1781VA an Telekom VVDSL: Verbindungs-Unterbrechungen

[backslash]

Hi fildercom,

also wenn das wirklich alles ist, was im PPP-Trace zum Zeitpunkt des Abbaus drinstand (also vor dem PADT nichst stand, was auf einen Abbau hindeutet), dann ist das eindeutig ein Problem des Providers, dann dann hat der Access-Concentrator die Verbindung hart mit einem PADT (PPPoe Active Discovery Terminate) beendet - das hat die Telekom früher gerne für die Zwangstrennung alle 24 Stunden genutzt

Code: Alles auswählen

[PPP] 2019/06/16 12:45:02,390  Devicetime: 2019/06/16 12:45:01,713

Received PADT frame from peer 00:31:46:XX:XX:XX for session 5a00

Gruß
Backslash

[fildercom]

Hallo backslash,

danke für die Info. Ich poste mal einige Zeilen vorher:

Code: Alles auswählen

[PPP] 2019/06/16 12:41:31,450  Devicetime: 2019/06/16 12:41:30,768

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID a7 and length 8 for peer TELEKOM
Sending LCP echo-response with ID a7 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/16 12:41:57,482  Devicetime: 2019/06/16 12:41:56,798

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/16 12:42:01,466  Devicetime: 2019/06/16 12:42:00,781

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID a8 and length 8 for peer TELEKOM
Sending LCP echo-response with ID a8 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/16 12:42:31,467  Devicetime: 2019/06/16 12:42:30,795

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID a9 and length 8 for peer TELEKOM
Sending LCP echo-response with ID a9 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/16 12:42:47,482  Devicetime: 2019/06/16 12:42:46,798

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/16 12:43:01,483  Devicetime: 2019/06/16 12:43:00,809

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID aa and length 8 for peer TELEKOM
Sending LCP echo-response with ID aa and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/16 12:43:37,483  Devicetime: 2019/06/16 12:43:36,798

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/16 12:44:27,468  Devicetime: 2019/06/16 12:44:26,798

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/16 12:45:02,390  Devicetime: 2019/06/16 12:45:01,713

Received PADT frame from peer 00:31:46:XX:XX:XX for session 5a00

[PPP] 2019/06/16 12:45:02,390  Devicetime: 2019/06/16 12:45:01,713

Transmit PADT frame to peer 00:31:46:XX:XX:XX for session 5a00

[PPP] 2019/06/16 12:45:02,390  Devicetime: 2019/06/16 12:45:01,713
Change phase to DEAD for TELEKOM
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer
Stopping IPV6CP restart timer

Da ist doch nichts weiter zu sehen, was eine Trennung von Seiten des Routers andeuten würde? Also doch ein Telekom-Problem, oder? Dann ist nur die Frage, wie ich die Telekom dazu bekomme, das Ticket an die zuständige Organisationseinheit zu eskalieren? Das ist dann definitiv kein Fall für den Telekom Außendienst mehr.

Viele Grüße und danke
fildercom.

[backslash]

Hi fildercom,

da kommt das PADT aus LANCOM-Sicht eindeutig unvermittelt während der laufenden Verbindung....

Der Provider schickt alle 30 Sekunden ein Echo-Request, das vom LANCOM beantwortet wird. Es gibt keinen Hinweis darauf, daß das Echo-Reply nicht beim Provider ankommt - denn in einem solchen Fall, müßte er vor der Trennung eigentlich meherer Echo-Requests in einem kürzeren Intervall wiederholen, um einen einmaligen Paketverlust ausschließen zu können.

Stattdessen wird in der letzten Minute KEIN Echo-Request mehr vom Provider empfangen - wohl aber noch normale Datenpakete, denn das LANCOM selbst unterdückt seine eigenen Echo-Requests aufgrund dessen:

Code: Alles auswählen

[PPP] 2019/06/16 12:43:37,483  Devicetime: 2019/06/16 12:43:36,798

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/16 12:44:27,468  Devicetime: 2019/06/16 12:44:26,798

LCP polling timeout for peer TELEKOM - data received during last interval

Da keine Echo-Requests ankommen, werden auch keine beantwortet. Wenn die nun also irgendwo auf der Strecke vom Provider zum LANCOM verloren gehen, dann könnte der Access-Concentrator tatsächlich meinen, die Verbindung wäre gestört. Da aber offensichtlich weiterhin Nutzdaten ankommen (das LANCOM unterdrückt ja seine Echo-Requests) ist das in meinen Augen definitiv ein Problem des Providers...

Gruß
Backslash

[fildercom]

Hallo backslash,

danke für die ausführliche Erklärung. Ich bin mir nicht sicher, ob es relevant ist, aber Folgendes:
Die Einträge mit dem "LCP Polling timeout" habe ich im PPP-Trace ständig, nicht nur unmittelbar vor dem Abbruch der Verbindung.

