Internetverbindung wird alle 2 Stunden getrennt
5 years ago
Hallo zusammen,
ich habe an meinem Anschluss das Problem, dass seit dem 6. Januar 2020 die Internetverbindung (PPPoE-Einwahl) etwa alle 2 Stunden (+-5 Minuten) getrennt wird - die DSL-Synchronisation ist absolut stabil. Auch ist eine sofortige Wiedereinwahl problemlos möglich.
Die letzte Änderung am Anschluss war ein Tarifwechsel im Mai 2019, sonst wurde nichts geändert und es gab auch absolut keine Probleme bis jetzt.
Über entsprechende Debugging- bzw. Tracingfunktionen meines Routers (Cisco ISR1100 mit Zyxel VMG1312-B30A als Modem) kann ich sehen, dass die Trennung der PPPoE-Session vom BNG initiiert wird, das Verhalten gleicht der alten 24-Stunden-Zwangstrennung, nur eben mit 2 Stunden, siehe Screenshot im Anhang.
[DATENSCHUTZ] ist die MAC-Adresse des BNGs, [DATENSCHUTZ] ist die MAC-Adresse meines Routers. Paket #3979 ist der PPP Termination Request vom BNG .
Auf Basis dessen würde ich ein Problem meinerseits nahezu ausschließen und auf ein Telekom-seitigs Konfigurationsproblem (vermutlich irgendwo im RADIUS , Kundendatensatz, etc.) tippen.
Generell scheint diese Problematik ja scheinbar kein Einzelfall und auch lösbar zu sein:
- https://www.onlinekosten.de/forum/showthread.php?t=152453
Ich habe dazu bereits versucht regulär eine Störung zu melden. Die erste Störungsmeldung ([DATENSCHUTZ]) ging zur Diagnose und wurde nach 72 Stunden automatisch vom System geschlossen.
Vorhin habe ich dann eine neue Störung ([DATENSCHUTZ]) gemeldet, der Hotline-Kollege hat sich viel Zeit für das Problem genommen, konnte aber wohl mit seinen Mitteln (Techniker, Line-Reset, Rekonfiguration, etc.) nicht viel tun zumal sein System sagt es wäre alles in Ordnung. Er gab mir auch zu verstehen, dass er keine großen Hoffnungen hat, dass dieses Problem von ihm oder direkt nachgelagerten Abteilungen gelöst werden könnte.
Vielleicht kann ja mal jemand vom Telekom hilft Team ein Auge darauf werden und die Störungsmeldung ggf. in die richtigen Bahnen lenken...?
Danke vorab!
-------------------------------------------
MAC's, Anlage und TicketID's gelöscht.
1358
24
5 years ago
Willkommen hier im Kunde-hilft-Kunde-Forum.
Deine Störungsmeldung dürfte in den richtigen Bahnen sein ( auch wenn Du vielleicht zwischenzeitlich so eine irreführende ErforlsSMS bekommen hast).
Aber vielleicht schaut ja doch einmal ein Mitglied vom Telekom-hilft-Team vorbei, da wäre es hilfreich, wenn Du wenigstens Deine Kontaktdaten schon mal hinterlegt hättest (Kann außer dem Team keiner einsehen):
https://telekomhilft.telekom.de/t5/user/myprofilepage/tab/personal-profile%3Atelekom-custom-user-pro...
Werde dann mal eskalieren....
0
5 years ago
Beim DSL gibt es nur eine Handvoll Fehlerbilder.
Also ist der Verweis auf andere Störungsmeldungen völlig unsinnig - du findest bei x Millionen DSL Anschlüssen in Deutschland immer mehrere Tausend Leute, welche gerade auch eine Störung mit dem Fehlerbild haben.
0
5 years ago
3
Answer
from
5 years ago
@Marlon K.
Vielen Dank!
Wie bereits im ersten Beitrag erwähnt ist habe ich bereits eine Störung gemeldet.
Da aus mir unerfindlichen Gründen die Störungsnummer aus dem Beitrag entfernt wurde, hier nochmals die Nummer: 256159454
Da ich mehr als einen Anschluss auf meiner Kundenummer habe ist die Info ggf. "wichtig" um das Problem dem richtigen Anschluss zuordnen zu können.
@CyberSW
Ich erlaube mir mal die von dir entfernten Informationen hier wieder hinzuzufügen da diese weder personenbezogen noch "geheim" sind sondern IMHO durchaus relevant bzw. hilfreich für die Störungseingrenzung bzw. -bearbeitung sind.
Abgesehen davon sind die Informationen von mir und daher meine freie Entscheidung was ich veröffentliche.
Hinsichtlich der Sinnhaftigkeit von Verweisen bzw. Hinweisen auf ähnliche oder gar identische Störungsfälle habe ich eine andere Meinung, aber das müssen wir an dieser Stelle nicht vertiefen.
No. Time Source Destination Protocol Length Info
3914 2020-01-18 13:57:35,333 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPP LCP 60 Echo Request
3915 2020-01-18 13:57:35,333 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPP LCP 60 Echo Reply
3933 2020-01-18 13:57:43,901 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPP LCP 60 Echo Request
3934 2020-01-18 13:57:43,918 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPP LCP 60 Echo Reply
3953 2020-01-18 13:57:53,914 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPP LCP 60 Echo Request
3954 2020-01-18 13:57:53,931 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPP LCP 60 Echo Reply
3979 2020-01-18 13:58:03,682 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPP LCP 60 Termination Request
3980 2020-01-18 13:58:03,683 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPPoED 60 Active Discovery Terminate (PADT)
3981 2020-01-18 13:58:03,685 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPP LCP 60 Termination Ack
3982 2020-01-18 13:58:03,689 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPPoED 60 Active Discovery Terminate (PADT)
4013 2020-01-18 13:58:23,742 00:00:5e:00:01:yy ff:ff:ff:ff:ff:ff PPPoED 60 Active Discovery Initiation (PADI)
4014 2020-01-18 13:58:23,832 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPPoED 66 Active Discovery Offer (PADO) AC-Name='<removed>'
4018 2020-01-18 13:58:25,793 00:00:5e:00:01:yy 88:a2:5e:bf:24:xx PPPoED 66 Active Discovery Request (PADR) AC-Name='<removed>'
4019 2020-01-18 13:58:25,816 88:a2:5e:bf:24:xx 00:00:5e:00:01:yy PPPoED 66 Active Discovery Session-confirmation (PADS) AC-Name='<removed>'
MAC-Adresse des BNG : 88:a2:5e:bf:24:xx
MAC-Adresse meines Routers: 00:00:5e:00:01:yy
Paket #3979 ist der PPP Termination Request vom BNG .
pppoe-capture-2-stunden-trennung_edit.png
Answer
from
5 years ago
@cm42Bearbeitungsnummern und öffentliche IP Adressen sind durchaus persönliche Daten und haben hier in der Öffentlichkeit nichts zu suchen und würden daher entfernt.
Mit gefülltem Profil können die Teamies alles Notwendige nachvollziehen.
Answer
from
5 years ago
Unlogged in user
Answer
from
5 years ago
2
Answer
from
5 years ago
@Marlon K.
Alles klar, danke für die Information.
Der Fehler ist weiterhin vorhanden, aber schauen wir mal ob der neue Port evt. eine Veränderung ergibt.
Answer
from
5 years ago
@Marlon K.
Die Umschaltung auf den neuen Port wurde am Freitag (24.01.2020) zwischen 12:10 und 12:20 Uhr durchgeführt, jedenfalls ist in diesem Zeitraum die Synchronisation kurz weg gewesen.
Leider hat der neue Port das Fehlerbild nicht verändert:
[...]
24.01.2020 23:53:01 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 23:52:39 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 21:57:38 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 21:57:16 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 20:02:15 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 20:01:53 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 18:06:52 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 18:06:30 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 16:11:29 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 16:11:07 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 14:16:06 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 14:15:44 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 12:20:43 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 12:14:29 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 11:40:06 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 11:39:44 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 09:39:44 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 09:39:22 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 07:44:20 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 07:43:58 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
24.01.2020 05:48:57 DIALER-6-BIND: Interface Vi3 bound to profile Di1
24.01.2020 05:48:35 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
[...]
Die Fett markierten Zeilen sind die Trennung & Neuverbindung aufgrund des Portwechsels (UNBIND = Trennung, BIND = Verbindungsaufbau).
Der Fehler ist also nach wie vor vorhanden, leider.
Ich habe am Wochenende auch versuchsweise mal Easy Login aktiviert und festgestellt, dass auch damit der Fehler auftritt - falls diese Information irgendwie weiterhilft.
Unlogged in user
Answer
from
5 years ago
1
Answer
from
5 years ago
@Marlon K.
Ja, leider ist der Fehler noch immer vorhanden, hier die Logs von heute:
[...]
27.01.2020 19:59:15 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 19:58:53 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 17:58:52 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 17:58:30 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 16:03:29 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 16:03:07 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 14:03:07 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 14:02:44 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 12:07:43 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 12:07:21 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 10:12:20 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 10:11:58 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 08:16:57 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 08:16:35 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 06:21:34 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 06:21:12 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 04:26:10 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 04:25:48 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 02:30:47 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 02:30:25 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
27.01.2020 00:30:24 DIALER-6-BIND: Interface Vi3 bound to profile Di1
27.01.2020 00:30:02 DIALER-6-UNBIND: Interface Vi3 unbound from profile Di1
[...]
Sind also nach wie vor die Intervalle von ca. 1:55 bzw 2:00 Stunden, also 6900 bzw. 7200 Sekunden.
Unlogged in user
Answer
from
5 years ago
0
5 years ago
0
5 years ago
1
Answer
from
5 years ago
@Marlon K.
Ich nutze auf dem DSL-Modem Zyxel VMG1312-B30A die Zyxel-Firmware Version V1.00(AATO.6)C0. Diese ist aus 2016 und in der Tat etwas älter, läuft jedoch stabil (bei neueren Versionen hängt sich das Modem gelegentlich auf und muss resettet werden).
Um hier jedoch einen Fehler auszuschließen habe ich heute zwischen 15:30 und 16:00 Uhr ein Update auf die Telekom-Firmware Version V1.00(AAEB.7) (welche unter https://www.telekom.de/hilfe/geraete-zubehoer/router/weitere-router/zyxel/zyxel-vmg-1312-b30a angeboten wird) durchgeführt.
Mein Router hat nach dem Update um 16:02 Uhr wieder eine PPPoE-Verbindung aufgebaut - diese wurde jedoch um 17:57 Uhr wieder getrennt. Um 19:53 Uhr erfolgte dann die nächste "Zwangstrennung". Also wieder ziemlich genau die 6900 bzw. 7200 Sekunden.
Ich würde somit einmal behaupten, dass die Modem-Firmware keinen Einfluss (weder positiv noch negativ) auf das Problem hat.
Hinsichtlich des Routers verwende ich die Cisco-Firmware-Version IOS-XE 16.09.04 welches seitens Cisco das aktuelle "Recommended Release" ist. Es gibt keine neuere "stable" Firmware.
An dieser Stelle möchte ich auch nochmals darauf hinweisen, dass mein "Setup" so seit Monaten unverändert (d.h. Hardware, Software, Firmware, Konfiguration) in Betrieb ist und bis zum 6. Januar 2020 absolut störungsfrei war.
Rein logisch betrachtet muss sich am 6. Januar 2020 irgendetwas "Telekom-netzseitig" verändert haben was dieses Verhalten auslöst.
Unlogged in user
Answer
from
5 years ago
1
Answer
from
5 years ago
@Marlon K.
Gibt es hier bereits irgendwelche Neuigkeiten?
Danke vorab!
Unlogged in user
Answer
from
5 years ago
Moin, ich gebe das hier mal direkt weiter:
RüMeld. v. BICO:
Die Sessions werden alle 2 Stunden getrennt, weil das Endgerät des Kunden nicht auf die LCP Keepalives (LCP EchoRequest) des BNG antwortet.
Fehler liegt am Kundenendgerät.
bngafr@ERKJ01> op show-subscriber line-id DEU. DTAG .XXXX | match login
01.02.2005 12:11
Login Time: 2020-02-05 12:03:31 CET
{master}
bngafr@ERKJ01> show log radius.log | match DEU. DTAG .XXXX
01.02.2005 12:11
Feb 5 12:03:09.431166 UserAccess:000xxxxxxxxxxxxxxxxxxxxx0001@t-online.de session-id:41796185 state:logout-start ERKJ01#ge-0/2/6.demux0.3221417685:1179-7#10.109.194.62/0.0.0.0 atm 2/29#DEU. DTAG .XXXX
Feb 5 12:03:09.814799 UserAccess:000xxxxxxxxxxxxxxxxxxxxxxxx0001@t-online.de session-id:41796185 state:log-out ERKJ01#ge-0/2/6.demux0.3221417685:1179-7#10.109.194.62/0.0.0.0 atm 2/29#DEU. DTAG .XXXX reason: aaa shutdown-idle-timeout
Feb 5 12:03:31.660048 UserAccess:000xxxxxxxxxxxxxxxxxxxxxxxxxxxxx0001@t-online.de session-id:41802669 state:start ERKJ01#ge-0/2/6.demux0.3221418929:1179-7#10.109.194.62/0.0.0.0 atm 2/29#DEU. DTAG .XXXX
Feb 5 12:03:32.011573 UserAccess:000xxxxxxxxxxxxxxxxxxxxxxxxxxxxx0001@t-online.de session-id:41802669 state:access-granted ERKJ01#ge-0/2/6.demux0.3221418929:1179-7#10.109.194.62/0.0.0.0 atm 2/29#DEU. DTAG .XXXX
{master}
bngafr@ERKJ01>
Bitte noch einmal, beim Hersteller des Modems nachfragen, ob es dort noch irgendwelche Hotfixes oder Konfigurationsänderungen gibt. Ich habe im Hintergrund noch andere Fälle mit ähnlichem Hintergrund laufen und wir sind definitiv schon länger einem sehr komplizierten LCP Echo Request Fehler auf der Spur. Die Hersteller sind auch bereits informiert und arbeiten mit Hochdruck an einer Lösung. Leider gibt es immer noch keine konkreten Antworten. Vielleicht gibt es bei ihrem Router irgendwie die Möglichkeit, die Einwahl regelmäßiger zu wiederholen, um das Problem so zu umgehen. Das hat bei einigen unserer Endgeräte mit einem ähnlichem Fehlerbild auch geholfen(Speedport Smart 3, Speedport 925V). Ansonsten muss vorerst ein anderer Router/Modem vorgeschaltet werden. Bisher fehlerfrei liefen die FB7530/60/90 bei gleichem/ähnlichem Fehlerbild.
Mit freundlichem Gruß Marlon K.
3
Answer
from
5 years ago
@Marlon K.
Vielen Dank für die Rückmeldung und den Logauszug, das hat mir in der Tat sehr weitergeholfen!
Tatsächlich konnte ich das Problem lokalisieren - um es jedoch vorweg zu nehmen: Die Ursache liegt nicht an meinen Endgeräten.
Aber zunächst etwas mehr zum Hintergrund:
Ich nutze den Telekom DSL-Anschluss primär für die Telefonie als Ersatz für einen ISDN-Anschluss.
Als Internetzugang nutze ich einen FTTH -Anschluss eines anderen Providers, sollte dieser einmal ausfallen dient der Telekom DSL-Anschluss als Backup.
D.h. im Normalbetrieb läuft über den Telekom DSL-Anschluss kaum Traffic (gelegentliche SIP-Keepalives + ein paar VoIP-Anrufe pro Woche).
Zusätzlich muss ich auch noch sagen, dass ich beruflich selbst im ISP -Umfeld tätig bin, d.h. BNGs, RADIUS , PPP & Co. sind mir nicht fremd.
Nun ins Detail:
Die Begründung, dass das Kundenendgerät nicht auf LCP-Keepalives des BNGs antwortet ist (zumindest in diesem Fall) - mit Verlaub - Quatsch.
LCP Keepalives Requests werden gewöhnlich von beiden Seiten ( BNG & Kundenrouter) generiert und das in Intervallen von standardmäßig 10 Sekunden (bei Cisco-Geräten) bzw. 30 Sekunden (bei Juniper-Geräten). Andere Hersteller haben da u.U. andere Intervalle, i.d.R. lässt sich das aber auch manuell konfigurieren.
Werden die LCP Keepalives Requests mehrfach (afaik 3-4x) nicht von der Gegenseite mit einem LCP Keepalives Reply beantwortet wird dies als Timeout gewertet und die PPP-Verbindung wird getrennt.
Wenn es hierbei irgendwelche Probleme geben würde (was durchaus möglich ist!), dann würden diese mit ziemlicher Sicherheit nicht regelmäßig alle 2 Stunden (d.h. nach mehreren Hundert erfolgreichen Request-/Reply-Vorgängen) auftreten sondern vermutlich schon viel früher und weniger deterministisch.
Des weiteren kann & konnte ich über einen Packet-Capture nachvollziehen, dass dies - auch zum Zeitpunkt der Verbindungstrennung - einwandfrei ohne Timeouts funktioniert (ein derartiges Capture könnte man übrigens auch von der BNG -seite aus durchführen...).
Was mir jedoch im Logauszug aufgefallen ist, ist folgende Zeile:
Feb 5 12:03:09.814799 [...] session-id:41796185 state:log-out [...] reason: aaa shutdown-idle-timeout
Die Zeile sagt aus, dass der BNG die Verbindung aktiv trennt und zwar aufgrund von Inaktivität, d.h. weil zu wenig (oder gar kein) Datenverkehr über die PPP-Session fließt!
Diese "Theorie" konnte ich auch bestätigen indem ich seit heute ca. 12:00 Uhr künstlich etwas mehr Traffic auf die Leitung gebe (Dauerping zu einigen Zielen im Internet):
Die letzte Trennung war heute um 10:31 Uhr, die nächste "planmäßige Verbindungstrennung" hätte um demnach um ca. 12:30 Uhr stattfinden "sollen" - dies ist aber nicht passiert, die Einwahl / PPP-Session ist nun seit fast 5 Stunden aktiv & stabil. Und die Endgeräte sind die Gleichen.
D.h. es gibt in der Konfiguration Telekom-seitig einen Idle-Timeout welcher Verbindungen mit wenig oder gar keinem Datenverkehr aktiv beendet.
Diese Konfiguration befindet sich _vermutlich_ irgendwo in einem Default-Profil auf den RADIUS -Servern und _vermutlich_ werden zwei RADIUS -Server im Loadsharing verwendet welche (bewusst oder unbewusst) leicht unterschiedlich konfiguriert sind - das würde zumindest die abweichenden Intervalle von 6900 & 7200 Sekunden erklären.
Auf dem BNG sollte sich das Vorhandensein für eine aktive Session auch mit dem Befehl "show subscribers interface demux0.<passende-id-einfügen> extensive" nachvollziehen lassen.
Dass es diesen Idle-Timeout gibt ist IMHO an sich nicht grundsätzlich falsch da es auf einem BNG immer mal wieder "hängende" tote Sessions gibt welche unnötig Ressourcen belegen welche dadurch bereinigt werden.
Allerdings würde ich persönlich den Timeout von 2 Stunden überdenken und diesen vielleicht auf 12 oder 24 Stunden setzen, allein um die Menge der Session-Changes zu limitieren (welche auch Resourcen kosten...) und die Wahrscheinlichkeit von "Kollateralschäden" wie in meinem speziellen Fall auf ein Mindestmaß zu reduzieren (2 Stunden mit ohne oder mit wenig Traffic ist wahrscheinlicher als 24 oder mehr Stunden...).
Des weiteren wäre es natürlich auch gut, wenn derartige Dinge irgendwo für den Kunden zugänglich dokumentiert wären... (Schnittstellenbeschreibung, FAQ, etc.)
Vielleicht kann man das ja mal an die zuständigen Kollegen weitergeben, möglicherweise hilft es ja auch anderen Kunden.
Und eine andere hilfreiche Sache wäre, die (eigenen) Logs zu lesen und richtig zu interpretieren... (wenn ich mir diesen "Seitenhieb" einmal erlauben darf...)
Answer
from
5 years ago
Answer
from
5 years ago
@Marlon K.
Alles klar, danke, dann bin ich mal gespannt!
Sollte ich noch irgendwie unterstützen können stehe ich gerne zur Verfügung!
Unlogged in user
Answer
from
Unlogged in user
Ask
from