• Der Fragesteller hat diesen Beitrag als gelöst markiert.
  • Geschlossen

3-5 Verbindungsunterbrüche pro Monat - LCP terminated by peer

fiberguy
Level 1
1 von 6

Hallo zusammen,

 

Ich habe ein inOne KMU Abo über Kupfer mit einem CB2 Router, fixen IP Adressen und verwende PPPoE Passthrough zu einem Linux Firewall. Ungefähr drei bis fünf mal pro Monat wird meine Internetverbindung von der Gegenstelle terminiert. Der Unterbruch dauert dann zwischen 30 Sekunden und 20 Minuten. Dies ist sehr ärgerlich, da ich hier einige Server stehen habe und auch viel Nachts via RAS arbeiten muss.

 

Die Unterbrüche sind immer zwischen 01:00 Uhr und 05:00 Uhr und regelmässig alle ein bis zwei Wochen:

Jan 18 01:49:59 fw1 pppd[2252]: LCP terminated by peer
Jan 26 02:08:48 fw1 pppd[2252]: LCP terminated by peer
Feb  1 03:53:12 fw1 pppd[2252]: LCP terminated by peer
Feb  7 04:40:05 fw1 pppd[2252]: LCP terminated by peer
Feb 15 03:08:08 fw1 pppd[2252]: LCP terminated by peer
Feb 25 01:50:40 fw1 pppd[2287]: LCP terminated by peer
Mar  4 03:00:36 fw1 pppd[2274]: LCP terminated by peer
Mar 15 02:48:31 fw1 pppd[2247]: LCP terminated by peer
Mar 21 01:23:32 fw1 pppd[2247]: LCP terminated by peer
Mar 29 04:23:42 fw1 pppd[2247]: LCP terminated by peer
Apr  5 03:53:19 fw1 pppd[2247]: LCP terminated by peer
Apr 12 01:08:54 fw1 pppd[2247]: LCP terminated by peer
Apr 18 02:14:45 fw1 pppd[2247]: LCP terminated by peer
Apr 26 01:31:11 fw1 pppd[2247]: LCP terminated by peer
May  4 04:28:59 fw1 pppd[2247]: LCP terminated by peer
May 10 01:34:20 fw1 pppd[2247]: LCP terminated by peer
May 21 04:49:12 fw1 pppd[2253]: LCP terminated by peer
May 29 03:41:01 fw1 pppd[2253]: LCP terminated by peer
Jun  4 01:04:59 fw1 pppd[2253]: LCP terminated by peer
Jun 15 01:26:16 fw1 pppd[2253]: LCP terminated by peer
Jun 25 02:40:42 fw1 pppd[2253]: LCP terminated by peer
Jul  2 01:00:17 fw1 pppd[2253]: LCP terminated by peer
Jul 11 04:32:32 fw1 pppd[2253]: LCP terminated by peer
Jul 18 02:10:17 fw1 pppd[2253]: LCP terminated by peer
Jul 22 04:31:26 fw1 pppd[2279]: LCP terminated by peer
Jul 29 03:38:30 fw1 pppd[2279]: LCP terminated by peer
Aug  6 02:10:35 fw1 pppd[2279]: LCP terminated by peer
Aug 13 03:59:08 fw1 pppd[2279]: LCP terminated by peer
Aug 22 04:39:29 fw1 pppd[2279]: LCP terminated by peer
Aug 28 02:23:05 fw1 pppd[2279]: LCP terminated by peer
Sep  8 04:03:45 fw1 pppd[2279]: LCP terminated by peer
Sep 24 01:25:27 fw1 pppd[2274]: LCP terminated by peer
Oct  1 03:25:10 fw1 pppd[2274]: LCP terminated by peer
Oct  9 03:39:12 fw1 pppd[2274]: LCP terminated by peer
Oct 15 01:00:05 fw1 pppd[2274]: LCP terminated by peer
Oct 22 04:02:19 fw1 pppd[2274]: LCP terminated by peer
Oct 29 02:05:39 fw1 pppd[2274]: LCP terminated by peer

 Macht hier Swisscom Wartung an ihren DSLAMs und bootet die neu oder was ist die Ursache? Die Unterbrüche sind definitiv zu häufig für meinen Geschmack.

 

Merci und Gruss
Luke

HILFREICHSTE ANTWORT1

Akzeptierte Lösungen
fiberguy
Level 1
6 von 6

Das Rätsel ist gelöst.

 

Kurzversion:

Der Swisscom RADIUS Server schickt die "Termination Requests", worauf mein Firwall die Verbindung ab und neu aufbaut.

 

Hier die lange Version:

