DSL remote-disconnected

[DirkK]

Hallo zusammen,

aktuell habe ich massiv mit DSL-Problemen zu kämpfen und ich weiß nicht, ob es nicht vielleicht doch an meiner Konfiguration, oder der neuen 10.90 Firmware des 1784 liegt. Der Provider meint natürlich wieder mal, dass auf seiner Seite alles OK sei.
Im syslog sehe ich folgende Fehlermeldungen:

303 2025-04-01 09:43:13 AUTH Info Disconnected from peer INTERNET: remote-disconnected
304 2025-04-01 09:43:13 AUTH Info Disconnected from peer INTERNET: remote-disconnected
305 2025-04-01 09:43:13 LOCAL0 Debug passive disconnect from peer INTERNET

Wie kann ich da zu mehr Infos bzgl. des Disconnect-Grundes kommen?
Ein Trace erscheint mir auf Grund des unvorhersehbaren Zeitraums des Verbindungsabbruchs schwierig, auf was müsste ich ggf. filtern, um genauere Debug-Info zu erhalten?

Danke
VG Dirk

[DirkK]

aktuell habe ich massiv mit DSL-Problemen zu kämpfen und ich weiß nicht, ob es nicht vielleicht doch an meiner Konfiguration, oder der neuen 10.90 Firmware des 1784 liegt. Der Provider meint natürlich wieder mal, dass auf seiner Seite alles OK sei.

Tja, so wie es aussieht könnte es doch an meiner Konfiguration bzw. der neuen 10.90 Firmware liegen:
Kurz zu meiner Konfiguration: 1784VA mit 60MBit-DSL-Anschluss über des interne Modem, zweiter WAN-Anschluss über ETH-4 = DSL-1 (Ethernet-Layer) an eine sog. ZTE-Hyperbox LTE/5G. Beide WAN-Verbindungen werden per Loadbalancer an das Intranet-LAN weitergeroutet.

Das hat die letzten zwei Jahre auch recht ordentlich und stabil funktioniert. Einzelne Services oder auch Clients musste ich per Policy-Based Routing auf den DSL-Kanal fixieren, aber z.B. der normale Web-Traffic wurde weitgehend problemlos über die beiden Leitungen verteilt.

Seit einigen Wochen kamen aber immer wieder Beschwerden/Berichte von Benutzern, die über "Packet-Bursts" und Probleme in Online-Spielen berichtet haben, sowie andere, die Probleme bei Teams oder WebEx-Konferenzen meldeten. Der normale Web-Traffic war unauffällig. Vor drei Wochen habe ich die Hyperbox (LTE/5G) für eine Woche an einem anderen Standort gebraucht und entsprechend vom 1784 abgeklemmt. In dieser Zeit haben die User weder über Packet-Bursts bei Spielen, noch über Audio-/Video-Probleme bei Konferenzen berichtet. Sobald ich die Hyperbox wieder angeschlossen hatte waren diese Symptome wieder da. Inzwischen wurde auch die 10.90.0220-RU2 released. Seitdem hatte ich dann auch die berichteten "Remote-disconnects" verstärkt beobachtet.

Soweit die Symptome. Bei der Fehlersuche in den letzten Tagen habe ich Messprofile in der SD-WAN Dynamic Path Selection eingerichtet, um hier eventuell weitere Hinweise zu bekommen. Und siehe da, hier sieht man durchaus ungewöhnliches Verhalten, wenn beide WAN-Anschlüsse aktiv sind. So wird die Leitungsqualität der DSL-Leitung teilweise massiv schlechter, wenn die LTE-Leitung gleichzeitig aktiviert ist (siehe beispielhafte Screenshots). So steigen Paketverlust, Latenz und Jitter teilweise massiv an, Jitter bis auf über 8000ms und das auf DSL. Im Endeffekt ist dann praktisch die LTE-Leitung meist besser, als DSL und das, obwohl der LTE-Empfang auch eher schlecht ist. Weitere Tests (z.B. speedtest.net) zeigen ebenfalls unerklärliches Verhalten. Sind beide WAN-Leitungen aktiv, der Loadbalancer ist ausgeschaltet bzw. der Traffic wird alles über DSL geroutet, so erhalte ich lediglich 30MBit Durchsatz. Klemme ich ohne weitere Änderung den LTE-WAN-Anschluss ab erhalte ich die erwarteten 54-56MBit über DSL. Diese Verhalten ist jederzeit reproduzierbar.
D.h. alleine das aktive Vorhandensein der zweiten WAN-Leitung (LTE), ohne dass irgendwelches Routing, oder Datenfluss erfolgt, führt zu massiver Verschlechterung der DSL-Leitung des internen Modems. Das geht eben soweit, dass seit Update auf die 10.90 RU2 sogar diese "remote-disconnects" gemeldet werden.
Über die letzten zwei Tage habe ich nun testweise mal das ETH-4 ausgeschaltet (bei sonst unveränderter Konfiguration) und siehe da, keine disconnects, keine "Packet-Bursts", keine Probleme bei Audio-/Video-Konferenzen.

