PPP Glückssache mal mit, mal ohne IPv4, IPv6

[kawk]

Hi,

unser Router 1906VA mit 10.50.0530RU4 macht mit einem Provider über VDSL Sorgen. Bei dem PPP Verbindungsaufbau wird manchmal eine IPv4-Verbindung nebst IPv6 brauchbar eingerichtet, manchmal nur IPv6. Im Log wird im Problemfall zu IPv4 einfach nur vermerkt:

CONN-LOGIN_INFO: local IP address for INTERNET is 0.0.0.0, remote IP address is 0.0.0.0

In der Konfiguration/Kommunikation/Protokolle/PPP-Liste ist für die Gegenstelle INTERNET sowohl IPv4 als auch IPv6 an. Ich habe daneben in Protokolle/IP-Parameter für die Gegenstelle auch die (festen, bekannten) Adressen vorgegeben, das scheint hinsichtlich Erfolg aber keinen Unterschied zu machen.

Nur wenn ich in der PPP-Liste bei der Gegenstelle IPv6 abschalte, kommt (zumindest bisher) immer zuverlässig die IPv4-Verbindung wirklich zustande.

Mit "trace + vdsl-data" sehe ich bei erfolgreichem Aufbau (also sowohl IPv4 wie auch IPv6 aktiv) zusätzliche IPCP-Nachrichten, nämlich gerade jene mit den IP-Informationen (IP-Adresse, DNS).

Wie kriege ich nun heraus, von welcher Seite da was unterschlagen wird? Und noch wichtiger: Wie kriege ich zuverlässig immer beides brauchbar zustande?

Danke für Ideen und Infos
Kolja

[backslash]

Hi kawk

Und noch wichtiger: Wie kriege ich zuverlässig immer beides brauchbar zustande?

ein LANCOM handelt immer alles aus, was konfiguriert wurde...

Wie kriege ich nun heraus, von welcher Seite da was unterschlagen wird?

dazu gibt es den PPP-Trace - der sagt dir genau, was im PPP ausgehandelt wird.

Wichtig dabei ist, daß in beide Richtungen vollkommen getrennte Verhandlungen laufen und du die zusammen gehörenden Teile korrekt zuordnen mußt. Es ist alo nicht ausreichend, wenn du im Ethernet-Trace irgendwelche IPCP-Pakete siehst. sie müssen noch korrekt zugeordnet werden

Aber wenn IPv4 tatsächnlich nicht augehandelt wird, dann kann es eigentlich nur sein, daß der Provider das abgelehnt hat - oder du die Verhandlungsparamter (Try, Config, Fail) zu ein aggressiv gestellt hast.

• Try gibt die Anzahl der unbeantworteten Requests an, bis abgebrochen wird (default ist 5)
• Config gibt die Anzahl der erlaubten empfangenen Ablehnungen (Configure-NAK) an, bis abgebrochen wird (default ist 10)
• Fail gibt die Anzahl der erlaubten empfangenen unerfüllbaren Anfragen (Configure-Request) an, bis abgebrochen wird (default ist 5)

Gruß
Backslash

[kawk]

Hi, danke für die schnelle erste Antwort

dazu gibt es den PPP-Trace - der sagt dir genau, was im PPP ausgehandelt wird.

Dachte ich auch, aber bei "trace + ppp vdsl-data" bekomme ich nicht mehr als nur mit "trace + vdsl-data"; jedenfalls sieht das für mich so aus?

Nun sehe ich, dass es nur im Gut-Fall überhaupt Pakete mit Protocol:IPCP gibt. Sonst nur Protocol:IPV6CP. Gibt es vorher bei LCP und PAP noch etwas, worauf ich achten könnte?

Kolja

[kawk]

Ah, mit nur "trace + ppp" sehe ich PPP-Details. Abgesehen von Verzögerungen (die natürlich relevant sein könnten) gibt es im Gut-Fall nach Hin und Her mit LCP und PAP mit der Gegenstelle namens "INTERNET" nur die hier mit ">" eingerückten zusätzlichen Zeilen. Aber warum nicht immer?

Code: Alles auswählen

[PPP] 2022/04/12 14:03:58,252

