1781VA mit Paketverlust an xDSL-Anschlüssen der Telekom

[fildercom]

Hallo zusammen,

ich habe die letzten Wochen eine wirklich seltsame Beobachtung gemacht, die ich mir nicht erklären kann. Dazu muss ich jedoch ein wenig ausholen: Meine beiden Anschlüsse der Telekom (ADSL2+ und VDSL 250) sind über einen Outdoor-DSLAM geschaltet, welcher per Querkabel "meinen" Kupfer-KVz versorgt. Der Kupfer-KVz hat noch Lötstreifen und das Vzk ist leider noch papierisoliert. Das alte Zeug ist damit nicht mehr im allerbesten Zustand, leider.

Nun nutze ich seit einem halben Jahr ein externes Monitoring für meine Leitungen. Dazu habe ich einen Account bei thinkbroadband.com eingerichtet. Für die Überwachung sendet deren Server permanent ICMP-Anfragen an meine IP-Adressen. Die Antworten der Router werden dann grafisch aufbereitet. So erkennt man beispielsweise vollständige Ausfälle, Paketverlust und hohe Latenzen.

Bis vor kurzem hatte ich an beiden xDSL-Anschlüssen jeweils einen 1781VA angeschlossen. Lange Zeit mit den internen Modems, vor wenigen Wochen dann auf zwei externe Modems umgestellt.

In der Überwachung hatte ich bei beiden xDSL-Anschlüssen seit jeher permanten leichten Paketverlust. Es machte keinen Unterschied, ob das interne oder externe Modem benutzt wurde.

Vor kurzem habe ich am ADSL2+ statt dem 1781VA einen 1900EF angeschlossen. Dabei habe ich nicht schlecht gestaunt: der permanente leichte Paketverlust ist weg!

Hier der Beweis:

monitoring.PNG

Am VDSL mit dem 1781VA und dem externen Modem (DrayTek Vigor 165) sieht man diese roten Bereiche oben am Schaubild. Am ADSL2+ mit 1781VA und DrayTek Vigor 130 sah das identisch aus. Mit dem 1900EF und dem Vigor 130 hingegen ist der Paketverlust weg.

Ich hatte in Sachen Paketverlust immer, aber wirklich immer, dieses alte Papierkabel im Verdacht, durch welches nicht korrigierbare Fehler entstehen = verlorene Pakete. Aber es ist nicht das Kabel, sondern der Router, welcher dafür verantwortlich ist.

Kann sich dieses Verhalten jemand erklären? Dass die CPU überfordert wäre kann ich ausschließen, auf dem ADSL2+ ist kaum Last drauf, auf dem VDSL momentan auch ganz wenig Last (momentan route ich 90 % des Traffics über den DOCSIS-Kabelanschluss).

Woher kommt also dieser Paketverlust beim 1781VA, den der 1900EF nicht auslöst?

Insbesondere beim VoIP ist das Thema Paketverlust nämlich zeitweise ein Ärgernis.

Gruß und danke
fildercom.

[GrandDixence]

Im Fall von "TestUser123" hat sich ja das Paketverlustrate-Problem@*DSL auch auf wundersame Weise "in Luft aufgelöst".
fragen-zum-thema-vpn-f14/vpn-tunnel-bre ... 0-s15.html
Vielleicht sollte diese Frage an die Deutsche Telecom gestellt werden.

Mir persönlich wäre die Paketverlustrate und Latency auch im unteren Screenshot noch viel zu hoch! => Siehe dazu meinen Beitrag im oben aufgeführten Link auf Seite 2.

In der Schweiz wird für den Einsatz an ADSL/VDSL-Internetanschlüsse als Endgerät (CPE) nur die LANCOM 1781- und 1783er Serie mit dem DSL-Chipsatz IFTN VRX268 empfohlen:
https://www.swisscom.ch/dam/swisscom/en ... ipment.pdf

Diese Empfehlung dient zur Vermeidung von Hardwarekompatibilätsproblemen DSLAM<->Endgerät.
https://de.wikipedia.org/wiki/Digital_S ... ultiplexer
Die in der Liste aufgeführten xDSL- und G.Fast-Modem/Router wurden von Swisscom ausführlich getestet und erfüllen das Anforderungsprofil.
https://www.swisscom.ch/dam/swisscom/en ... -V3.00.pdf

[fildercom]

@ GrandDixence:
Viele deiner Beiträge bestehen nur aus einer Link-Sammlung zu anderen Beiträgen und Anbietern. Das ist dann eher wenig hilfreich. Ich sehe auch keinerlei Parallelen zu meinem "Problem". Ein Lehrer würde in dem Fall "Thema verfehlt" sagen...