Laut den Logmeldungen war mir eigentlich von Anfang an klar, dass mein Firwall die Verbindung nicht von sich aus abbaut, sondern dies von Seite Provider getriggert wird. Mir war nur nicht klar, ob der Router dies auslöst oder eine andere Komponente auf der Providerseite wie der DSLAM oder der RADIUS Server.

 

Mittels tcpdump habe ich den ppp Verkehr zwischen Firewall und Router aufgezeichnet:

 

tcpdump pppoes and ppp proto 0xc021 -i eth0 -w /tmp/pppoe.pcap

 

Zudem habe ich auch den pppd im Debug Modus laufen lassen. Nach ein paar Wochen hatte ich genügend Daten zusammen.

 

Im Wireshark war sehr schön ersichtlich, dass nach einem erfolgreichen Verbindungsaufbaus tagelang nur noch LCP Echo Requests und LCP Echo Replies zwischen meinem Firewall und Gegenstelle hin und her gingen. Plötzlich kommt von der Gegenstelle ein LCP Termination Request, worauf mein Firewall die Verbindung abbaut. Die Logfiles deckten sich mit dieser Beobachtung.

 

Mein Vorgehen, die Konfigurationen sowie sämtliche Beobachtungen habe ich in einem fünfseitigen Analysedokument zusammengefasst. Anschliessend habe ich mich mit dem Helpdesk in Verbindung gesetzt und meinen technischen Kontakt verlangt. Dieser wollte mich erst gar nicht anhören, da Swisscom ja keinen Support auf einen von mir installierten Firewall geben könne. Ich konnte ihn aber zumindest davon überzeugen, dass ich ihm mein Dokument per Mail schicken kann und er sich das kurz anschaut. Auf eine Antwort müsse ich aber mindestens zwei Wochen warten, da er nur noch eine Stunde arbeite und dann Ferien habe.

 

Nach zwei Wochen und zwei Tagen läutete mein Telefon und der nette Herr vom teschnischen Support war am Apparat. Er erzählte mir, dass er mit meinem Dokument beim 3rd Level Support war und die ihm sofort bestätigt haben, dass meine Analyse korrekt sei und diese "Termination Requests" vom RADIUS Server stammen.

 

Der Ursprung dafür ist in der Vergangenheit zu suchen. Im Jahre 2005 hat Swisscom den Internet Provider Cybernet übernommen. Scheinbar gab es nach der Übernahme Probleme mit den Routern auf diesen Anschlüssen. Die PPP Sessions blieben oft hängen und erholten sich nicht mehr. Als Workaround wurde das periodische Schicken von Resets in der Nacht implementiert.

 

Dieses Problem betreffe aber nicht alle Swisscom Kunden sondern nur jene, die unglücklicherweise einen so konfigurierten RADIUS Server zugeteilt bekommen. Die allermeisten Kunden sollen das auch gar nicht merken, da die Verbindung sehr schnell wieder aufgebaut sei.

 

Auf meine Frage, ob man diesen Workaround den nicht abstellen könne da die heutigen Router das Problem ja nicht mehr haben, bekam ich eine negative Antwort. Scheinbar ist der Aufwand zu gross für etwas, dass nur eine Hand voll Kunden überhaupt bemerken. Man könne mich auch nicht auf einen anderen RADIUS Server zügeln der das Verhalten nicht hat. Die einzige mögliche Lösung die mir vorgeschlagen wurde war, meinen IP Range zurückzugeben und einen neuen zu bestellen. Möglicherweise käme ich so auf einen anderen RADIUS Server. Eine Garantie gebe es aber nicht. Zudem hätte ich dann einen anderen Adressbereich, was wiederum mit viel Aufwand für mich verbunden wäre.

 

Nach Monaten bekam ich also endlich die Bestätigung, dass das Problem nicht bei meinem Firewall sondern beim RADIUS Server der Swisscom zu suchen ist. Dummerweise sind beide meiner Standorte betroffen und eine Lösung für das Problem bekam ich auch nicht. Da es nicht genügend Kunden gibt die sich daran stören, befindet sich dieses Ticket bei Swisscom so weit hinten im Backlog, dass es nie auch nur angeschaut wird. Schade, dass das Abbauen von technischen Schulden scheinbar keine grössere Priorität hat.

 

Am meisten stört mich aber, dass ich zuerst beweisen musste, dass das Problem nicht bei mir lag. Es muss doch eine interne Knowledge Base geben wo dieses Verhalten beschrieben ist? Beim 1st Level Support wird nur die Checkliste abgearbeitet, dort erwarte ich das auch nicht. Beim 2nd Level Support könnte man aber schon etwas Nachforschung erwarten. Bei über CHF 500 pro Monat die ich für meine beiden Anschlüsse bezahle würde ich mir das zumindest wünschen. Schlussendlich war ich aber mit dem netten Herren vom technischen Support doch sehr zufrieden.

 