Received PAP frame from peer INTERNET (channel 1)
Evaluate PAP ack with ID 4e and size 5
This-Layer-Up action for LCP
Change phase to CALLBACK for INTERNET
This-Layer-Up action for LCP
Change phase to NETWORK for INTERNET
> Lower-Layer-Up event for IPCP
> Initializing IPCP restart timer to 3000 milliseconds
> Generating IPCP configure-request for peer INTERNET
> Inserting IP address ...
> Inserting primary DNS address 0.0.0.0
> Inserting secondary DNS address 0.0.0.0
> Sending IPCP configure-request with ID 00 and length 22 to peer INTERNET (channel 1)
> Starting IPCP restart timer with 3000 milliseconds
Lower-Layer-Up event for IPV6CP
Initializing IPV6CP restart timer to 3000 milliseconds
Generating IPV6CP configure-request for peer INTERNET
Inserting Interface Identifier ....
Sending IPV6CP configure-request with ID 00 and length 14 to peer INTERNET (channel 1)
Starting IPV6CP restart timer with 3000 milliseconds

Im Schlecht-Fall sieht es genauso aus bezüglich phase und IPV6CP, aber IPCP fehlt

Kolja

[backslash]

Hi kawk,

Im Schlecht-Fall sieht es genauso aus bezüglich phase und IPV6CP, aber IPCP fehlt

Geht der Schlecht-Fall denn auch über die Gegenstelle "INTERNET"?
Das kann ich mir igendwie nicht vorstellen, denn ob IPCP ausgehandelt wird, ist einzig davon abhängig, ob IPv4 in der PPP-Tabelle aktiviert wurden UND daß es eine IPv4-Route gibt, die auf die jeweilige Gegenstelle (hier also "INTERNET") verweist. Entsprechenes gilt für IPV6CP - hier muß IPv6 in der PPP-Tabelle aktiviert sein und es muß eine IPv6-Route geben, die auf die Gegenstelle verweist...

Beide Protokolle (IPCP, IPV6CP) werden sofort gestartet, sobald das PPP in die NETWORK-Phase wechselt.

Ansonsten fällt mir höchstens noch auf, daß du die IP-Adresse anonymisiert hast:

Code: Alles auswählen

> Inserting IP address ...

Das deutet für mich darauf hin, daß die eine DMZ mit öffentlichen IP-Adressen betreibst. Denn bei einem "normalen" Internetzugang mit dynamischen Adressen würde das LANCOM die Zuweisung der Adresse anfordern (sprich sie wäre wie beim DNS 0.0.0.0)

Gruß
Backslash

[kawk]

Geht der Schlecht-Fall denn auch über die Gegenstelle "INTERNET"?

Ja. Zwischen beiden Fällen liegen nur eine Minute, ein händischer Verbindungsabbau (LCOS-Menübaum>Sonstiges>Manuelle Wahl>Abbau (INTERNET)) mit nachfolgem automatischen Wiederaufbau, keine Konfigurationsänderungen. Die Trace-Info im Schlechtfall sieht buchstäblich gleich aus, abgesehen von der Zeit und eben den Zeilen zu IPCP.

Entsprechenes gilt für IPV6CP - hier muß IPv6 in der PPP-Tabelle aktiviert sein und es muß eine IPv6-Route geben, die auf die Gegenstelle verweist...

Das ist der Fall, für IPv4 und IPv6. Die Defaultroute und ein zwei Routen mit Tag führen über dieses INTERNET, zwei weitere Routen mit Tag über eine andere Anbindung. Ausserdem existiert noch ein Load-Balancing-Router, ist aber während der Untersuchung kein Ziel irgendeiner Route. Aber könnte das vielleicht mit reinspielen?

eine DMZ mit öffentlichen IP-Adressen betreibst.

Richtig. Das ist ein anderer Bereich. Aber auch die Haupt-IP ist fix, nicht dynamisch. Ich hatte sie mal bei den "IP-Parametern" für die Gegenstelle fest eingetragen, aber das änderte nichts.

Danke für die Hilfe!
Kolja

[kawk]

Ausserdem existiert noch ein Load-Balancing-Router ... vielleicht mit reinspielen?

