‎Internetverbindung wird alle 2 Stunden getrennt

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Internetverbindung wird alle 2 Stunden getrennt

vor 5 Jahren

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://telekomhilft.telekom.de/t5/Telefonie-Internet/Internetverbindung-wird-staendig-getrennt/m-p/3241964

- https://telekomhilft.telekom.de/t5/Telefonie-Internet/Alle-2-Stunden-Abbruch-der-Internetverbindung/m-p/3066482

- https://telekomhilft.telekom.de/t5/Telefonie-Internet/Internetabbruch-etwa-alle-zwei-Stunden/td-p/3036506

- https://telekomhilft.telekom.de/t5/Telefonie-Internet/Alle-2-Stunden-Abbruch-der-Internetverbindung/td-p/3201510

- https://telekomhilft.telekom.de/t5/Telefonie-Internet/Alle-2-Stunden-wird-die-Verbindung-getrennt-FritzBox-7490/td-p/3209088

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

1390

vor 5 Jahren
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
vor 5 Jahren
Ohja .. natürlich kein Einzellfall!

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
0
vor 5 Jahren
@cm42 Ich hab das heute nicht zum ersten Mal gehört. Ich geb dein Ticket weiter an unsere Kollegen von der Netztechnik zur Analyse. Sobald ich Rückmeldung erhalte, gebe ich dir hier Bescheid. Mit freundlichem Gruß Marlon K.
0
3
Antwort
von
vor 5 Jahren
@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 .

0
Antwort
von
vor 5 Jahren
@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.
0
Antwort
von
vor 5 Jahren
@cm42 Ich hab das richtige Ticket erwischt. Die Fehlerbeschreibung mit LCP Echo Request im zwei Stundentakt reicht aus. Die Kollegen prüfen ihre eigenen Logs. Deine genauen Daten finden wir über deine Kundennummer. Es reicht also wirklich, wenn Du dein Profil füllst. Wenn wir Auszüge brauchen, dann sagen wir in der Regel Bescheid oder lassen sie uns als private Nachricht zukommen. Du kannst also deine Daten gern wieder löschen hier im Post. Mit freundlichem Gruß Marlon K.
0
Uneingeloggter Nutzer
Antwort
von
vor 5 Jahren
@CM Die Kollegen konnten im ersten Step keinen Fehler finden. Ich lasse jetzt am Freitag den DSL Port tauschen auf Verdacht. Dafür brauchen sie nicht anwesend sein. Mit freundlichem Gruß Marlon K.
0
2
Antwort
von
vor 5 Jahren
@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.
0
Antwort
von
vor 5 Jahren
@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.
0
Uneingeloggter Nutzer
Antwort
von
vor 5 Jahren
@cm42 Hast Du den Fehler jetzt aktuell immer noch? Ich hatte mittlerweile mehrere Fälle mit deinem Fehlerbild. Die anderen haben heute alle Entwarnungen gegeben. Es scheint doch ein zentraler Fehler gewesen zu sein, der jetzt wieder gepatched wurde. Falls es bei dir immer noch nicht läuft, dann muss ich noch ein neues Ticket speziell für dich aufmachen. Mit freundlichem Gruß Marlon K.
0
1
Antwort
von
vor 5 Jahren
@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.

0
Uneingeloggter Nutzer
Antwort
von
vor 5 Jahren
@cm42 Alles klar, tut mir Leid, dass es bei dir noch nicht läuft. Ich habe erneut ein Ticket an die Technik Infrastruktur weitergeleitet. Mit freundlichem Gruß Marlon K.
0
0
vor 5 Jahren
@cm42 Nur als Zwischenmeldung: Das Ticket läuft noch. Mit freundlichem Gruß Marlon K.
0
0
vor 5 Jahren
@cm42 Die Kollegen aus dem Second Level haben zurückgemeldet, dass die Firmware auf dem Modem/Router nicht aktuell ist. Der Fehler soll damit beseitigt werden. Mit freundlichem Gruß Marlon K.
0
1
Antwort
von
vor 5 Jahren
@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.
0
Uneingeloggter Nutzer
Antwort
von
vor 5 Jahren
@cm42 Ich gebe das wieder so weiter, bitte die aktuelle FW auf dem Modem lassen, damit die Kollegen sehen, dass dies gemacht wurde. Mit freundlichem Gruß Marlon K.
0
1
Antwort
von
vor 5 Jahren
@Marlon K.
Gibt es hier bereits irgendwelche Neuigkeiten?

Danke vorab!
0
Uneingeloggter Nutzer
Antwort
von
vor 5 Jahren
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.
0
3
Antwort
von
vor 5 Jahren
@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...)

Antwort
von
vor 5 Jahren
@cm42 Vielen Dank für deine ausführliche Antwort. Ich glaube Du bist da etwas auf der Spur Ich habe deine Antwort an meine Kollegen weitergeleitet und auch noch an eine Expertenkomission, die sich hier intern mit einem ähnlichen Fehlerbild beschäftigt. Ich muss jetzt erst Mal wieder die Rückmeldungen abwarten. Sobald ich etwas höre, werde ich dir hier Bescheid geben. Mit freundlichem Gruß Marlon K.
0
Antwort
von
vor 5 Jahren
@Marlon K.
Alles klar, danke, dann bin ich mal gespannt!
Sollte ich noch irgendwie unterstützen können stehe ich gerne zur Verfügung!
0
Uneingeloggter Nutzer
Antwort
von