Falls sonst jemand ein solches Verhalten feststellt, kann er das jetzt zumindest hier nachlesen.

 

Workaround:

Ich habe die ppp Konfiguration um die "holdoff" Option ergänzt:

holdoff n
Specifies how many seconds to wait before re-initiating the link after it terminates.  
This option only has any effect if the persist or demand option is used.

Den Werte habe ich auf zwei Sekunden gesetzt. Nach zwei Sekunden wir die Verbindung nach der Terminierung also wieder aufgebaut. Im Idealfall ist die Verbindung so ca. für 6-7 Sekunden unterbrochen. Ich hatte aber auch schon Fälle wo die Authenisierung nach der Terminierung einige Male scheinbar völlig grundlos fehlschlug und so einen Unterbruch von bis zu 15 Minuten verursachte.

 

Alternativ könnte ich mir auch vorstellen die LCP Termination Request Pakete gezielt via "iptables --string" zu blockieren. Dies könnte aber unschöne Nebenwirkungen haben 😉

 

 

5 Kommentare 5
SamuelD
Swisscom
2 von 6

Hallo @fiberguy

 

Hast du bereits den Swisscom Support angerufen?

 

Gruss Samuel

Hinweis: Ich bin Swisscom Mitarbeiter, schreibe hier allerdings als Privatperson.
Hinweis: Ich bin Swisscom Mitarbeiter, schreibe hier allerdings als Privatperson.
fiberguy
Level 1
3 von 6

Hallo @SamuelD

 

Das habe ich soeben gemacht:

 

Die Leitung sehe gut aus und ihnen ist nicht bekannt, wieso es diese Unterbrüche geben könnte. Ich soll den Router rebooten, ev. den Router resetten oder sie können mir einen neuen Router schicken.

 

Und ich soll anrufen wenn das Problem das nächste mal Auftritt.

 

Leider hilft mir das nicht wirklich weiter. Anhand der Meldung die ich in meinem Log sehe würde ich eher nicht auf den Router tippen..

Merci und Gruss
Luke

SamuelD
Swisscom
4 von 6

Hallo @fiberguy

 

Wenn das Problem wieder vorkommt und du einen neuen Router hast, können die Kollegen ausschliessen, dass es am Gerät liegt.

Vielleicht haben @FlySmurf oder @Tux0ne noch einen Input. 

 

Gruss Samuel

Hinweis: Ich bin Swisscom Mitarbeiter, schreibe hier allerdings als Privatperson.
Hinweis: Ich bin Swisscom Mitarbeiter, schreibe hier allerdings als Privatperson.
Tux0ne
Level 9
5 von 6

Ja. Ein idle timeout in der Firewall kann auch zu solch einem Verhalten führen.

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
fiberguy
Level 1
6 von 6

Das Rätsel ist gelöst.

 

Kurzversion:

Der Swisscom RADIUS Server schickt die "Termination Requests", worauf mein Firwall die Verbindung ab und neu aufbaut.

 

Hier die lange Version:

Laut den Logmeldungen war mir eigentlich von Anfang an klar, dass mein Firwall die Verbindung nicht von sich aus abbaut, sondern dies von Seite Provider getriggert wird. Mir war nur nicht klar, ob der Router dies auslöst oder eine andere Komponente auf der Providerseite wie der DSLAM oder der RADIUS Server.

 

Mittels tcpdump habe ich den ppp Verkehr zwischen Firewall und Router aufgezeichnet:

 

tcpdump pppoes and ppp proto 0xc021 -i eth0 -w /tmp/pppoe.pcap

 

Zudem habe ich auch den pppd im Debug Modus laufen lassen. Nach ein paar Wochen hatte ich genügend Daten zusammen.

 

Im Wireshark war sehr schön ersichtlich, dass nach einem erfolgreichen Verbindungsaufbaus tagelang nur noch LCP Echo Requests und LCP Echo Replies zwischen meinem Firewall und Gegenstelle hin und her gingen. Plötzlich kommt von der Gegenstelle ein LCP Termination Request, worauf mein Firewall die Verbindung abbaut. Die Logfiles deckten sich mit dieser Beobachtung.

 

