Warum kein LRQ bei PPPoE?

[#1]

Nachdem wir vor knapp einem Monat nun mehr oder weniger auf FTTH zwangsumgestellt worden sind (Anschluss liegt in einem OPAL-Gebiet, und die über OPAL bereitgestellte Technik möchte die Telekom in den Ruhestand versetzen), hatten wir vorhin einen „Hänger“: die PPPoE-Verbindung steht formal noch, überträgt aber keinerlei Daten mehr. Sowas hatte ich gelegentlich damals in der Anfangszeit von DSL, aber die knapp 10 Jahre, die wir über OPAL versorgt worden sind, überhaupt nicht mehr.

Wenn „man“ (also der Router, in diesem Fall eine Eigenbau-Version auf Basis von FreeBSD+pf) den Zustand bemerken könnte, wäre das gar kein Problem: PPP-Verbindung neu aufgebaut, und alles geht wieder.

Eigentlich gibt es dafür LQR (Link Quality Reporting) auf der niedrigsten PPP-Ebene, dem LCP. Das wird über LCP-Echos abgewickelt, und wenn die Echo-Anforderung keine Antwort mehr bekommt, weiß die einwählende Seite, dass der Link offenbar nicht mehr verfügbar ist und neu aufgebaut werden muss.

Nur: die Telekom lehnt die Verhandlung dieser Option ab (hat sie schon vor 20 Jahren so gemacht):

Jul  1 23:29:54 camel ppp[600]: LQM: deflink: LQR/LCP ECHO not negotiated

Warum eigentlich? Sie zu gestatten, würde niemanden stören. Die üblichen Plastikrouter werden vermutlich gar nicht versuchen, sie zu verhandeln, und selbst wenn: es ist allemal sinnvoller, das auf LCP-Ebene abzuhandeln als den Router zu zwingen, das irgendwo in den höheren Schichten per ICMP-Echo oder dergleichen zu bewerkstelligen.

[#2 · Accepted solution]

Hallo @dl8dtl,

ich habe auf meine Anfrage folgende Antwort erhalten:

Danke für das Interesse, leider ist das für uns bei der Masse der Anschlüsse nicht umsetzbar und Einzelanschlüsse können im Rahmen der Bereitstellung nicht einzeln aktiviert werden.
Zudem haben sich für uns aus der Variation der Implementierungen im Rahmen der Endgerätefreiheit (1TR112) eine unzureichende Aussagekraft ergeben.


Grüße Detlev K.

[#3]

Wenn du dich verkomplizierst und dadurch dafür sorgst, dass der Anschluss nicht mehr geht, wie wärs, wenn du einfach Technik dran hängst die du nicht kaputt spielen kannst? So einen Speedport als Beispiel.

[#4]

Was genau hilft das gegen einen nicht mehr reagierenden PPPoE-Link?

Davon abgesehen: ein Speedport löst 08/15-Aufgaben. Die löst er brauchbar, und in einer für den Endkunden gut handhabbaren Einfachheit. In meinem Setup wäre er vollständig überfordert. Aber das spielt für den nicht mehr funktionierenden PPP-Link keine Rolle.

(Nochmal zur Erinnerung: gleicher Router mit weitestgehend gleicher Konfiguration (bis auf die Einstellungen, die ich nun für VoIP hinzu fügen musste) hat fast 10 Jahre lang am OPAL-Anschluss anstandslos funktioniert.)

[#5]

---

@dl8dtl  schrieb:
und selbst wenn: es ist allemal sinnvoller, das auf LCP-Ebene abzuhandeln als den Router zu zwingen, das irgendwo in den höheren Schichten per ICMP-Echo oder dergleichen zu bewerkstelligen.

---

Interessierte Nachfrage: Warum ist das sinnvoller? Wenn doch mittlerweile schon die Endgeräte selbst die Internetkonnektivität erfassen, was mindestens in dieser höheren Schicht stattfindet.

[#6]

Weil es genau an der Stelle ansetzt, an der das Problem auch gelöst werden kann: auf der untersten Ebene der PPP-Verbindung.

Es nützt nicht viel, wenn ein Endgerät den Zustand der Internetverbindung erfasst: das Endgerät kann nur konstatieren „geht“ oder „geht nicht“ – aber im letzteren Falle kann es selbst nichts dagegen tun. Außerdem kann man den Zustand der IP-Verbindung ja nur gegen eine bekannte Gegenstelle erfassen, und auf der Ebene kann durchaus auch ein Fehler jenseits meiner eigenen PPP-Verbindung vorliegen (Routingproblem im Netz, Gegenseite ausgefallen). Dann würde das Neustarten der eigenen PPP-Verbindung überhaupt nichts ändern.

Dass das PPP „einschläft“, ist irgendwo ein Bug. LQR würde einfach nur dagegen helfen, dass man im Falle des Bugs schnell reagieren kann. Natürlich wäre es besser, wenn der Bug gar nicht erst auftritt. Wie ich schon schrieb, zu Anfang der DSL-Zeit hatte ich das auch hin und wieder, später nicht mehr. Insofern bin ich natürlich erstaunt, dass es bei FTTH nun wieder auftritt.

[#7]

Hallo @dl8dtl,

---

dl8dtl schrieb: die Telekom lehnt die Verhandlung dieser Option ab (hat sie schon vor 20 Jahren so gemacht):
Jul 1 23:29:54 camel ppp[600]: LQM: deflink: LQR/LCP ECHO not negotiatedWarum eigentlich?

---

ich gehe dem einmal nach und versuche Informationen dazu zu bekommen.
Das wird meiner Erfahrung nach aber etwas Zeit kosten.


Grüße Detlev K.

[#8 · Accepted solution]

Hallo @dl8dtl,

ich habe auf meine Anfrage folgende Antwort erhalten:

Danke für das Interesse, leider ist das für uns bei der Masse der Anschlüsse nicht umsetzbar und Einzelanschlüsse können im Rahmen der Bereitstellung nicht einzeln aktiviert werden.
Zudem haben sich für uns aus der Variation der Implementierungen im Rahmen der Endgerätefreiheit (1TR112) eine unzureichende Aussagekraft ergeben.


Grüße Detlev K.

[#9]

Danke @Detlev K. für die Bemühungen!

Schade, dass die Antwort deiner Kollegen nicht so richtig viel Substanz enthält, aber das lässt sich dann wohl nicht ändern. Dann muss ich zusehen, wie ich einen Linktest ohne LQR aufgesetzt bekomme.

In 9 Jahren VDSL via OPAL haben wir keinen einzigen "Klemmer" dieser Art gehabt, überhaupt war diese Technik extrem stabil, ganze zwei Ausfälle, wenn ich mich recht entsinne, von denen einer dem berüchtigten "Kabelbagger" geschuldet war. Zuvor (an einem anderen Ort) auf Kupfer-DSL passierte das auch hin und wieder mal: das PPP ist zwar der Meinung, die Verbindung würde noch stehen, tatsächlich werden jedoch keinerlei Daten mehr transportiert. Das ist dann vermutlich der Punkt, an dem Otto Normalnutzer einfach seinen Plastikrouter aus- und wieder einschaltet, und danach geht alles wieder …

Schade, dass das jetzt über FTTH wieder auftritt: wir haben FTTH mittlerweile gerade mal einen reichlichen Monat, aber in der Zeit bereits zwei derartige Hänger (19. Juni, 10.17 bis 14.22 Uhr; 8. Juli 03.56 bis 07.39 Uhr, jeweils nur durch manuellen Neustart des PPPoE auflösbar).