Ich bin komplett ratlos, jemand von euch eine Idee??

VG Dirk

[Dr.Einstein]

Ich kann dir nicht sagen, ob es auch die 17xx Modelle betrifft: Laut 10.90 Release Notes

Der VDSL-/ADSL-Linecode wurde aktualisiert.

Also einfach mal auf die 10.80RU10 zurück gehen?

[DirkK]

Also einfach mal auf die 10.80RU10 zurück gehen?

Danke, den Gedanken habe ich auch schon gehabt, ich habe nur etwas Bedenken bzgl. der Konfiguration. Nicht immer ist die ja abwärtskompatibel.
Wäre vielleicht ein Versuch wert.

Grüße
Dirk

[Frühstücksdirektor]

Hallo Dirk,

das Linecode-Update betraf m.W. nach nur die 180x-Serie und die 1926/1936-Serie.

Folgende Ideen hätte ich:
1) Das Remote Disconnected im PPPoE kann dadurch kommen, dass der BRAS kein LCP-Echo-Paket mehr vom LANCOM bekommt, warum auch immer.
2) Ich würde eine Config-Sicherung machen und das unter der 10.80 testen
3) Tritt der Fehler dort auf, ist es vmtl. ein Config-Fehler. Könnte in einer fehlerhaften Routing-Tabelle, Loadbalancer oder DSL-Gegenstellen sein
4) Tritt der Fehler nicht unter der 10.80 und nur unter der 10.90 auf, müssen wir das hier näher analysieren. Hier würde ich tracen, wo die angeblichen verlorenen Pakete hingehen.

Viele Grüße,
Frühstücksdirektor

[DirkK]

Hallo Frühstücksdirektor (und an alle anderen natürlich auch),

2) Ich würde eine Config-Sicherung machen und das unter der 10.80 testen

4) Tritt der Fehler nicht unter der 10.80 und nur unter der 10.90 auf, müssen wir das hier näher analysieren. Hier würde ich tracen, wo die angeblichen verlorenen Pakete hingehen.

habe ich gemacht und wie erwartet war das nicht so trivial, weil nicht alles abwärtskompatibel ist (z.B. VRRP-Konfiguration). Soll keine Beschwerde sein, sondern nur verdeutlichen, dass ich eine möglichst identische Konfiguration (zumindest bezogen auf die beiden WAN-Leitungen und den Loadbalancer) für die Versionen 10.90 und 10.80 als Basis für einen Vergleich hergestellt habe.

Ergebnis: unter der 10.80 treten die Probleme mit den Paketverlusten nicht auf, beim Umstellen auf 10.90RU2 treten sie reproduzierbar wieder auf.

Schwierig ist es die Diagnose und das Vorhandensein von Paketverlusten auch wirklich nachzuweisen. Aus der Fehleranalyse haben sich für mich folgende Parameter als Hinweisgeber herauskristallisiert: "Packet-Bursts" in Online-Spielen, sowie (deutlich) verminderte Durchsatzraten bei Speedtests, jeweils per policy based routing gebunden auf die DSL-Leitung. Die Anzeige von Packetverlust und Jitter in den Messprofilen vom DPS sind zu träge, um hier einen quantitative Indikation zu liefern. Wenn jemand eine andere Idee, oder Vorschlag hat: "very welcome".

Folgendes Verhalten bei der 10.90RU2 ist bezeichnend: sobald ich den ETH-4 Port (Anschluss des LTE-Routers) auf DSL-1 (2. WAN-Leitung) konfiguriere treten Paketverluste am internen DSL-Modem auf. Ist ein für mich recht unverständliches Verhalten, aber reproduzierbar. Schalte ich ETH-4 aus (stromlos), oder auf LAN-4 sind die Paketverluste am internen DSL-Modem verschwunden.

VG Dirk

[tobiasr]

Und wieso schaltest du den AUCH auf DSL1 und nicht auf DSL2?

[DirkK]

Und wieso schaltest du den AUCH auf DSL1 und nicht auf DSL2?

Ich habe nicht geschrieben, dass ich den ETH-4 auch auf DSL-1 geschaltet habe, sondern "nur" auf DSL-1.
Testweise habe ich es aber auch mal auf DSL-2 gestellt, macht aber keinen Unterschied.