Mein Vorgehen, die Konfigurationen sowie sämtliche Beobachtungen habe ich in einem fünfseitigen Analysedokument zusammengefasst. Anschliessend habe ich mich mit dem Helpdesk in Verbindung gesetzt und meinen technischen Kontakt verlangt. Dieser wollte mich erst gar nicht anhören, da Swisscom ja keinen Support auf einen von mir installierten Firewall geben könne. Ich konnte ihn aber zumindest davon überzeugen, dass ich ihm mein Dokument per Mail schicken kann und er sich das kurz anschaut. Auf eine Antwort müsse ich aber mindestens zwei Wochen warten, da er nur noch eine Stunde arbeite und dann Ferien habe.

 

Nach zwei Wochen und zwei Tagen läutete mein Telefon und der nette Herr vom teschnischen Support war am Apparat. Er erzählte mir, dass er mit meinem Dokument beim 3rd Level Support war und die ihm sofort bestätigt haben, dass meine Analyse korrekt sei und diese "Termination Requests" vom RADIUS Server stammen.

 

Der Ursprung dafür ist in der Vergangenheit zu suchen. Im Jahre 2005 hat Swisscom den Internet Provider Cybernet übernommen. Scheinbar gab es nach der Übernahme Probleme mit den Routern auf diesen Anschlüssen. Die PPP Sessions blieben oft hängen und erholten sich nicht mehr. Als Workaround wurde das periodische Schicken von Resets in der Nacht implementiert.

 

Dieses Problem betreffe aber nicht alle Swisscom Kunden sondern nur jene, die unglücklicherweise einen so konfigurierten RADIUS Server zugeteilt bekommen. Die allermeisten Kunden sollen das auch gar nicht merken, da die Verbindung sehr schnell wieder aufgebaut sei.

 

Auf meine Frage, ob man diesen Workaround den nicht abstellen könne da die heutigen Router das Problem ja nicht mehr haben, bekam ich eine negative Antwort. Scheinbar ist der Aufwand zu gross für etwas, dass nur eine Hand voll Kunden überhaupt bemerken. Man könne mich auch nicht auf einen anderen RADIUS Server zügeln der das Verhalten nicht hat. Die einzige mögliche Lösung die mir vorgeschlagen wurde war, meinen IP Range zurückzugeben und einen neuen zu bestellen. Möglicherweise käme ich so auf einen anderen RADIUS Server. Eine Garantie gebe es aber nicht. Zudem hätte ich dann einen anderen Adressbereich, was wiederum mit viel Aufwand für mich verbunden wäre.

 

Nach Monaten bekam ich also endlich die Bestätigung, dass das Problem nicht bei meinem Firewall sondern beim RADIUS Server der Swisscom zu suchen ist. Dummerweise sind beide meiner Standorte betroffen und eine Lösung für das Problem bekam ich auch nicht. Da es nicht genügend Kunden gibt die sich daran stören, befindet sich dieses Ticket bei Swisscom so weit hinten im Backlog, dass es nie auch nur angeschaut wird. Schade, dass das Abbauen von technischen Schulden scheinbar keine grössere Priorität hat.

 

Am meisten stört mich aber, dass ich zuerst beweisen musste, dass das Problem nicht bei mir lag. Es muss doch eine interne Knowledge Base geben wo dieses Verhalten beschrieben ist? Beim 1st Level Support wird nur die Checkliste abgearbeitet, dort erwarte ich das auch nicht. Beim 2nd Level Support könnte man aber schon etwas Nachforschung erwarten. Bei über CHF 500 pro Monat die ich für meine beiden Anschlüsse bezahle würde ich mir das zumindest wünschen. Schlussendlich war ich aber mit dem netten Herren vom technischen Support doch sehr zufrieden.

 

Falls sonst jemand ein solches Verhalten feststellt, kann er das jetzt zumindest hier nachlesen.

 

Workaround:

Ich habe die ppp Konfiguration um die "holdoff" Option ergänzt:

holdoff n
Specifies how many seconds to wait before re-initiating the link after it terminates.  
This option only has any effect if the persist or demand option is used.

Den Werte habe ich auf zwei Sekunden gesetzt. Nach zwei Sekunden wir die Verbindung nach der Terminierung also wieder aufgebaut. Im Idealfall ist die Verbindung so ca. für 6-7 Sekunden unterbrochen. Ich hatte aber auch schon Fälle wo die Authenisierung nach der Terminierung einige Male scheinbar völlig grundlos fehlschlug und so einen Unterbruch von bis zu 15 Minuten verursachte.

 

Alternativ könnte ich mir auch vorstellen die LCP Termination Request Pakete gezielt via "iptables --string" zu blockieren. Dies könnte aber unschöne Nebenwirkungen haben 😉

 

 

Nach oben