Nachdem ich nun Load Balancing abgeschaltet habe - weil im Moment eh keine Route auf dorthin führt - scheint der "Schlecht-Fall" sich nicht mehr provozieren zu lassen?! ... das beobachte ich weiter

[backslash]

Hi kawk

Ausserdem existiert noch ein Load-Balancing-Router ... vielleicht mit reinspielen?

Nachdem ich nun Load Balancing abgeschaltet habe - weil im Moment eh keine Route auf dorthin führt - scheint der "Schlecht-Fall" sich nicht mehr provozieren zu lassen?! ... das beobachte ich weiter

Damit hast du wohl auch schon die Ursache gefunden... Jenachdem, ob der Verbindungsaufbau über ein zu übertragenes Paket oder den Loadbalancer getriggert wird, sieht es bei der Routensuche anders aus...

Gruß
Backslash

[kawk]

Jenachdem [...] sieht es bei der Routensuche anders aus...

So richtig "richtig" fühlt sich das nicht an. Immerhin existieren fest konfigurierte statische Routen zu dem Anschluss.

Kurz beschrieben ist es für IPv4 etwa wie folgt eingerichtet, mit Gegenstellen "A" (INTERNET) und "B" (ähnlich), und Load Balancer "C" = "A" oder "B":

- Default Route: via A
- Routing Tag 400: via A (einige spezielle Ziel-Hosts und die gesamte DMZ)
- Routing Tag 401: via B (einige spezielle Ziel-Hosts)
- Zur Zeit nichts: via Load Balancer C

Für IPv6 sieht es fast genauso aus, nur dass dort die Default Route derzeit via B geht.

Einziger Unterschied in der (immer noch) stabileren Konfiguration zu vorher: Load Balancer C ist nicht mehr aktiviert. Aber da keine Route dahin führte, war der doch vorher praktisch auch nicht aktiv. Und beim konkreten Verbindungsaufbau denke ich dürfte das Load Balancing keine Rolle spielen?!

Ich würde nämlich eigentlich gerne Load Balancing einsetzen, aber das ist jetzt nicht das erstmal Mal, dass es in dem Zusammenhang "irgendwie" heftig hakt oder zumindest nicht richtig zufriedenstellend läuft. Auch ein Fallback auf B für die Defaultroute traue ich schon gar nicht mehr zu aktivieren, aber das ist ein anderes Thema

Viele Grüsse,
Kolja

[backslash]

Hi kawk »

Aber da keine Route dahin führte, war der doch vorher praktisch auch nicht aktiv. Und beim konkreten Verbindungsaufbau denke ich dürfte das Load Balancing keine Rolle spielen?!

doch es macht einen Unterschied...

wenn eine Gegenstelle in einem Loadbalnacer steckt, dann übernimmt der Loadbalancer den Verbindungsaufbau... Wenn es keine Route zum Loadbalnacer gibt, wird zunächsz keione Leitung aufgebaut - selbst wenn die einzelnen Leitungen eine Haletzeit von 9999 haben (Keep-Alive), denn wie gesagt: der Loadbalancer ist nun zuständig...

Soll jetzt aber ein Paket gesendet werden, dann triggert der Router den Verbindungsaufbau für die eine Leitung (Dial-On-Demand) und es funktioniert erstmal...
Sobald die Leitung obe ist, bekommt der Loadbalancer das mit und übernimmt die Kontrolle - und ziegt dann auch die zweite Leitung hoch - aber bereits bei der wird kein IPv4 mehr ausgehandelt, weil es keine Route zum Loadbalancer gibt.
Trennst du jetzt manuell die erste Leitung, so bleibt der Loadbalnacer weiterhin aktiv und wir die Leitung wieder aufbauen - nun wird aber IPv4 nicht mehr ausgehandelt, ebenfalls weil es keine Route zum Loadbalancer gibt.

Erst wenn du den Loadbalanecr komplett trennst kehrst du zum Ausgangspunkt zurück...

Ich würde nämlich eigentlich gerne Load Balancing einsetzen

kein Problem... richte einfach eine Route ein, die auf den Loadbalancer verweist...

Gruß
Backslash