Nur zur Klarstellung: das interne VDSL-Modem läuft unter DSL Port 0

[DirkK]

Ich poste hier mal die Konfig 1

[DirkK]

Ich poste hier mal die Konfig 2

[tstimper]

Hallo Dirk,

mir ist beim durchlesen des Threads und beim Nachdenken über das was wir am Montag im Call besprochen haben noch folgendes eingefallen:

Long Story short:

Stell mal für Deine beiden Gegenstellen des Loadbalancers dieselbe MTU ein. Die muss gleich oder kleiner der kleineren MTU beider Anschlüsses sein.
Teste mal 1300 oder 1250 oder 1200 und erhöhe den Wert bis die Paketverluste wieder auftreten.

Long Story long:

1. In früheren LCOS Versonen wurde z.b. für VPN einfach eine relativ kleine MTU (1200 oder so) hardgecoded.
Damit funktionierten dann die meisten Leitungen einfach mit VPN.
Bei späteren LCOS Versionen war und ist die MTU konfiurierbar.
Normalerweise macht der Client ja eine Path MTU Bestimmung und nimmt für für dire Pakete die kleinste MTU, die noch in den gesamten Path passt.
Also wenn z.B. auf dem Weg ins Internet jemand eine MTU von 512 hat, da wird der gesamte Traffic vom Client in 512 Bytes große Pakete zerlegt.

2. Es hieß in Lancupdate Präsentationen und im Support immer, das der Loadbalancer nur richtig läuft, wenn die Anschlüsse gleich in Art und Geschwindiglkeit sind.

3. VDSL hat eine MTU von 1492, LTE hat eine MTU von 1500

4. Provider Layers können die MTU veringern.

5. Du bündelst mit dem Loadbalancer zwei Leitungen mit unterschiedlichen MTUs

Also wenn die Veringerung der MTU hilt, hätten wir eine Aussage, mit der die Entwickler auch was anfangen können.

Viele Grüße

ts

[DirkK]

Hallo Thomas,

mir ist beim durchlesen des Threads und beim Nachdenken über das was wir am Montag im Call besprochen haben noch folgendes eingefallen:
3. VDSL hat eine MTU von 1492, LTE hat eine MTU von 1500

ohhh, das ist ein guter Hinweis!

Also ich habe mal die MTU's beider Gegenstellen auf 1492 gesetzt. Und tatsächlich, das Problem ist deutlich besser geworden. Ich sehe bei starken Traffic zur nach wie vor "remote-disconnects", aber der Paketverlust ist massiv gesunken und beträgt laut Messprofilen (DPS) i.d.R. unter 3% und nicht wie ohne MTU-Begrenzung auch gerne mal >30%. Auch die Paketverluste in den Online-Spielen sind deutlich zurückgegangen., aber leider noch nicht so, wie vor der 10.90RU2. Auch der Speedtest ist noch nicht auf dem Niveau, wie es der "Single-DSL-Betrieb" zeigt.
Die Frage ist jetzt, ob ich nochmal MTU-Werte unter 1492 probieren soll.

VG Dirk

[tstimper]

Hallo Dirk,

Wir haben Szenarien mit Reseller Providern plus WLC Tunnel plus VPN, da müssen wir bis auf 1250 MTU runter gehen.

Du kannst mal je Gegenstelle die Path-MTU testen und
stellst dann das kleinere minus 10 als Sicherheit ein.

https://de.m.wikipedia.org/wiki/Path_MTU_Discovery

https://learn.microsoft.com/en-us/samp ... etpathmtu/


Teste mal …


Viele Grüße

ts

[DirkK]

Hallo Thomas,

Teste mal …

Done: (mehr oder minder abwechselnd) zwischen 1492 und 1498. Das zeigt zumindest, dass der Loadbalancer offensichtlich funktioniert .
Für Tests und Verifikation brauche ich noch etwas Zeit, aber erste Speedtests und DPS-Messprofil-Statistiken zeigen keine weitere Verbesserung.
Überlege gerade, ob ein externes DSL-Modem / -Router vielleicht ein Testcase wert wäre.

Danke für deinen Input!

VG Dirk

[Dr.Einstein]

https://ftp.lancom.de/Documentation/Rel ... RU3_DE.pdf

Waren bei CPE-Routern mit mehreren Internet-Verbindungen mindestens zwei
Verbindungen aufgebaut, kam es zu Timing-Problemen in der WarteschleifenVerwaltung (Active Queue Management) für Quality of Service (QoS).
Dies führte zu hohen Latenzen und zu Paketverlusten bei der InternetKommunikation