Kuriose Telekom-Probleme...

[Koppelfeld]

allo zusammen,
vielleicht kann ich abwechslungshalber einmal etwas Konstruktives beitragen in Bezug auf die aktuell diskutierten Telekom-Störungen.

Heute fand ich, zum dritten Mal hintereinander an unterschiedlichen Standorten, folgende Situation vor:

- 1 Telekom-ADSL/6.000MBit/s über Splitter mit AnnexB, an separatem DSL - Modem (DLINK 321, aktuelle FW
- 1 Telekom-VDSL/50.000MBit/s ohne Splitter und ohne "virtuellen ISDN - Anschluß", terminiert an einer der neuartigen Outdor-Hyperkonfluenzkisten.

Höchst ungewöhnlich, daß die T an drei unterschiedlichen Standorten jeweils zwei Technologieen in den selben APL liefert, aber es ist so.

"Poor man's load balancing": die Annex B - ADSLs werden ausschließlich zum Telephonieren benutzt, qua Routing-Tag im VCM und in der Routing-Tabelle.


Die neuen VDSL - Dinger klappen fast schon zu gut, hier hat die Telekom richtig 'was auf die Beine gestellt.

AAABER jetzt hatten wir, in Abständen von 24 bis 36 Stunden, das Phänomen, daß die ADSL 6000er Verbindung zwar stand, aber keinerlei Traffic durchging.
Weder ankommend noch abgehend.

Bislang hatte ich das auf die Telephonieplattform geschoben, aber da scheint wohl ein Problem beim DSLAM zu bestehen.

Wenn die Verbindung einmal weg ist, kommt sie nicht wieder

!Die VDSL - Verbindungen liefen ohne Probleme duch.


Alle drei Router haben die FW 9.20.0266.


Kann es sein, daß doch noch irgendeine Klinke im Lancom steckt?

[Bernie137]

Hallo Koppelfeld,

AAABER jetzt hatten wir, in Abständen von 24 bis 36 Stunden, das Phänomen, daß die ADSL 6000er Verbindung zwar stand, aber keinerlei Traffic durchging.
Weder ankommend noch abgehend.

Genau dieses Phänomen hatten wir am Freitag Morgen an zwei unterschiedlichen Standorten, allerdings T-DSL16000 mit Splitter. Entweder Einwahlprobleme oder wenn dioe Verbindung stand, dann gingen keinerlei Daten durch. Ein simpler Ping hatte Paketverluste von weit über 60%. Ein alter Test-Lancom mit FW 8.0 hatte an den Anschlüssen das gleiche Problem, Splittertausch hat auch nicht geholfen. Einmal war FW 9.24.0153 und einmal FW 9.24.0212 produktiv im Einsatz. Ich glaube aber nicht, dass es an der FW lieg. Das war ein Telekom Problem und ist bisher nicht wieder aufgetreten.

Wir haben ja eine extra Business Hotline mit angeblich besseren Reaktionszeiten. Aber die waren so überfordert, dass gleich eine Bandansage kam mit Wartezeit > 45 Min und das Gespräch wurde beendet. Was nützt uns das, wenn ich alleine 3h zum Absetzen der Störung benötige. Ich habe beim dritten Anlauf tatsächlich 45 Min gewartet. Kurz nach dem Telefonat gingen beide Anschlüsse wieder. In der Nacht zuvor waren heftige Gewitter und die User berichteten danach von diesen Problemen.

Gruß Bernie

[Dr.Einstein]

Hallo Koppelfeld,

AAABER jetzt hatten wir, in Abständen von 24 bis 36 Stunden, das Phänomen, daß die ADSL 6000er Verbindung zwar stand, aber keinerlei Traffic durchging.
Weder ankommend noch abgehend.

Genau dieses Phänomen hatten wir am Freitag Morgen an zwei unterschiedlichen Standorten, allerdings T-DSL16000 mit Splitter. Entweder Einwahlprobleme oder wenn dioe Verbindung stand, dann gingen keinerlei Daten durch. Ein simpler Ping hatte Paketverluste von weit über 60%. Ein alter Test-Lancom mit FW 8.0 hatte an den Anschlüssen das gleiche Problem, Splittertausch hat auch nicht geholfen. Einmal war FW 9.24.0153 und einmal FW 9.24.0212 produktiv im Einsatz. Ich glaube aber nicht, dass es an der FW lieg. Das war ein Telekom Problem und ist bisher nicht wieder aufgetreten.

Wir haben ja eine extra Business Hotline mit angeblich besseren Reaktionszeiten. Aber die waren so überfordert, dass gleich eine Bandansage kam mit Wartezeit > 45 Min und das Gespräch wurde beendet. Was nützt uns das, wenn ich alleine 3h zum Absetzen der Störung benötige. Ich habe beim dritten Anlauf tatsächlich 45 Min gewartet. Kurz nach dem Telefonat gingen beide Anschlüsse wieder. In der Nacht zuvor waren heftige Gewitter und die User berichteten danach von diesen Problemen.

Gruß Bernie

Letzte Freitag war ein LNS ausgefallen, der für einen bestimmten IP-Adresskreis zuständig ist (betraf zufällig einen Bereich mit festen IPs). Find den Bericht/Foreneintrag dazu leider gerade nicht mehr. Das wird aber nix mit Koppelfelds Problemen zutun haben.

Gruß Dr.Einstein

[fildercom]

Höchst ungewöhnlich, daß die T an drei unterschiedlichen Standorten jeweils zwei Technologieen in den selben APL liefert, aber es ist so.

Also ich finde das nicht ungewöhnlich. Ich kenne APL, da ist alles bunt gemischt: VDSL (outdoor splitterlos), ADSL2+ (outdoor splitterlos) und ADSL (indoor mit ISDN), alles gerade so wie es die Kunden beauftragt hatten. Mir wäre neu, dass ein APL immer einheitlich beschaltet werden würde. In Mehfamilienhäusern stelle ich mir das schwierig bis unmöglich vor.

[ecox]

Letzte Freitag war ein LNS ausgefallen, der für einen bestimmten IP-Adresskreis zuständig ist (betraf zufällig einen Bereich mit festen IPs). Find den Bericht/Foreneintrag dazu leider gerade nicht mehr. Das wird aber nix mit Koppelfelds Problemen zutun haben.

Der LNS (LZG) ist ausgefallen und hatte dafür gesorgt das alle, afaik, alte BO-Kennungen mit fester IP nicht mehr liefen, wie du schon erwähnt hast schließe ich das als den Verursacher aus.

Bzgl. Koppelfeld sein Problem, würde ich da einen Techniker vor Ort kommen lassen, die sollen mal die Bitströme messen und gucken ob da Fehler auf der Leitung sind -> Crosstalking ist bei solchen Konstellationen keine Seltenheit, von daher, bitte mal den Wunsch äußern das die komplette Linie durchgemessen wird, nicht nur Remote, sondern von einem Techniker solche Fehler liegen meistens hinter der Haustür in der Inhouseverkabelung, das kann noch so perfekt aussehen :p

Grüße

[Jirka]

Hallo Koppelfeld,

was passiert denn, im Fehlerfall, nach einem Neustart des LANCOM-Routers? Funktioniert dann die zweite Leitung wieder oder geht dann da nach wie vor nichts?

Derartige Fälle hatte ich seinerzeit auch, sind auch hier im Forum dokumentiert. Du verwendest ja so eine alte Firmware, da würde ich mal auf die 9.24-RU5 updaten.

Viele Grüße,
Jirka

[Koppelfeld]

Guten Morgen!

Danke für die Rückmeldungen!

Verkabelungsfehler an drei Standorten? Die sich selbst reparieren?
Möglich ist ja heutzutage alles.

--> Jirka:
Das mit dem Neustart ist ja das interessante.
Neustart kurzfristig nach Auftreten der Störung: Erfolglos.
Neustart 24h später: Sofortiger Erfolg.
Kann für mich nur heißen: LANCOM "erkennt" Wiederkehr der Funktionsbereitschaft nicht.
Ich will in den drei Fällen einmal probieren, Leitungsuberwachung gegen das Default - GW zu machen.

Firmwarestand: Ich habe nicht RU5, sondern sogar die 9.24 Beta Bld 266 verwendet. Aktueller geht ja wohl nicht.

[Dr.Einstein]

Hi,

den Fehler hatte ich früher (8.00?) öfters. Hab die Ursache nie rausgefunden, geholfen hat seinerzeit nur ein Linepolling auf die PPP Verbindung. Man hat dann schön im Syslog gesehen, dass immer wieder mal die Verbindung für 5-10 Minuten offline war, dafür aber sich selbst repariert hat.

Gruß Dr.Einstein

[Koppelfeld]

Moin!

den Fehler hatte ich früher (8.00?) öfters. Hab die Ursache nie rausgefunden, geholfen hat seinerzeit nur ein Linepolling

Als 8.84 aktuell war, habe ich mir 'mal das ganze LCOS-Handbuch durchgelesen. Nur leider: Mein Gedächtnis läßt doch merklich nach, da ist vieles verschwunden.

Meinst Du Leitungsüberwachung

- auf PPP-Ebene qua LCP oder
- auf dem Network-Layer qua ICMP ?

Ich "meine, mich zu erinnern", daß keiner dieser Polling-Tests auch AKTIONEN nach sich zöge.
Bei VPN-Verbindungen gibt es ja auch einen Mechanismus qua DPD, der sorgt bei entsprechender Konfiguration bestimmungsgemäß für einen Neuaufbau.

auf die PPP Verbindung.
Man hat dann schön im Syslog gesehen, dass immer wieder mal die Verbindung für 5-10 Minuten offline war, dafür aber sich selbst repariert hat.

Das wäre doch ein Traum.
Der "Einrichtungswizard" bietet ja ICMP an, so wie Dudas schilderst, hat Du PPP/LCP gewählt ?

[Dr.Einstein]

Du müssten ICMP Polling machen: /Setup/WAN/Polling-Table

Das LCP Polling ist ja genau das, was dir aktuell scheinbar nicht hilft.

Gruß Dr.Einstein

[Jirka]

Hallo Koppelfeld,

im ersten Posting hast Du aber von 9.20.0266 statt 9.24.0266 geschrieben - das war der Grund für meine Nachfrage. Die 9.24.0266 habe ich auch fast überall im Einsatz.

Zum Problem: Ich habe das für mich bisher so interpretiert, dass wenn der LANCOM-Router stundenlang erfolglos eine PPPoE-Einwahl versucht, dass er dann (unter gewissen Konstellationen vermutlich, die mir aber noch nicht bekannt sind) in einen Zustand kommt, wo dann eine Einwahl nicht mehr möglich ist, auch wenn sie dann klappen würde.
Hier hatte ich das mal in Ansätzen beschrieben:
http://www.lancom-forum.de/feedback-lco ... tml#p87604
Das andere Posting, was ich dazu gemacht hatte, finde ich leider gerade nicht.
Hier http://www.lancom-forum.de/telekom-pado ... tml#p89308 steht's auch im letzten Abschnitt.

Viele Grüße,
Jirka

[Koppelfeld]

Hi Jirka,
nein, im meinen drei Fällen zeigte der Router die Verbindung noch als etabliert an und im Syslog stand ... nichts.
Vielleicht ganz einfach deshalb, weil die Verbindung noch stand?
Kann ja sein, daß im HVT Probleme bestanden.

Verdächtig nur: Nach Reboot klappte alles wieder.

Ich mache es erstmal so, wie Dr. Einstein empfiehlt: Neben der LCP-Überwachung jetzt auch noch ICMP polling, und zwar auf eine eigens dafür freigeräumte öffentliche V4-Adresse in unserem Frankfurter RZ.
U.U. baue ich da sogar noch eine Art Watchdog.

Bloß: In der Doku steht nix drin, was passiert, wenn trotz Wiederholung kein 'icmp echo' zurückkommt.
Bekannt ist, daß der Trigger für eine eventuelle Backup-Verbindung ausgelöst wird. Idealerweise wird aber auch getrennt, gewartet und neu verbunden.

Gegegebenfalls berichte ich über Erfolg oder Mißerfolg.

[MoinMoin]

Moin, moin!

Das ist aber ein altbekanntes Problem, daß gelegentlich das LCP-Polling noch funktioniert, die Strecke aber hinter dem PPP-Endpunkt kaputt ist. Baut man dann die PPP-Verbindung neu auf, gehen auch wieder Daten über die Strecke. Da hilft dann nur ICMP-Polling.

Ciao, Georg

[Koppelfeld]

Hallo,

Das ist aber ein altbekanntes Problem, daß gelegentlich das LCP-Polling noch funktioniert, die Strecke aber hinter dem PPP-Endpunkt kaputt ist. Baut man dann die PPP-Verbindung neu auf, gehen auch wieder Daten über die Strecke. Da hilft dann nur ICMP-Polling.

Werde am Wochenende testweise umstellen und ggfs. später berichten.

[ecox]

Moin,

solche Fälle hatte ich schon 1 Mil. mal und das ist nicht gelogen und ich rede hier von Umgebungen mit 2000+ LANCOM Router.
Ich kann nur sagen das folgende Sachen eigentlich immer Erfolg bringen:

-Router stromlos machen für 2-3 Minuten (klingt doof und klingt auch nach 0800 330 1000, aber es hilft "manchmal")
-bevor Router durch gestartet wirde, mal das interne Modem durchbooten und ggf. vorher den vdsl-st und ppp trace starten

Code: Alles auswählen

do Status/VDSL/Modem/Reboot-Modem
tr# vdsl-st ppp

-bei der Telekom anrufen und fragen ob es möglich wäre direkt ein Line-reset zu machen <- idR klappt das zu 90-100%, man muss eben den korrekten Bearbeiter dran haben der eure Probleme sofort richtig zuordnen kann, sodass man mit etwas glück bei der diagnose raus kommt
-in der adsl/con-history mal schauen wie oft wirklich die verbindung mit line-error ausgestiegen ist und vorallem wenn es oft vorkommt mal die rauschabstände beobachten mit der sich das modem gesynct hat, diese sollten nicht allzuweit von einander abweichen
-desweiteren sollte man auch immer die dämpfung der leitung im auge haben -> siehe ls st/adsl st/vdsl
-diagnose möglichkeiten und sonstige tricks möge es ja geben um die leitung am leben zu erhalten, aber grundsätzlich sind das alles nur workarrounds, wenn eine Leitung zusammen bricht oder nicht mehr reagiert, denke ich, das ein grundlegendes problem mit manchen leitungen/kombinationen besteht, die nun leider nur durch Außendienst behoben werden kann.

-was der Field Service mit dem ARGUS misst, sind welten zwischen dem was einer von der technischen Infrastruktur misst.
-dokumentiert eure sachen und schickt es zu der telekom
-solche Fälle gehen immer an einen Service Engineer, die haben weitaus mehr Skill als manche Teams zusammen...

grüße