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

[thomaslauer]

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

[Birke]

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.

[thomaslauer]

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

[JeGr]

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.

[jahonix]

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.


[Grimson]

@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.

[jahonix]

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.

[Grimson]

@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.

[JeGr]

@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ß

[jahonix]

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.