Problem mid Telekom Glasfaser, wie kann ich die richtigen informationen ins Ticket übermitteln
vor einem Monat
Hi,
Ich habe seid Anfang März ein wildes problem mit meinem FTH Anschluss. ca alle 2 Stunden bricht die ppoe sitzung (echo reply fehler) und baut sich nach 30 sekunden wieder auf. Anschluss ist von der Dämpfung perfect, Kabel von meiner Dreambox (Unifi) zum Glasfasermodem ist getauscht, alle Geräte mehrfach rebootet und auf der letzten softwareversion.
Jetzt hatte ich den Techniker vor Ort und gehe den Weg lokale hardware zu tauschen, die unbekannte UDM durch fritzbox zu ersetzen usw. ein Prozess der lange dauert, desen Begründung ich verstehe und den ich natürlich supporte. Allerdings wird er nicht zum Erfolg führen und ich weiss nicht wie ich dies abkürzen kann.
Warum ist das so ? Der Abbruch findet erst seit dem 5.3. statt, mit unveränderter Software und hardware auf meiner seite. Und ausserhalb des 50 sekunden reconnects ist die Verbindung perfect, kein Packetverlust, kein Slowdown, konstant gute Geschwindigkeit ....
Aber vor allem kommen die reconnect reproduzierbar im 2 Stunden Raster (kann auch mal 1 oder 3 sein) und vor allem immer zur gleichen "Minute". Am 5.3. fand der erster reconnect um 22:57 statt. seid dem schiebt sich die Minute konstant über ca. 30 sekunden nach hinten, aktuell bei :24. Dieser Rythmus verändert sich nie und ist sehr konstant über die letzten Tage. Wenn der Fehler inkl. eines Timeouts in einem meiner Geräte liegen würde so würde sich das schema nach Neustart oder reboot verändern. Selbst wenn ein Fehler einen konstanten Timeout auslösen würde, so würde dieser nach Neustart neu anlaufen und sich das Schema der minutenwerte deutlich verändern .....
Für mich sieht es eher nach einer Softwarekomponente oder configuration auf seiten des Telekom PPOE servers oder der authenifizierung aus. Das zeitliche Schema passt perfect zu einem 1 Stunden Timeout (wobei meist jeder zweite zu einem vollständigen Abbruch führt). Die Verschiebung im Minutenraster lassen sich sehr gut durch erkennungszeiten (3 pings bei mir) und die Verzögerung im Sessionaufbau erklären.
Nun ist es aber so das im aktuellen Ticket der Prozess abgearbeitet wird, Kabel und ONT sind schon getauscht. Im nächsten Schritt wird es die UDM sein und man mich fragen ein Referenzgerät zu benutzen, dann eventuell das Modem näher am Router plazieren. Ich mache das gerne mit aber nichts davon erklärt das Zeitraster und irgendwie will aktuell niemand diese information aufnehmen oder auch nur berücksichtigen :(
Hilfe needed, I guess.
126
0
38
Das könnte Ihnen auch weiterhelfen
537
0
2
130
0
6
346
0
9
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor einem Monat
Welches SFP Modul hast du drin?
Hat die Telekom direkt ausgebaut oder wars die Glasfaser Nordwest?
0
0
vor einem Monat
telekom direkt ausgebaut. und ich nutze kein sfp modul (hatte von Temperaturproblemen gehört.
Die UDM baut eine PPOE über 2.5GB/lan mit dem Glasfasermodem der Telekom auf.
0
0
vor einem Monat
Hast du mal die Pigtails abgezogen? ggf. hast du dort Staubkörner drauf.
0
0
vor einem Monat
ja, alles durchgemessen und gut, würde auch alles nicht die regelmäßigkeit erklären die eigentlich der stärkste Hinweis auf eine Serverkomponente bzw. Konfiguration ist.
Aktuell hoffe ich das der ONT wechsel hier mittlebar hilft da er serverseitig im BRAS/ BNG vermutlich auch eine Configchange anstößt.
0
22
von
vor einem Monat
Guten Tag @Codingfragments , der Außendienst hat ja aktuell eine Messung bis Freitag angestoßen. Halte uns gerne auf dem Laufenden.
Viele Grüße Sven
0
von
vor einem Monat
Aktuell scheint die Verbindung stabil. Mal sehen ob es so bleibt.
0
von
vor einem Monat
Wunderbar. Wie Sven bereits schrieb, gib uns einfach Bescheid, wie es sich entwickelt.
Viele Grüße
Jonas
0
Uneingeloggter Nutzer
von
vor einem Monat
LCP
ja, als nächstes dann vermutlich ein refferenzgerät mit einer höheren LCP timeout ... (udm macht 3 failed echo mit 10 sec cadence. ) Es kann durchaus sein das es mit einer Fritzbox im 5/30 raster funktioniert (ändert nichts daran das trotzdem jede zweite Stunde die Session für 60 sekunden steht, alle Zoom-calls abbrechen und ich meine Backup logik ändern muss.
Meine Wahrnehmung ist leider das Informationen die ich liefern kann nicht im Case berücksichtigt werden. Gibt es hier für mich einen Weg das Augenmerk auf die Serverseite zu legen denn :
1) es gibt keinen sinnvollen Grund warum einen Kundenseitige Kabelstörung eine Störung exakt im Stundenraster verursachen sollte, und das über Wochen im selben Raster
2) es gibt keine sinnvollen Grund warum eine Kundenseitige Softwarestörung vorliegt die im Stundenraster zum Abbruch führt, natürlich ist ein Timeout oder ähnliches (Buffer overflow, ... ) denkbar der genau jeweils eine Stunde nach connect einen Abbruch auslöst entweder im ONT oder dem Router ABER desen Raster hätte sich dann beim Restart verschoben, also Probleme bei minutet 20 dann neustart bei minute 40 ab dann Probleme im Stundenraster bei minute 42 .... ) Das ist aber nicht der fall. Dir Abbrüche finden im Stundenraster statt aber seit Wochen auf der selben Minute (bzw. einer erklärbaren Verschiebung die sich durche eine Stunden timeout + 50-90 Sekunden reconnect ergibt. Um konstant diesen wert "wandert" das ereigniss ...
3) tcpdumps und ppoe logs belegen eine ultra-stabile verbindung bis eben zum problem, dann sofortiger reconnect und wieder Stabili
Vor allem das Minutenscharfe Stundenraster über Wochen deutet klar auf ein Problem im bereich server (software) hin, das entweder durch eine Konfiguration oder update Anfang März aufgetreten ist.
Nur, will diese Diagnosedaten aktuell niemand sehen :(. Könnt ihr da helfen oder wie ist mein weiterer Weg ?
Und ja, ich mache das (diagnose von netzwerk und software incidents) beruflich, bzw. habe es lange jahre hands on gemacht. Ich verstehe das euer Team prozessen folgt :(
@Codingfragments
Dann zeig uns doch mal einen Screenshot von den LCP Paketen im wireshark mit Zeitstempel und VLAN Prio.
Welche Firmware läuft denn auf dem Glasfasermodem? Gibt es im Modem ein Log wo man das letzte Update zeitlich nachvollziehen könnte?
0
0
vor einem Monat
siehe oben, Logs des modems sind ja für den Kunden nicht einsehbar. Wobei wieder Firmware version noch updates in der Heiminfra sinn machen. Siehe die Zeitkonstants. Der Fehler liegt eindeutig in der Server-Infra (vermutlich im BNG ) ansonsten wäre der zeitliche Verlauf ein anderer. Und an genau das Team komme ich nicht hin.
0
0
vor einem Monat
siehe oben, Logs des modems sind ja für den Kunden nicht einsehbar.
siehe oben, Logs des modems sind ja für den Kunden nicht einsehbar. Wobei wieder Firmware version noch updates in der Heiminfra sinn machen. Siehe die Zeitkonstants. Der Fehler liegt eindeutig in der Server-Infra (vermutlich im BNG ) ansonsten wäre der zeitliche Verlauf ein anderer. Und an genau das Team komme ich nicht hin.
@Codingfragments
Weißt Du das oder nimmst Du das nur an? Jedes Telekom Gerät welches ich kenne, das eine GUI für Firmware-Updates hat, hat auch ein Log. Deswegen gehe ich eigentlich davon aus, dass auch das Modem ein Log hat, aber wissen tue ich es nicht, ich habe ja nur einen DSL-Anschluss.
Auf jeden Fall sieht man die Verbindungswerte, was auch schon hilfreich sein könnte.
anbei noch der screenshot
anbei noch der screenshot, wobei, wie gesagt, ich der Telekom auch gerne die pcaps zur verfügung stellen kann. Im Screenshot zu sehen der letzte fehler.
Wäre schöner mit lesbaren Zeitstempeln und Screenshots von der VLAN Prio der ausgehenden LCP Pakete fehlen komplett.
0
1
von
vor einem Monat
Das ONT ist ein passiver Terminator (mostly) nur Telekom hat hier Zugriff auf die Logs
0
Uneingeloggter Nutzer
von
vor einem Monat
Vlan prio ist ein red-herring, der gesammte traffic im tcpdump ist im vlan 7 auf dem ppoe interface, also richtiges vlan und ausserhalb der incidents ohne jegliche probleme.
Die Zeitkonstanz ist der relevante Hinweis zur weiteren Fehlersuche, hier eine Analyse des Verhaltens.
Überprüft wurde die Hypothese das seit dem 4.3 ein 60 minuten timeout fenster auf dem Backend entstanden ist was ca. in 50 der Fälle zum Verbindungsabbruch serverseitig führt. Die Analyse zeigt das matching basierend auf einem fixen raster.
Sollte der Grund für den Ausfall auf Kundenseite liege (denkbar) so würde hier spätestens ab dem ersten restart eine Abweichung vom Zeitraster sichtbar sein denn das Raster folgt der annahme das der Rythmus seit dem 4.3 konstant fortgeschrieben wird (konkreter window fit 60min+24 sekunden).
Auf meiner seite sind alle Geräte mehrfach neu gestartet, unter anderm war mein gesammter Netzwerkstack letzte woche 5 minuten Stromlos ...
Die Ausreißer im graph korrespondieren mit manuellen disconnects, restarts und Fehlersuche. sind also zu erklären.
Die konstanz der Ereignisse schließt meiner Überzeugung auch physische Gründe, flackyness, Kabelverbindungen o.ä. aus.
Aktuelle Hypothese
0
0
vor einem Monat
Vlan prio ist ein red-herring, der gesammte traffic im tcpdump ist im vlan 7 auf dem ppoe interface, also richtiges vlan und ausserhalb der incidents ohne jegliche probleme.
Vlan prio ist ein red-herring, der gesammte traffic im tcpdump ist im vlan 7 auf dem ppoe interface, also richtiges vlan und ausserhalb der incidents ohne jegliche probleme.
Die Zeitkonstanz ist der relevante Hinweis zur weiteren Fehlersuche, hier eine Analyse des Verhaltens.
Überprüft wurde die Hypothese das seit dem 4.3 ein 60 minuten timeout fenster auf dem Backend entstanden ist was ca. in 50 der Fälle zum Verbindungsabbruch serverseitig führt. Die Analyse zeigt das matching basierend auf einem fixen raster.
Sollte der Grund für den Ausfall auf Kundenseite liege (denkbar) so würde hier spätestens ab dem ersten restart eine Abweichung vom Zeitraster sichtbar sein denn das Raster folgt der annahme das der Rythmus seit dem 4.3 konstant fortgeschrieben wird (konkreter window fit 60min+24 sekunden).
Auf meiner seite sind alle Geräte mehrfach neu gestartet, unter anderm war mein gesammter Netzwerkstack letzte woche 5 minuten Stromlos ...
Die Ausreißer im graph korrespondieren mit manuellen disconnects, restarts und Fehlersuche. sind also zu erklären.
Die konstanz der Ereignisse schließt meiner Überzeugung auch physische Gründe, flackyness, Kabelverbindungen o.ä. aus.
Aktuelle Hypothese
@Codingfragments
Du weißt scheinbar nicht mal, was die PRIO ist. Sieht im Wireshark so aus und muss bei LCP Paketen auf 6 stehen:
0
4
von
vor einem Monat
Da kommt jetzt Nix mehr ? Danke
0
von
vor einem Monat
Da kommt jetzt Nix mehr ? Danke
@Codingfragments
Du bist ja offensichtlich nicht an Hilfe und einer Problemlösung interessiert, also verschwende ich hier keine Zeit mehr.
0
von
vor einem Monat
Ich bin interessiert.
Aber es hilft halt nicht wenn Personen antworten die mein Antwort nicht bis zu Ende lesen, sondern mich sofort dissen sobald sie ein Schlüsselwort lesen. Mit allem Respekt aber das hast du hier getan :(
Du: Wäre schöner mit lesbaren Zeitstempeln und Screenshots von der VLAN Prio der ausgehenden LCP Pakete fehlen komplett.
Ich: Vlan prio ist ein red-herring, der gesammte traffic im tcpdump ist im vlan 7 auf dem ppoe interface, also richtiges vlan und ausserhalb der incidents ohne jegliche probleme
Du: Du weißt scheinbar nicht mal, was die PRIO ist. Sieht im Wireshark so aus und muss bei LCP Paketen auf 6 stehen
Ich hatte dir in meiner Antwort schon geschrieben das mir die VLan problematik klar ist, aber hier irrelevant da ich direct auf dem Vlan den dump ziehe .... und ausserdem mit falscher Vlan prio oder konfig hätte ich niemals konstant 60 min eine gute Verbindung.
Auch ist der konkretet (absolute) Zeitstempel irrelevant im Dump.
Sorry, das ich dann etwas angefressen rüber kam.
0
Uneingeloggter Nutzer
von
vor einem Monat
@Codingfragments
Schaue doch mal auf die GUI vom Modem. Da sollte man auch die Verbindungszeit/-qualität und vermutlich ein Log sehen können. Vielleicht stört irgendwas im Heimnetz die Stromversorgung und sorgt für einen Verbindungsverlust vom Modem, da gibt es so viele Möglichkeiten, hat hier schon die komischsten Dinge über die Jahre gegeben.
Die Möglichkeit, dass nur Dein Anschluss falsch "konfiguriert" ist, halte ich für sehr unwahrscheinlich. Da wären schon etliche Anschlüsse betroffen und dann sollte das auch bei der Telekom schon aufgefallen sein.
0
1
von
vor einem Monat
ALLES gute Hinweise, wie auch alles der Technik, und ich bin wirklich DANKBAR über euer Engagment.
...... ABER ....
könntet ihr vieleicht, nur vieleicht einmal auf die Zeitkonstanz eingehen, und wie diese mit irgendeiner Erklärung ausser dem Fehler auf dem Backend korrelieren kann.
Desweiteren:
Sorry, ich bin wirklich über Hilfe froh, aber bitte arbeitet doch mit allen Daten und vor allem suche ich verzweifelt nach einer Möglichkeit das die Telekom experten die Gesammtsicht der Daten bekommen :(
0
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von