Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    PFSense 2.4.2 über PPPOE mit DLINK Modem / 20% Paketverlust

    Deutsch
    5
    10
    506
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      thomaslauer last edited by

      Hallo Zusammen,

      ich habe eine PFSense mit v2.4.2 mit PPOE und einem DLINK Modem an einem Telekom ADSL Anschluss.
      Die PFSense meldet ca. 20% Paketverluste. laut Telekom ist der Anschluss in Ordnung.
      Vor der PFSense war eine Fortigate angeschlossen, die Problemlos lief.

      WAN01 Interface (wan, pppoe0)
      Status
      up
      PPPoE
      up Disconnect
      Uptime
      02:35:28
      IPv4 Address
      217.xxx.xxx.xxx
      Subnet mask IPv4
      255.255.255.255
      Gateway IPv4
      217.xxx.xxx.xxx
      IPv6 Link Local
      fe80::290:bff:fe68:7913%igb0
      DNS servers
      127.0.0.1
      217.237.151.142
      217.237.150.188
      8.8.8.8
      MTU
      1492
      In/out packets
      5326940/8590462 (681.41 MiB/10.53 GiB)
      In/out packets (pass)
      5326940/8590462 (681.41 MiB/10.53 GiB)
      In/out packets (block)
      5847/0 (307 KiB/0 B)
      In/out errors
      0/0
      Collisions
      0

      1 Reply Last reply Reply Quote 0
      • B
        Birke last edited by

        Wo siehst Du die Paketverluste? Beim Gatewaystatus?
        Wenn ja, was pingst Du an?
        Wir hatten bei unserem Telekomanschluss auch das Problem, dass da viele Fehler angezeigt wurden. Als wir das Gatewaymonitoring auf 8.8.8.8 umgestellt haben, waren die Fehler weg.

        1 Reply Last reply Reply Quote 0
        • T
          thomaslauer last edited by

          wir haben es bereits auf 8.8.8.8
          ich glaube jedoch das ist keine gute IP

          ich versuche es mal mit 9.9.9.9

          1 Reply Last reply Reply Quote 0
          • JeGr
            JeGr LAYER 8 Moderator last edited by

            8.8.8.8 hat keine Probleme zumal das meist geographisch geroutet und aufgelöst wird. 9.9.9.9 hat da mehr Latenz. Wenn du 20% Paketverlust hast mit 8.8.8.8 dann meistens(!) nicht wegen dem Server.

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • jahonix
              jahonix last edited by

              Kann ich nicht bestätigen, dass an einem Telekom VDSL (25) Anschluss die 8.8.8.8 ein gutes Monitoring-Ziel wäre. Zeitweise auch hier hohe Paketverluste, allesdings keine Collisions oder I/O Errors am WAN IF.
              Gerade heute war die Telekom vor Ort und hat den Splitter erneuert - jetzt linken wir zumindest wieder mit 21Mbps. Wir hängen auch im 217.x.y.z Bereich.

              Da die Telekom das Gateway ja nicht ping-bar gestaltet, versuche mal den next-hop. Wobei das auch nur ein Router ist und von der Technik jederzeit ersetzt oder außer Betrieb genommen werden kann.
              Ein Tip für das Monitoring war einmal heise.de, denn "die sind nie down". Auch das stimmt inzwischen nicht mehr.

              Probleme hatte ich beim Google DNS meistens zwischen 18h30 und 20h30, so dass der angehängte Vergleich die Zeit mit dem größten Traffic nicht wiederspiegelt. Momentan liegen 8.8.8.8 und 9.9.9.9 ziemlich gleich auf.

              ![9.9.9.9 vs 8.8.8.8.png](/public/imported_attachments/1/9.9.9.9 vs 8.8.8.8.png)
              ![9.9.9.9 vs 8.8.8.8.png_thumb](/public/imported_attachments/1/9.9.9.9 vs 8.8.8.8.png_thumb)

              1 Reply Last reply Reply Quote 0
              • Grimson
                Grimson Banned last edited by

                @jahonix:

                Da die Telekom das Gateway ja nicht ping-bar gestaltet, versuche mal den next-hop. Wobei das auch nur ein Router ist und von der Technik jederzeit ersetzt oder außer Betrieb genommen werden kann.
                Ein Tip für das Monitoring war einmal heise.de, denn "die sind nie down". Auch das stimmt inzwischen nicht mehr.

                Ich pinge aktuell den SIP Server der Telekom, der dürfte recht "nah" am Gateway sein und ich sehe dadurch auch recht flott wenn es Probleme mit der VOIP Verbindung gibt.

                1 Reply Last reply Reply Quote 0
                • jahonix
                  jahonix last edited by

                  Welchen denn, tel.t-online.de oder stun.t-online.de?
                  stun. steht in Ulm und ist damit für mich zwar nur 4 hops entfernt, trotzdem quer durch die Republik.
                  tel. wäre ganze 7 hops entfernt. Da ganz anders geroutet würde ich den nicht dringend auch in Ulm verorten.

                  Probiere wirklich mal den hop #3 aus Deinem trace route. Viel dichter geht's dann bei der Telekom wirklich nicht mehr.
                  Oder teste den Weg mit PingPlotter, der bereitet das trace route grafisch auf. Dann siehst Du, an welcher Stelle die Paketverluste beginnen.

                  1 Reply Last reply Reply Quote 0
                  • Grimson
                    Grimson Banned last edited by

                    @jahonix:

                    Welchen denn, tel.t-online.de oder stun.t-online.de?

                    tel.t-online.de, der ist bei mir der der 4. Hop mit einem Ping von 5ms. Allerdings wohne ich auch zwischen Darmstadt und Frankfurt, vermutlich steht er da irgendwo im Rechenzentrum. Den 3. Hop nutzen ich nicht, denn ich erhalte hier abwechselnd IPs aus dem 79er und 217er Bereich und je nach dem ändert sich auch dieser Hop während die IP des SIP Servers bisher immer gleich geblieben ist.

                    @jahonix:

                    Probiere wirklich mal den hop #3 aus Deinem trace route. Viel dichter geht's dann bei der Telekom wirklich nicht mehr.
                    Oder teste den Weg mit PingPlotter, der bereitet das trace route grafisch auf. Dann siehst Du, an welcher Stelle die Paketverluste beginnen.

                    Das wird für den OP wohl das Beste sein.

                    1 Reply Last reply Reply Quote 0
                    • JeGr
                      JeGr LAYER 8 Moderator last edited by

                      @jahonix: Das sieht aber so aus als hättest du bei egal welchem Ziel (egal ob quad8 oder quad9) immer wieder Aussetzer und Latenzen? Autsch! :/ Wir haben hier im südlichen Raum bei einigen Kunden sowohl die quad8 als auch die 8844 als Monitor drin und bei den VDSLs läuft das eigentlich recht zuverlässig. Aber wahrscheinlich wirds in den Randgebieten mit abnehmenden Leitungswerten schlechter?

                      Gruß

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      1 Reply Last reply Reply Quote 0
                      • jahonix
                        jahonix last edited by

                        Der graue Balken in der quad9 zwischen 22:57 und 22:58 ist entstanden, als ich die Aufzeichnung pausiert habe um beide Graphen synchron zu haben. Das war mal nicht das Netz.
                        Die generell erhöhte Latenz vor 23:00 sehe ich hier, wenn ich selbst eine größere Menge Daten auf dem VDSL generiere - in diesem Fall waren das 600MB Updates IIRC.
                        Die kleinen Spitzen dazwischen sorgen mich jedoch, so dass ich momentan ein neues VDSL-Modem in der Pipeline habe um das vorhandene Allnet ALL126AS2 mal zu tauschen.

                        Nicht erklären kann ich mir die PLs zu 217.0.117.216 in einem Graphen während der andere diesen Router ohne Aussetzer listet.

                        Alte Techniker-Weisheit dazu: Wer misst misst Mist. Wer viel misst misst viel Mist.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post