[fildercom]

Hat wirklich niemand eine Idee, warum es beim 1781VA diesen Paketverlust gibt?

Ich bin mir ganz sicher, dass wenn ich den noch verbliebenen 1781VA ebenfalls durch einen 1900EF ersetzen würde (beide jeweils mit dem gleichen externen DrayTek Vigor 165-Modem), der Paketverlust weg wäre. Trotzdem wäre es schön zu wissen, was die Ursache dafür beim 1781VA ist, denn das eigebaute Modem scheidet als Fehlerquelle schonmal aus...

[MoinMoin]

Moin fildercom,

ich bin mir nicht sicher. Kann sein, daß in den neueren LANCOMs ein anderer Switch verbaut ist.

Ciao, Georg

[alf29]

Moin,

ja, ein QCA8337 statt eines AR8327, die unterscheiden sich aber nur in Nuancen.

Was mir persönlich zu so etwas nur einfällt, sind entweder Paketbursts auf der Verbindung (das 1900EF hat einen Prozessor mit anderer Ethernet-Hardware und evtl. tieferen Puffern). oder ein anderer Job, den es so auf dem 1900EF nicht gibt, belegt die CPU so lange, daß der Ethernet-Treiber nicht drankommt. So oder so wüßte ich aber nicht, wie man das ohne Nachstellmöglichkeit adressieren sollte.

Viele Grüße

Alfred

[fildercom]

Danke euch beiden für die Antworten. Tja, es ist eben wirklich die Frage, ob das Problem mit dem leichten Paketverlust nur in meinem Szenario auftritt, oder ob es das noch häufiger gibt oder ob es gar quasi immer auftritt, nur dass es bisher noch niemandem aufgefallen ist. Und falls es häufiger auftritt ist auch die Frage, ob es mit der Gegenstelle zusammen hängt. Gut wäre es, wenn vielleicht jemand aus dem Forum mit einem 1781VA an einem Telekom xDSL-Anschluss bereit wäre, mal ein Monitoring bei thinkbroadband einzurichten und das Schaubild hier zu posten. Da wäre ich mehr als neugierieg, wie das aussehen würde.

[alf29]

Gut wäre es, wenn vielleicht jemand aus dem Forum mit einem 1781VA an einem Telekom xDSL-Anschluss bereit wäre, mal ein Monitoring bei thinkbroadband einzurichten und das Schaubild hier zu posten. Da wäre ich mehr als neugierieg, wie das aussehen würde.

Ich habe hier zwar ein 1781VAW an einem Telekom-Anschluß, aber mit ordinären 16 MBit. Das dürfte kaum vergleichbar sein...

[cpuprofi]

Hallo Fildercom,

... es ist eben wirklich die Frage, ob das Problem mit dem leichten Paketverlust nur in meinem Szenario auftritt, oder ob es das noch häufiger gibt oder ob es gar quasi immer auftritt...

ich hatte mal eben testweise einen Account bei "thinkbroadband.com" eingerichtet und bei meinem 1781VA (int. Modem) an T-Com VDSL 50/10 zeigt sich ein fast gleiches Bild wie bei Dir (oben immer der Grissel von den Paketverlusten).

Die Frage welche ich hier mal in den Raum werfen möchte, kann das vielleicht mit IDS zusammen hängen? Wobei ich dort extra für diesen Test die Einstellungen auf "übertragen" geändert habe.

Grüße
Cpuprofi

[fildercom]

Ich habe hier zwar ein 1781VAW an einem Telekom-Anschluß, aber mit ordinären 16 MBit. Das dürfte kaum vergleichbar sein...

Hallo Alfred,

danke für das Feedback. Doch, das passt doch genau. 16 Mbit/s ist dann ein ADSL2+, also entspricht exakt dem Anschluss, an dem ich den 1781VA durch den 1900EF ersetzt habe. Und auch hier sah es ganz genau so aus in Sachen Paketverlust, nicht nur am VDSL 250 (der übrigens aufgrund der schlechten Leitung auch "nur" mit 233 Mbit/s synchronisiert - aber das ist ein anderes Thema).

Die Frage welche ich hier mal in den Raum werfen möchte, kann das vielleicht mit IDS zusammen hängen? Wobei ich dort extra für diesen Test die Einstellungen auf "übertragen" geändert habe.

Hallo cpuprofi,

dein Posting hat mich auf eine Idee gebracht. Ich habe mal in die IPv4-Firewall-Ereignisse im LANmonitor geschaut und siehe da:

Firewall.PNG

Die 80.249.99.164 ist der ICMP-Testserver von thinkbroadband.

Ich würde morgen mal testweise eine ALLOW-Regel in der Firewall anlegen. Da ich gerade nicht am Standort des 1781VA bin habe ich mal in einem leeren LANconfig eine Regel gebastelt:

Regel.PNG

So sollte es doch klappen? Einzig beim Ziel bin ich mir unsicher, es soll ja keine Station im LAN sein, sondern der Router selbst. Ist das dann mit "Gegenstelle" "TELEKOM" richtig, oder muss hier 127.0.0.1 rein oder ganz was anderes?

Gruß und danke
fildercom.

[MoinMoin]

Moin fildercom,

die Verworfenen Pakete an Adresse 0.0.0.0 bekomme ich gelegentlich auch, seit ich eine 10.40 im Gerät habe. Wobei ich eigentlich davon ausgehe, daß vom Provider keine Pakete mit der Zieladresse an meinen Anschluß geroutet werden.

Code: Alles auswählen

Date: 6/3/2020 14:14:03

The packet below

Src: 18.162.200.43  Dst: 0.0.0.0 (ICMP)

IP-Packet (36 Bytes):

   45 00 00 24 de ec 40 00  f3 01 89 b8 12 a2 c8 2b | E..$..@. .......+
   00 00 00 00 08 00 e2 46  00 17 32 f3 16 15 07 a2 | .......F ..2.....
   f1 c6 d3 30                                      | ...0
matched this filter rule: intruder detection
filter info:              packet for invalid address 0.0.0.0 received
from interface NETCOLOGNE

because of this the actions below were performed:
   drop
   send email to administrator

Ciao, Georg

[fildercom]

Moin fildercom,

die Verworfenen Pakete an Adresse 0.0.0.0 bekomme ich gelegentlich auch, seit ich eine 10.40 im Gerät habe.

Hallo Georg,

bei mir läuft aber noch die 10.32.

Gruß
fildercom.

[MoinMoin]

Moin Fildercom,

ich bin wohl direkt von der 10.20 auf die 10.40 umgestiegen.

Ciao, Georg

[cpuprofi]

Hallo Fildercom und Georg,

dann sollte man doch mal einen WAN-Trace für die Adresse 80.249.99.164 machen, dann sieht man doch sofort was da los ist.

Ich für meine Teil werde das mal für die FW 10.40 anstoßen.

Grüße
Cpuprofi

[cpuprofi]

Hallo an Alle,

so nun hier das Ergebnis:

Code: Alles auswählen

[VDSL-DATA] 2020/06/04 15:01:19,050  Devicetime: 2020/06/04 15:01:21,751
Received 60 byte Ethernet packet via LL-VDSL:
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : 02:a0:57:1b:a9:4a (LANCOM (local-0) 1b:a9:4a)
Source              : 3c:61:04:51:bb:62
Type                : 802.1p/q VLAN
-->802.1p/q VLAN Header
VLAN Id             : 7
VLAN Prio           : 0
VLAN CFI            : 0
Type                : PPPoE Session
-->PPPoE Session Packet
Version             : 1
Type                : 1
Code                : Session
Session-ID          : 148
Payload Length      : 30
--->PPP Payload
Protocol            : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 28
ID                  : 24859
Fragment            : Offset 0
TTL                 : 59
Protocol            : ICMP
Checksum            : 51156 (OK)
Src Address         : 80.249.99.164
Dest Address        : 79.192.82.148
-->ICMP Header
Msg                 : echo request
Checksum            : 18060 (OK)
Identifier          : 32872
Sequence            : 12555
Packet Trailer      : 00 00 00 00 00 00       ......

[Firewall] 2020/06/04 15:01:19,250  Devicetime: 2020/06/04 15:01:21,752
Packet matched rule intruder detection
DstIP: 0.0.0.0, SrcIP: 80.249.99.164, Len: 28, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x8068, seq: 0x310b

Filter info: packet for invalid address 0.0.0.0 received from interface T-COM
send SNMP trap
send email to administrator
packet dropped

Wie man hier schön sieht, macht die Firewall/IDS hier einen Fehler:

Die Firewall/IDS nimmt hier eine "DstIP: 0.0.0.0" an, wie sie darauf kommt ist fraglich...

Übrigens: Im VDSL-WAN-Trace im Lancom Webfrontend findet man in Wireshark keine "IP: 0.0.0.0".

Somit scheint das ein BUG zu sein, auf den Fildercom gestoßen ist.

Viele Grüße
Cpuprofi