Ständige PPPoE Disconnects an T-Com VDSL 100 (Manchmal 1-2x Täglich, manchmal 1,5 Wochen Ruhe)
Servus Gemeinde,
wie die Überschrift es schon verlauten lsst geht es um Tageszeitunabhängige, willkürliche Trennungen vom Internet, die mir den letzten Nerv rauben. Dieses Problem hat angefangen aufzutreten als ich eine neue Firewall bei mir daheim in Betrieb genommen habe. Ich bin von einer ZyXel ZyWall USG100 auf eine ZyXel USG 110 umgestiegen, da diese mehr Performance bietet. Als Modem verwende ich ein ZyXel VMG 1312-B30A welches im PPPoE pass through-Modus betrieben wird. Der Internetanschluss ist ein VDSL2 100 der Telekom mit Vectoring-Technologie.
Ich komme direkt aus der TAE-Dose mit einem CAT5.1 Netzwerkkabel von Dätwyler und gehe damit in den WAN-Port des ZyXel VMG 1312-B30A. Auf dem Modem ist eine Schnittstellen-Gruppe eingerichtet, welche das Bridging von dem WAN-Port auf einen Ethernet-Port ermöglicht. Das VLAN-Tag 7, welches ich für das VDSL der Telekom benötige wird ebenfalls am WAN-Port des Modems übergeben und ist somit auf diesem konfiguriert.
Die PPPoE-Einwahl macht die ZyXel USG 110. Diese hat bzgl. des WANs keine extrawagante Konfiguration. Das PPPoE-Interface ist an den WAN1-Port gebunden. IP-Adresse wird automatisch bezogen. Der eingerichtete PPPoE-Account ist an das PPP-Interface gebunden. Die Einwahl funktioniert auch schnell und Problemlos. Die Übertragungsraten sind einwandfrei entsprechend VDSL100 (~95MBit down, ~39,5MBit up).
Seit dem ich die ZyXel ZyWall USG 100 gegen die ZyXel USG 110 getauscht habe ging es los mit den Willkürlichen Disconnects. Im Log-File finde ich dann die Einträge: "Interface wan1_ppp disconnected: peer not responding". Genau dieses Verhalten gab es zu ZyWall USG 100-Zeiten nicht. Die Konfig der ZyWall USG 100 habe ich händisch und manuell auf die USG 110 übernommen soweit die Identischkeit der Menüpunkte es zulies (Die Geräte haben fast die identischen Einstellmöglichkeiten. Die USG 110 hat ein paar Zusatzfunktionen). Das heißt also ich habe die WAN-Konfig 1:1 auf die USG 110 übertragen.
Nachdem diese Disconnects anschließend an der Tagesordnung waren habe ich mit dem Troubleshooting angefangen. Folgende Dinge habe ich getan:
Gerätebezogen:
- Aktualisierung der Firmware auf USG 110
- Kontrollieren der Einstellungen auf USG 110
- Ändern von Einstellungen auf USG 110 (Wie MTU und Idle-Timeout des WANs)
- Aktualisierung der Firmware auf VMG 1312-B30A sowie zurücksetzen und Neueinrichtung des Gerätes
Kommunikation mit Telekom:
Kommunikation mit 1. Support-Menschen:
Es wurde durch den technischen Service der T-Com mitgeteilt, dass auf dem Port des DSLAMs wohl eine "Missmatch Configuration" festgestellt wurde. Anschließend wurde der Port auf defaults geresettet. Danach wurde mir durch Rückruf mitgeteilt, dass es jetzt wohl alles sauber ausschaut und der Fehler behoben wäre... Es war anschließend ca. eine Woche lang Ruhe von den Disconnects und dann ging es wieder los.
Kommunikation mit 2. Support-Menschen:
Ich habe mich erneut mit der Telekom in Verbindung gesetzt und der Mitarbeiter hat den Langzeit-Log/Leitungsmessung ausgelesen und hat mich, ohne auf das Disconnect-Problem einzugehen, gleich danach gefragt ob ich irgendwelche Antiviren-Software oder vergleichbare Programme auf meinen Rechnern installirt habe (Das verneinte ich und er fing an mir einen Vortrag zu halten. Bla bla bla bla Sicherheit bla bla bla..... -_-). Ich hab mich gefragt weshalb er das macht und hab ihn unterbrochen. Da meinte er, er hätte im Log den Hinweis "Punkbuster-Irgendwas" meine/unsere Leitung betreffend (Ich habe keine Ahnung von dem ganzen Gaming-Punkbuster-sonstewas-Kram). Er meinte es könne wohl sein, dass irgendwelche Spieleplanttformen wie Steam oder Origin oder was es nicht alles gibt bei Updates bestimmte NAT-Sessions öffnen und darüber dann bestimmte schadhafte Signaturen geladen werden, welche sich wohl sogar auf der Firewall/Router/Gateway einnisten können und solche disconnects triggern können (Vor allem wenn wohl Hacks oder Fälschugen oder gecrackte Spiele vorliegen). Als ich das Gehört habe, hat sich die Anzahl der Fragezeichen in meinem Kopf auf eine drastische weise erhöht. Was er da erzählt hat, hat sich sehr sportlich und weit hergeholt angehört. Eigentlich habe ich auch nur die Hälfte verstanden weil sich dieses Szenario in meiner Vorstellungskraft nicht vollständig entfalten konnte Ich habe absolut keinen Plan ob da was dran ist oder nicht oder von was er da überhaupt erzählt hat. Gibt es hier jemanden der ansatzweise nachvollziehen kann worauf er hinaus wollte?
Weiteres Vorgehen durch mich:
Durch Auswertung des Firewall-Logs aus der USG 110 habe ich gesehen, dass mehrmals kurz vor den Disconnects ein UPnP-Paket auf dem WAN-Port einschlägt, welches vom Modem zu kommen scheint. Daraufhin habe ich die Einstellungen auf dem VMG 1312-B30A nochmals angepasst und UPnP deaktiviert. Selbst dies hat für eine bestimmte Zeit für Verbesserung gesorgt und ich hatte ein paar tage wieder keinen Disconnect. ...Dann kamen sie wieder.
Nach längerem Hin und Her mit ZyXel habe ich die Einigung treffen können, dass mir per RMA-Austausch eine neue ZyXel USG 110 zugesendet wird, da der Verdacht auf einen Fehler in der Firewall fiel. Das Gerät kam an, ich habe meine Config eingespielt und es in Betrieb genommen. Bumms... am nächsten Tag 14:33 Uhr fliege ich auf arbeit wieder aus dem SSL-VPN Richtung daheim raus. Erneuter Disconnect! meine Laune fiel wieder auf den Null-Punkt.
Mittlerweile bin ich soweit das Modem gegen ein "ALLNET ALL-BM100VDSL2" auszutauschen. Wobei ich mir schwer vorstellen kann, dass es an diesem liegt, da mit der USG 100 alles einwandfrei funktioniert hat. Nur mit mittlerweile zwei unterschiedlichen USG 110 geht es nicht. Am Modem hat sich nichts verändert...
Ich weiß nicht mehr weiter.... Bin mit dem Lateien am Ende...
Verkabelt ist alles mit Dätwyler Cat 5e hochflexibel
Ich wäre sehr froh wenn mir jemand Ratschläge geben könnte...
Danke!
Benjamin
wie die Überschrift es schon verlauten lsst geht es um Tageszeitunabhängige, willkürliche Trennungen vom Internet, die mir den letzten Nerv rauben. Dieses Problem hat angefangen aufzutreten als ich eine neue Firewall bei mir daheim in Betrieb genommen habe. Ich bin von einer ZyXel ZyWall USG100 auf eine ZyXel USG 110 umgestiegen, da diese mehr Performance bietet. Als Modem verwende ich ein ZyXel VMG 1312-B30A welches im PPPoE pass through-Modus betrieben wird. Der Internetanschluss ist ein VDSL2 100 der Telekom mit Vectoring-Technologie.
Ich komme direkt aus der TAE-Dose mit einem CAT5.1 Netzwerkkabel von Dätwyler und gehe damit in den WAN-Port des ZyXel VMG 1312-B30A. Auf dem Modem ist eine Schnittstellen-Gruppe eingerichtet, welche das Bridging von dem WAN-Port auf einen Ethernet-Port ermöglicht. Das VLAN-Tag 7, welches ich für das VDSL der Telekom benötige wird ebenfalls am WAN-Port des Modems übergeben und ist somit auf diesem konfiguriert.
Die PPPoE-Einwahl macht die ZyXel USG 110. Diese hat bzgl. des WANs keine extrawagante Konfiguration. Das PPPoE-Interface ist an den WAN1-Port gebunden. IP-Adresse wird automatisch bezogen. Der eingerichtete PPPoE-Account ist an das PPP-Interface gebunden. Die Einwahl funktioniert auch schnell und Problemlos. Die Übertragungsraten sind einwandfrei entsprechend VDSL100 (~95MBit down, ~39,5MBit up).
Seit dem ich die ZyXel ZyWall USG 100 gegen die ZyXel USG 110 getauscht habe ging es los mit den Willkürlichen Disconnects. Im Log-File finde ich dann die Einträge: "Interface wan1_ppp disconnected: peer not responding". Genau dieses Verhalten gab es zu ZyWall USG 100-Zeiten nicht. Die Konfig der ZyWall USG 100 habe ich händisch und manuell auf die USG 110 übernommen soweit die Identischkeit der Menüpunkte es zulies (Die Geräte haben fast die identischen Einstellmöglichkeiten. Die USG 110 hat ein paar Zusatzfunktionen). Das heißt also ich habe die WAN-Konfig 1:1 auf die USG 110 übertragen.
Nachdem diese Disconnects anschließend an der Tagesordnung waren habe ich mit dem Troubleshooting angefangen. Folgende Dinge habe ich getan:
Gerätebezogen:
- Aktualisierung der Firmware auf USG 110
- Kontrollieren der Einstellungen auf USG 110
- Ändern von Einstellungen auf USG 110 (Wie MTU und Idle-Timeout des WANs)
- Aktualisierung der Firmware auf VMG 1312-B30A sowie zurücksetzen und Neueinrichtung des Gerätes
Kommunikation mit Telekom:
Kommunikation mit 1. Support-Menschen:
Es wurde durch den technischen Service der T-Com mitgeteilt, dass auf dem Port des DSLAMs wohl eine "Missmatch Configuration" festgestellt wurde. Anschließend wurde der Port auf defaults geresettet. Danach wurde mir durch Rückruf mitgeteilt, dass es jetzt wohl alles sauber ausschaut und der Fehler behoben wäre... Es war anschließend ca. eine Woche lang Ruhe von den Disconnects und dann ging es wieder los.
Kommunikation mit 2. Support-Menschen:
Ich habe mich erneut mit der Telekom in Verbindung gesetzt und der Mitarbeiter hat den Langzeit-Log/Leitungsmessung ausgelesen und hat mich, ohne auf das Disconnect-Problem einzugehen, gleich danach gefragt ob ich irgendwelche Antiviren-Software oder vergleichbare Programme auf meinen Rechnern installirt habe (Das verneinte ich und er fing an mir einen Vortrag zu halten. Bla bla bla bla Sicherheit bla bla bla..... -_-). Ich hab mich gefragt weshalb er das macht und hab ihn unterbrochen. Da meinte er, er hätte im Log den Hinweis "Punkbuster-Irgendwas" meine/unsere Leitung betreffend (Ich habe keine Ahnung von dem ganzen Gaming-Punkbuster-sonstewas-Kram). Er meinte es könne wohl sein, dass irgendwelche Spieleplanttformen wie Steam oder Origin oder was es nicht alles gibt bei Updates bestimmte NAT-Sessions öffnen und darüber dann bestimmte schadhafte Signaturen geladen werden, welche sich wohl sogar auf der Firewall/Router/Gateway einnisten können und solche disconnects triggern können (Vor allem wenn wohl Hacks oder Fälschugen oder gecrackte Spiele vorliegen). Als ich das Gehört habe, hat sich die Anzahl der Fragezeichen in meinem Kopf auf eine drastische weise erhöht. Was er da erzählt hat, hat sich sehr sportlich und weit hergeholt angehört. Eigentlich habe ich auch nur die Hälfte verstanden weil sich dieses Szenario in meiner Vorstellungskraft nicht vollständig entfalten konnte Ich habe absolut keinen Plan ob da was dran ist oder nicht oder von was er da überhaupt erzählt hat. Gibt es hier jemanden der ansatzweise nachvollziehen kann worauf er hinaus wollte?
Weiteres Vorgehen durch mich:
Durch Auswertung des Firewall-Logs aus der USG 110 habe ich gesehen, dass mehrmals kurz vor den Disconnects ein UPnP-Paket auf dem WAN-Port einschlägt, welches vom Modem zu kommen scheint. Daraufhin habe ich die Einstellungen auf dem VMG 1312-B30A nochmals angepasst und UPnP deaktiviert. Selbst dies hat für eine bestimmte Zeit für Verbesserung gesorgt und ich hatte ein paar tage wieder keinen Disconnect. ...Dann kamen sie wieder.
Nach längerem Hin und Her mit ZyXel habe ich die Einigung treffen können, dass mir per RMA-Austausch eine neue ZyXel USG 110 zugesendet wird, da der Verdacht auf einen Fehler in der Firewall fiel. Das Gerät kam an, ich habe meine Config eingespielt und es in Betrieb genommen. Bumms... am nächsten Tag 14:33 Uhr fliege ich auf arbeit wieder aus dem SSL-VPN Richtung daheim raus. Erneuter Disconnect! meine Laune fiel wieder auf den Null-Punkt.
Mittlerweile bin ich soweit das Modem gegen ein "ALLNET ALL-BM100VDSL2" auszutauschen. Wobei ich mir schwer vorstellen kann, dass es an diesem liegt, da mit der USG 100 alles einwandfrei funktioniert hat. Nur mit mittlerweile zwei unterschiedlichen USG 110 geht es nicht. Am Modem hat sich nichts verändert...
Ich weiß nicht mehr weiter.... Bin mit dem Lateien am Ende...
Verkabelt ist alles mit Dätwyler Cat 5e hochflexibel
Ich wäre sehr froh wenn mir jemand Ratschläge geben könnte...
Danke!
Benjamin
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 356773
Url: https://administrator.de/contentid/356773
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
41 Kommentare
Neuester Kommentar
'n Abend,
wende Dich erneut an den Support und lasse Deinen VDSL Anschluß auf einen anderen Port legen, wenn möglich auch auf eine andere Linecard. Das sieht mir so aus, als wäre der Port defekt.
Ich hatte ähnliche Probleme mit meinem VDSL50 Anschluß mit Telekom Speedport. Zuerst wurde der Speedport getauscht. Ohne Erfolg. Da ein Nachbar bei der Telekom im Entstörungsdienst arbeitet und diese Problematik selber erlebt hat und kennt, habe ich dies dem Support mitgeteilt.
Man hat dann meinen Port in einen anderen Schrank auf neue Komponenten umgezogen. Seitdem ist Ruhe.
Viel Glück bei der Entstörung.
Gruss Penny
wende Dich erneut an den Support und lasse Deinen VDSL Anschluß auf einen anderen Port legen, wenn möglich auch auf eine andere Linecard. Das sieht mir so aus, als wäre der Port defekt.
Ich hatte ähnliche Probleme mit meinem VDSL50 Anschluß mit Telekom Speedport. Zuerst wurde der Speedport getauscht. Ohne Erfolg. Da ein Nachbar bei der Telekom im Entstörungsdienst arbeitet und diese Problematik selber erlebt hat und kennt, habe ich dies dem Support mitgeteilt.
Man hat dann meinen Port in einen anderen Schrank auf neue Komponenten umgezogen. Seitdem ist Ruhe.
Viel Glück bei der Entstörung.
Gruss Penny
Hm,
gut in meinem Falle war es recht eindeutig, zumal ich ja den Nachbarn bei der Telekom habe, welcher genau die gleiche Problematik hatte. Und dieser hat mir den Tipp gegeben. Zudem hat er nebenbei meinen Port durchgemessen.
Bei der Messung sind KEINE Fehler festgestellt worden. Also angeblich alles in Ordnung.
Für mich war es der Glücksfall, daß ich
a) den Telekomnachbar habe
b) er das Problem kannte und selber hatte
c) ich mich auf seine Informationen berufen konnte und ihn auch namentlich beim Support angeben konnte/durfte
d) ich ich dies dem Support und auch dem Techniker vor Ort mitteilen konnte
Teile dem Support mit, daß bereits das Gerät ausgetauscht hast und Dein Anschluß auf einen anderen Port besser andere Linecard legen sollen.
Du kannst dem Support mitteilen, daß eine Linecard max. 75% belegt werden soll.
Gruss Penny
gut in meinem Falle war es recht eindeutig, zumal ich ja den Nachbarn bei der Telekom habe, welcher genau die gleiche Problematik hatte. Und dieser hat mir den Tipp gegeben. Zudem hat er nebenbei meinen Port durchgemessen.
Bei der Messung sind KEINE Fehler festgestellt worden. Also angeblich alles in Ordnung.
Für mich war es der Glücksfall, daß ich
a) den Telekomnachbar habe
b) er das Problem kannte und selber hatte
c) ich mich auf seine Informationen berufen konnte und ihn auch namentlich beim Support angeben konnte/durfte
d) ich ich dies dem Support und auch dem Techniker vor Ort mitteilen konnte
Teile dem Support mit, daß bereits das Gerät ausgetauscht hast und Dein Anschluß auf einen anderen Port besser andere Linecard legen sollen.
Du kannst dem Support mitteilen, daß eine Linecard max. 75% belegt werden soll.
Gruss Penny
Hast du eigentlich mal geschaut ob du bei den PPPoE Problemen den Sync behältst? Im Systemmonitor bei xDSL-Statistik ists versteckt, direkt im oberen "Abschnitt"
Wenn der Sync abbricht könnte es der etwas blöde Adapter sein. Oder halt der Port. Wenn der werte Herr Techniker dann vor Ort ist kannst du ja mal versuchen ihm ein Signaturkabel abzuschwatzen. Die liegen massenhaft auf den Autos für alle Fälle, manchmal hilft es durchaus. Vielleicht reicht aber auch schon der neue Port
Link Uptime: 49 days: 17 hours: 2 minutes
SNR Margin: 6.0 dB
Was man auch an den vielen CRC Fehlern sieht welche erneut übertragen werden müssen da nicht korrigierbar.
D.h. wenn zu Stoßzeiten in der Umgebung viele Leute im Kabelstrang unterwegs sind (Kabelübersprechen nimmt zu) und der SNR weiter in den Keller sackt wird dadurch der Sync vermutlich verloren gehen.
Ich würde das Modem mal auf konservativere Sync-Werte einstellen wenn dieses es zulässt. Dann ist zwar die Datenrate etwas niedriger, dafür nimmt die Stabilität der Leitung jedoch zu.
Zusätzlich sicherstellen das sämtliche Kabelwege möglichst lange geschirmt geführt werden und sicherstellen das sich keine DLAN-Geräte in der Nähe befinden, bzw. Netzteile davon in anderen Dosen platzieren.
Kannst du die PPPoE-Timeouts an der USG konfigurieren und testweise den Intervall, als auch die Anzahl tolerierter ausbleibender Echo-Responses erhöhen?
Die Fehlermeldung klingt so, als wenn die USG die Verbindung trennt resp. für tot erklärt, weil keine LCP-Echo-Responses mehr zurückkommen. Wenn der Intervall zu niedrig angesetzt ist, kann das aber auch passieren wenn die Internetverbindung stark ausgelastet ist.
Die Fehlermeldung klingt so, als wenn die USG die Verbindung trennt resp. für tot erklärt, weil keine LCP-Echo-Responses mehr zurückkommen. Wenn der Intervall zu niedrig angesetzt ist, kann das aber auch passieren wenn die Internetverbindung stark ausgelastet ist.
Vdsl uptime von 21 Minuten deutet, sofern du das Modem nicht neugestartet oder vom Telefonnetz getrennt hast, auf Syncverlust hin. Die recht vielen FEC und CRC können von einer alten TAE kommen... Oder vom APL zur TAE liegt das beliebte Rot schwarz weiß gelb... Deine Maximalwerte sehen aber gut aus, scheinbar eine sehr kurze Leitung.
Versuche es mal mit neuer TAE, Signaturkabel und neuem Port. Eins der 3, mglw auch mehrere Faktoren, sind für die häufigen Fehler verantwortlich. Kenne das leider zu gut, bei zu vielen Fehlern bricht die Leitung gern weg. Man versucht dann, um den Störer oder das Problem herum zu trainieren.
Versuche es mal mit neuer TAE, Signaturkabel und neuem Port. Eins der 3, mglw auch mehrere Faktoren, sind für die häufigen Fehler verantwortlich. Kenne das leider zu gut, bei zu vielen Fehlern bricht die Leitung gern weg. Man versucht dann, um den Störer oder das Problem herum zu trainieren.
Er meint die DSL-Leitung zum DSLAM. Noch kürzer und er kann die Bits von Hand rüber reichen .
Wo steht denn zu kurz?? Hat er doch gar nicht geschrieben .
Zitat:
Zitat:
Zitat von @vanfeuchtsing:
Und ja.... Die Leitung ist kurz. habe mit ihm drüber grsprochen auf welchem Kasten ich auflaufe und der ist ~100m entfernt von der Wohnung
Und ja.... Die Leitung ist kurz. habe mit ihm drüber grsprochen auf welchem Kasten ich auflaufe und der ist ~100m entfernt von der Wohnung
Zitat von @134464:
Wo steht denn zu kurz?? Hat er doch gar nicht geschrieben .
Zitat:
Ach so, die Länge seiner Leitung von der Wohnung zum DSLAM beträgt 100m.Wo steht denn zu kurz?? Hat er doch gar nicht geschrieben .
Zitat:
Zitat von @vanfeuchtsing:
Und ja.... Die Leitung ist kurz. habe mit ihm drüber grsprochen auf welchem Kasten ich auflaufe und der ist ~100m entfernt von der Wohnung
Und ja.... Die Leitung ist kurz. habe mit ihm drüber grsprochen auf welchem Kasten ich auflaufe und der ist ~100m entfernt von der Wohnung
Hätte er auch gleich so schreiben können.
Sooo viel anders ists bzgl. Fehlern ja nicht, aber seis drum. Die meisten davon lassen sich korrigieren, sie sollen sich nur nicht häufen. Bester Anschluss bisher: 20000 FEC, 10000 CRC in 20 Sekunden (!). Dagegen ist deiner ein Traum. Wenns immernoch nicht so stabil läuft, dass die Verbindung auch mal ein paar Tage stehen bleibt solltest du besser noch eine Störung melden, dieses mal dann Port tauschen lassen. Aber wenns bisher noch läuft ist ja schonmal gut
Blöde Frage aber nur um sicher zu gehen, du hast sicher in der USG den 24h Disconnect deaktiviert?! Den braucht es ja bei VDSL nicht mehr.
Hi,
mit BNG gibts keinen 24h disconnect mehr. Weder bei ADSL noch bei VDSL. Auf der "alten" Plattform kann ichs dir ausm Kopf gerade nicht sagen, da ich privat direkt von BRAS-ATM nach VDSL BNG gewechselt bin und GBE (ADSL/VDSL) damit übersprungen hab. Ansonsten besorgen mich die Werte eher nicht. Wenn ein anderes Modem das gleiche Bild zeigt wirds wohl aufn Port Change rauslaufen.
mit BNG gibts keinen 24h disconnect mehr. Weder bei ADSL noch bei VDSL. Auf der "alten" Plattform kann ichs dir ausm Kopf gerade nicht sagen, da ich privat direkt von BRAS-ATM nach VDSL BNG gewechselt bin und GBE (ADSL/VDSL) damit übersprungen hab. Ansonsten besorgen mich die Werte eher nicht. Wenn ein anderes Modem das gleiche Bild zeigt wirds wohl aufn Port Change rauslaufen.
Jepp
VDSL-/ADSL-Modem zur Verwendung mit
ADSL/ADSL2/ADSL2+ nach DT AG 1TR112 (auch IPbasiert,
Annex J) bzw. ITU G.992.1, ITU G.992.3, ITU
G.992.5 (Annex B oder J) oder VDSL2 nach
DT AG 1TR112 (auch IP-basiert) bzw. ITU G.993.2 inkl.
G.vector