1781VA an Telekom VVDSL: Verbindungs-Unterbrechungen

[fildercom]

Hallo zusammen,

seit ein paar Tagen habe ich vermehrt kurze Verbindungsabbrüche der PPPoE-Verbindung im Syslog stehen, wie z.B. diese hier:

Code: Alles auswählen

49	2019-05-05 12:50:44	AUTH	Info	Disconnected from peer TELEKOM: remote-disconnected
212	2019-05-04 22:26:28	AUTH	Info	Disconnected from peer TELEKOM: LCP-conn.-Error
213	2019-05-04 22:26:22	LOCAL0	Fehler	line polling to peer TELEKOM failed
491	2019-05-03 22:05:01	AUTH	Info	Disconnected from peer TELEKOM: remote-disconnected
1778	2019-04-30 05:47:08	AUTH	Info	Disconnected from peer TELEKOM: remote-disconnected
2462	2019-04-28 01:25:40	AUTH	Info	Disconnected from peer TELEKOM: remote-disconnected

Es ist kein Muster erkennbar, die installierte Version ist 10.20 RU5 bzw. seit dem 03.05.2019 die RU6.

Für mich sehen zumindest die "remote-disconnected"-Einträge so aus, als ob die Gegenstelle (der BNG der Telekom) dafür verantwortlich ist. Beim anderen Eintrag mit dem "LCP-conn.-Error" bin ich mir hingegen unsicher.

Doch bevor ich eine Störung melde (die dann leider nie direkt zur PTI geht, sondern immer erst zum Service), möchte ich gerne wissen, ob es nicht doch ein Geräte-/Softwareproblem sein kann.

Einen Trace zu erstellen wäre natürlich ideal, aber leider kündigt sich der Fehler nicht an und somit ist es schwer bis unmöglich, exakt zu dem Zeitpunkt eine Trace-Ausgabe zu erstellen.

Weiß jemand von euch mehr, was die Ursache sein kann und was man dagegen tun könnte?

Viele Grüße und herzlichen Dank
fildercom.

[fildercom]

Hallo zusammen,

das Problem ist noch immer/wieder da. Kann mir niemand ein paar Tipps geben, auf welcher Seite die Ursache liegen könnte?

Viele Grüße und danke
fildercom.

[fildercom]

Bevor ich bei der Telekom eine Störung melde muss ich wissen, dass der Fehler definitiv NICHT am LANCOM-Router liegen kann. Ich komme momentan einfach nicht weiter...

[MDCYP]

Zeig mal die Leitungswerte unter der Web Oberfläche vom Router

dann unter LCOS-Menübaum
-- Status > VDSL

[fildercom]

Hallo,

danke für wenigstens eine Antwort. Ich will mal kurz darauf eingehen.

Gerne kann ich die Werte posten, allerdings ist das absolut sinnfrei, da das Problem nicht auf Layer 1 (also Leitung zwischen DSLAM und eingebautem Modem des Routers) liegt, da der Sync nicht verloren geht, sondern ohne Unterbrechung besteht.

Das Problem ist auf PPPoE-Ebene, also auf Layer 2. So langsam aber sicher habe ich das LCOS 10.20 RU6 im Verdacht, dass dieses irgend einen Bug hat (welcher eventuell nur in Verbindung mit VRRP auftritt) und für die Disconnects verantwortlich ist. Daher habe ich nun testweise auf RU5 umgestellt und werde beobachten.

Gruß
fildercom.

[fildercom]

Wie im ersten Posting geschrieben, ist der Fehler in der RU5 ebenfalls vorhanden. Ich habe nun auf die RU4 downgegraded und werde beobachten. Wenn das Problem auch dort vorhanden ist (mit dieser Version lief es früher einwandfrei), dann ist es entweder ein Gerätedefekt (eher unwahrscheinlich) oder doch eine Störung der Telekom.

[fildercom]

Auch mit der RU4 ist das Problem vorhanden. Folglich entweder ein Gerätedefekt oder wirklich eine Telekom-Störung.

Kann jemand von den Experten mit 100 %iger Sicherheit ausschließen, dass der Log-Eintrag "Remote Disconnected" definitiv kein Gerätedefekt sein kann? Denn ansonsten ist eine Störungsmeldung zwecklos und möglicherweise kostenpflichtig.

[alf29]

Moin,

Kann jemand von den Experten mit 100 %iger Sicherheit ausschließen, dass der Log-Eintrag "Remote Disconnected" definitiv kein Gerätedefekt sein kann? Denn ansonsten ist eine Störungsmeldung zwecklos und möglicherweise kostenpflichtig.