Und: Auch auf dem zweiten 1781VA, welcher an einem Telekom DeutschlandLAN mit ADSL2+ Annex J mit dynamischer IP eingesetzt wird, sind diese Einträge ständig im PPP-Trace enthalten. Wie gesagt, auf dem Gerät gibt es keine Abbrüche. Hier ein Auszug aus dem Trace des nicht betrofennen Anschlusses/Routers:

Code: Alles auswählen

[PPP] 2019/06/17 21:01:09,007  Devicetime: 2019/06/17 21:01:09,421

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 2c and length 8 for peer TELEKOM
Sending LCP echo-response with ID 2c and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:01:32,594  Devicetime: 2019/06/17 21:01:33,010

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/17 21:01:39,015  Devicetime: 2019/06/17 21:01:39,422

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 2d and length 8 for peer TELEKOM
Sending LCP echo-response with ID 2d and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:02:09,013  Devicetime: 2019/06/17 21:02:09,423

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 2e and length 8 for peer TELEKOM
Sending LCP echo-response with ID 2e and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:02:22,590  Devicetime: 2019/06/17 21:02:23,010

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/17 21:02:39,011  Devicetime: 2019/06/17 21:02:39,425

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 2f and length 8 for peer TELEKOM
Sending LCP echo-response with ID 2f and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:03:09,013  Devicetime: 2019/06/17 21:03:09,426

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 30 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 30 and length 8 to peer TELEKOM (channel 1)

[PPP] 2019/06/17 21:03:12,575  Devicetime: 2019/06/17 21:03:13,010

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/17 21:03:39,001  Devicetime: 2019/06/17 21:03:39,428

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 31 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 31 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:04:02,594  Devicetime: 2019/06/17 21:04:03,010

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/17 21:04:09,007  Devicetime: 2019/06/17 21:04:09,429

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 32 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 32 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:04:39,000  Devicetime: 2019/06/17 21:04:39,431

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 33 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 33 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:04:52,578  Devicetime: 2019/06/17 21:04:53,010

LCP polling timeout for peer TELEKOM - data received during last interval


[PPP] 2019/06/17 21:05:09,001  Devicetime: 2019/06/17 21:05:09,433

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 34 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 34 and length 8 to peer TELEKOM (channel 1)


[PPP] 2019/06/17 21:05:39,000  Devicetime: 2019/06/17 21:05:39,434

Received LCP frame from peer TELEKOM (channel 1)
LCP echo-request with ID 35 and length 8 for peer TELEKOM
Sending LCP echo-response with ID 35 and length 8 to peer TELEKOM (channel 1)

[PPP] 2019/06/17 21:05:42,594  Devicetime: 2019/06/17 21:05:43,010

LCP polling timeout for peer TELEKOM - data received during last interval

Gibt es da etwa ein generelles Problem mit dem LCP Polling Timeout oder ist das "normal"?

Viele Grüße und danke
fildercom.

[Björn]

Hey, wie sieht denn bei dir /Setup/WAN/PPP aus?

(Interessieren würde mich Time, Try, Conf, Fail und Term)

Gruß Björn

[MoinMoin]

Moin fildercom,

Gibt es da etwa ein generelles Problem mit dem LCP Polling Timeout oder ist das "normal"?

Das ist normal. Das LANCOM prüft regelmäßig (das ist besagter Timeout), ob zwischenzeitlich von der Gegenseite ein Pollpaket oder Daten gekommen sind. Wenn nicht, dann schickt das LANCOM selber ein Pollpaket.

Ciao, Georg

[fildercom]

Hey, wie sieht denn bei dir /Setup/WAN/PPP aus?

(Interessieren würde mich Time, Try, Conf, Fail und Term)

Gruß Björn

Hallo,

hier kommen die gewünschten Informationen:

PPP.JPG

Ich denke, dass da alles passen sollte.

@ MoinMoin: Danke für die Information. Dann ist also nicht davon auszugehen, dass hier ein generelles Problem vorliegt, sondern wirklich nur der eine gestörte Anschluss.

Gruß
fildercom.

[Björn]

Sieht leider echt ok aus :/

[MDCYP]

Kannst du das Gerät am Wochenende vllt mal an einem andren DSL Anschluss testen?

[fildercom]

Kannst du das Gerät am Wochenende vllt mal an einem andren DSL Anschluss testen?

... das wird momentan leider etwas schwierig, ich brauche beide Anschlüsse so wie sie sind relativ intensiv und ein Tauschen bedeutet auch immer Zugangsdaten, Zertifikate etc. ändern. Den Aufwand kann ich gerade nicht betreiben.