Ganz ehrlich: wer kann so etwas schon mit 100-komma-null-prozentiger Sicherheit?

Viele Grüße

Alfred

[fildercom]

Moin,

Kann jemand von den Experten mit 100 %iger Sicherheit ausschließen, dass der Log-Eintrag "Remote Disconnected" definitiv kein Gerätedefekt sein kann? Denn ansonsten ist eine Störungsmeldung zwecklos und möglicherweise kostenpflichtig.

Ganz ehrlich: wer kann so etwas schon mit 100-komma-null-prozentiger Sicherheit?

Viele Grüße

Alfred

Hallo Alfred,

klar, meine Formulierung war vielleicht etwas überspitzt gewählt, aber trotzdem wäre es hilfreich, wenn jemand Ursachen dieses Log-Eintrags nennen könnte.

Gruß und danke
fildercom.

[hyperjojo]

hallo,

poste doch mal die Leitungswerte, wie bereits oben geschrieben. Und beobachte diese am besten dauerhaft, damit du weißt, ob sich da während des Ausfalles etwas ändert.
Du könntest auch testweise mal ein externes Modem vor den LANCOM schalten und schauen, ob sie Ausfälle dann weniger/weg sind.

Gruß hyperjojo

[fildercom]

Hallo hyperjojo,

die Leitungswerte werde ich nachreichen, allerdings ist der Sync stabil und es gibt keine Veränderungen/Ausfälle. Das Problem besteht NICHT auf physikalischer Ebene, sondern einzig und allein die PPPoE-Verbindung wird kurz unterbrochen.

[MoinMoin]

Moin fildercom,

wenn du es schaffst, von dem "Ausfall" eine PPP-trace zu machen, dann kannst du nachsehen, warum die Verbindung abgebaut wird.

Ciao, Georg

[fildercom]

Hallo Georg,

das wäre in der Tat "schön", im Fehlerfall einen Trace machen zu können, aber da sich der Fehler nicht ankündigt und auch nicht selbst "nachstellen" lässt wird das sehr schwierig werden.

Hier noch die nachgereichten VDSL-Sync-Werte:

VDSL.JPG

Heute früh gab es Wartungsarbeiten und danach kam keine PPPoE-Verbindung mehr hoch. Jedes mal im Log "manual disconnect". Dann half nur die PPPoE-Gegenstelle komplett löschen (über den Assistenten), neu anlegen und manuell wieder nacharbeiten. Genau dasselbe Szenario hatte ich im Februar schon einmal, damals hatte ich auch eine Störung bei der Telekom gemeldet, jedoch wurde keine PTI hinzugezogen und das Ticket dann ohne Fehlerfindung/-behebung geschlossen. Seit dem Update des Telekom-BNG Anfang dieses Jahres habe ich solche seltsamen Störungen...

[fildercom]

Also ich habe eine Störung gemeldet, allerdings mit mäßigem Erfolg: Es wurde nur ein Line-Reset durchgeführt, der logischerweise nicht weitergeholfen hat. Interssantes Detail: Obwohl der Router synchron ist, "sieht" die Telekom das Gerät nicht. Da man leider keine Chance hat, mit der PTI direkt zu kommunizieren, wird die Fehlersuche schwierig bis unmöglich. Ist das ein Defekt des Routers? Ist es ein Bug im LCOS? Ist es ein Bug seit dem Update der Software des BNG? Wie soll man das herausfinden???

[fildercom]

Moin fildercom,

wenn du es schaffst, von dem "Ausfall" eine PPP-trace zu machen, dann kannst du nachsehen, warum die Verbindung abgebaut wird.

Ciao, Georg

So, durch ein Langzeit-Trace habe ich es geschafft, den Fehlerfall festzuhalten.

1. der dazugehörige Syslog-Ausschnitt:

Code: Alles auswählen

73	2019-06-16 12:45:08	AUTH	Hinweis	Successfully connected to peer TELEKOM
97	2019-06-16 12:45:01	AUTH	Info	Disconnected from peer TELEKOM: remote-disconnected

2. und hier der Auszug aus dem Trace:

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

[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

[PPP] 2019/06/16 12:45:03,407  Devicetime: 2019/06/16 12:45:02,736 VLAN-ID 7 chosen by Provider VLAN Selector

[PPP] 2019/06/16 12:45:03,626  Devicetime: 2019/06/16 12:45:02,950

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: XX XX XX XX XX XX XX XX

[PPP] 2019/06/16 12:45:03,673  Devicetime: 2019/06/16 12:45:03,036

Received PADO frame from peer 00:31:46:XX:XX:XX for session 0000
AC-Name: STGJ11, accepted
Host-ID: XX XX XX XX XX XX XX XX, accepted
Service: (any), accepted
Cookie:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX, accepted

[PPP] 2019/06/16 12:45:03,673  Devicetime: 2019/06/16 12:45:03,036

Transmit PADR frame to peer 00:31:46:62:0a:19 for session 0000
Host-ID: XX XX XX XX XX XX XX XX
Service: (any)
Cookie:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

[PPP] 2019/06/16 12:45:03,735  Devicetime: 2019/06/16 12:45:03,082

Received PADS frame from peer 00:31:46:62:0a:19 for session 5a45
Service: (any), accepted
Host-ID: XX XX XX XX XX XX XX XX, accepted
AC-Name: STGJ11, accepted
Cookie:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX, accepted

[PPP] 2019/06/16 12:45:03,735  Devicetime: 2019/06/16 12:45:03,082
Change phase to ESTABLISH for TELEKOM
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds

[PPP] 2019/06/16 12:45:03,907  Devicetime: 2019/06/16 12:45:03,131

Received LCP frame from peer TELEKOM (channel 1)
Stop waiting for connection
Stopping LCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer TELEKOM
Inserting local MRU 1492
Inserting local magic number XXXXXXXX
Sending LCP configure-request with ID 00 and length 14 to peer TELEKOM (channel 1)
Starting LCP restart timer with 3000 milliseconds
Evaluate configure-request with ID 7c and size 18
Peer MRU 1492 accepted
Peer requests authentication protocol PAP, accepted
Peer magic number XXXXXXXX accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID 7c and length 18 to peer TELEKOM (channel 1)

[PPP] 2019/06/16 12:45:03,907  Devicetime: 2019/06/16 12:45:03,231

Received LCP frame from peer TELEKOM (channel 1)
Evaluate configure-ack with ID 00 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for TELEKOM
Generating PAP-request for peer TELEKOM
Resolved peer as TELEKOM in PPP table

Sending PAP-request with ID 13, size 54 and peer-id XXXXXXXXXXXXXXXXXXXXXXXXXXX@t-online.de to peer TELEKOM (channel 1)
Stopping LCP restart timer


[PPP] 2019/06/16 12:45:08,907  Devicetime: 2019/06/16 12:45:08,231

Tx-Authentication retry timeout for peer TELEKOM
Generating PAP-request for peer TELEKOM
Resolved peer as TELEKOM in PPP table

Sending PAP-request with ID 14, size 54 and peer-id XXXXXXXXXXXXXXXXXXXXXXXXXXX@t-online.de to peer TELEKOM (channel 1)

[PPP] 2019/06/16 12:45:09,360  Devicetime: 2019/06/16 12:45:08,732

Received PAP frame from peer TELEKOM (channel 1)
Evaluate PAP ack with ID 14 and size 26
Embedded message: SRU=37000#SRD=103176#
This-Layer-Up action for LCP
Change phase to CALLBACK for TELEKOM
This-Layer-Up action for LCP
Change phase to NETWORK for TELEKOM
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer TELEKOM
Inserting IP address 0.0.0.0
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 22 to peer TELEKOM (channel 1)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2019/06/16 12:45:09,360  Devicetime: 2019/06/16 12:45:08,751

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-request with ID a2 and size 10
Peer requests IP address XX.XXX.XXX.XX, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID a2 and length 10 to peer TELEKOM (channel 1)

[PPP] 2019/06/16 12:45:09,360  Devicetime: 2019/06/16 12:45:08,751

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-nak with ID 00 and size 22
Peer NAKs IP address XX.XXX.XXX.XX, accepted
Peer NAKs primary DNS address 217.237.148.102, accepted
Peer NAKs secondary DNS address 217.237.151.115, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer TELEKOM
Inserting IP address XX.XXX.XXX.XX
Inserting primary DNS address 217.237.148.102
Inserting secondary DNS address 217.237.151.115
Sending IPCP configure-request with ID 02 and length 22 to peer TELEKOM (channel 1)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2019/06/16 12:45:09,579  Devicetime: 2019/06/16 12:45:08,911

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-ack with ID 02 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
This-Layer-Up action for IPCP
Stopping IPCP restart timer

Hinweis: Ich habe IP-Adressen, MAC-Adressen, Host-IDs usw. durch "XX..." ersetzt. Im Trace stehen natürlich die vollständigen Angaben.

So und nun? Wo liegt das Problem? Bei der Telekom? Auf dem LANCOM selbst? Im LCOS?

Ich hoffe sehr, dass die LANCOM-Experten hier im Forum jetzt einen heißen Tipp geben können.

Gruß und danke
fildercom.