[gelöst] Aussetzer bei der IPv6-Konnektivität

Forum für allgemeinen Fragen zum Thema IPv6 mit LANCOM Routern

Moderator: Lancom-Systems Moderatoren

OnkelThomas
Beiträge: 7
Registriert: 27 Jul 2020, 16:21
Kontaktdaten:

[gelöst] Aussetzer bei der IPv6-Konnektivität

Beitrag von OnkelThomas »

Guten Tag,

ich haben das Problem, das Zeitweise IPv6 über mehrere Stunden nicht geroutet wird.

Es ist ein LANCOM 1781EW+ im Einsatz. An einem Unitymedia DS-Lite Internetanschluss mit ::/56 IPv6-Präfix fungiert eine FRITZ!Box 6490 Cable als Modem.

Die Installation ist in vier VLANs aufgeteilt, wovon drei wie gewünscht über IPv6 verfügen. Das Ganze ließ sich recht einfach konfigurieren.
IPv6.png
IPv6.png (10.03 KiB) 790 mal betrachtet
Nun das Problem: Nach unbekannter Zeit hört IPv6 parallel in allen Netzen auf zu funktionieren. Verbindungen brechen ab bzw. lassen sich keine Neuen aufbauen. In der Syslog ist beim Abbruch nichts zu sehen. Nach einiger Zeit funktioniert es dann plötzlich wieder. In der Syslog steht dann

Code: Alles auswählen

11:21:53 CONN-LOGIN Notice [IPv6 Config] router advertisement started for prefix 2a02:8070:XXXX:73fe::/64 LAGER
11:21:53 CONN-LOGIN Notice [IPv6 Config] router advertisement started for prefix 2a02:8070:XXXX:73fd::/64 INTRANET
11:21:53 CONN-LOGIN Notice [IPv6 Config] router advertisement started for prefix 2a02:8070:XXXX:73ff::/64 GAESTE
Hab schon ohne Erfolg danach gesucht, ob sich der Zeitabstand zwischen den Router Advertisments verkürzen lässt.
Zuletzt geändert von OnkelThomas am 17 Sep 2020, 13:21, insgesamt 1-mal geändert.
chriswalg
Beiträge: 2
Registriert: 06 Sep 2020, 19:52
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von chriswalg »

Das Verhalten ist mir bei meinen 1781AW mit DualStack am Vodafone (Unitymedia)-Anschluss auch aufgefallen.
Lancom sagte, es liege am Provider/Modem. Provider sagte, ich solle von der Connect-Box auf eine Fritzbox 6561 umstellen. Gesagt und getan und jetzt hängt der Lancom gebrided an der Fritzbox. Hatte danach das Verhalten weiterhin. Mit der aktuellen 10.40RU1 ist mir das unter Fedora 32 Kernel 5.8.4 nicht mehr aufgefallen.
OnkelThomas
Beiträge: 7
Registriert: 27 Jul 2020, 16:21
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von OnkelThomas »

Danke für die Antwort!

Was mir mittlerweile aufgefallen war, ist das bestehende IPv6-Verbindungen weiter funktionierten. So musste ich über IPv6 einen OpenVPN-Server bereitstellen. Dieser sendet alle 30 Sekunden einen Keepalive an die Clients (Oder andersherum). Geht IPv6 gerade nicht, funktioniert die "Einwahl" natürlich auch nicht. Aber besteht bereits eine OpenVPN-Verbindung und IPv6 fällt aus, funktioniert die Verbindung weiter.
Genau so scheint ein IPv6-Dauerping weiter zu laufen (zumindest eine gewisse Zeit lang). Wenn dann plötzlich keine neuen IPv6-Verbindungen mehr gehen und ich den ping 10 Sekunden ruhen lasse, funktioniert auch er nicht mehr. (Vermutlich hat das was mit den Aging-Werten zu tun. Wäre es kein Produktivsystem, könnte ich mit den Werten mehr experimentieren.)
Wäre das komplette Routing betroffen, könnten aktive Verbindungen ja nicht weiterlaufen.

LANconfig hatte mir 10.40 noch gar nicht angezeigt. Hab es nun manuell von der Webseite geladen und werde es alsbald einspielen. Ich gebe dann nochmal Rückmeldung.
chriswalg
Beiträge: 2
Registriert: 06 Sep 2020, 19:52
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von chriswalg »

Das Verhalten war heute morgen wieder nach dem aufwachen vom Thinkpad (WiFi-Verbindung) aus dem Energiespar-Modus.
Welche Betriebssysteme und Versionen werden benutzt?
GrandDixence
Beiträge: 686
Registriert: 19 Aug 2014, 22:41

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von GrandDixence »

Wenn es ein Aging-Probleme wäre (was ich als IPv6-Anfänger bezweifle), so sollten die Aging-Einstellungen im LANCOM-Router kontrolliert werden:
viewtopic.php?f=14&t=17281#p98088

viewtopic.php?f=31&t=17621&p=99943#p99943

Danach sollten die aktuellen Lebenszeit-Werte der bestehenden Verbindungen (TCP/UDP/ICMP) auf der entsprechenden Status-Seite des LANCOM-Routers überwacht werden (LCOS-Menübaum/Status/IP-Router/Verbindungsliste).

Es darf angenommen werden, dass in der Fritzbox auch eine IPv6-Firewall (basierend auf Linux-Kernel => iptables) aktiv ist. Deshalb sollte auf dem Linux-Rechner mit conntrack die aktuellen Lebenszeit-Werte der bestehenden Verbindungen beobachtet werden:

https://forums.suse.com/discussion/comment/59615

Siehe auf dem Linux-Rechner auch:

Code: Alles auswählen

# su
# sysctl -a -r timeout
https://serverfault.com/questions/48189 ... s-live-for

Auch die Firewall vom Windows-Betriebssystem muss beobachtet werden:
https://www.msxfaq.de/netzwerk/grundlag ... imeout.htm

Ich empfehle die Verwendung des "Broadband Quality Monitor" von www.thinkbroadband.com zur Leitungsüberwachung:

https://www.thinkbroadband.com/broadban ... ng/quality

https://www.thinkbroadband.com/faq/broa ... ty-monitor

aktuelle-lancom-router-serie-f41/1781va ... 18179.html
geho
Beiträge: 10
Registriert: 11 Okt 2018, 20:55
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von geho »

Hallo,

die Problemursache wird schwierig zu finden sein, da hier vermutlich die Vorgeschichte der vom Provider ausgeteilten Präfixe wichtig ist.
Ein 'show ipv6-prefixes' auf der Konsole im Fehlerfall und wenn die Verbindung wieder funktioniert ist hier vermutlich die einzige Informationsquelle auf die im Fehlerfall noch zugegriffen werden kann.
Wenn möglich wäre es daher sinnvoll dauerhaft den 'ipv6-config' Trace und eventuell noch den 'icmpv6' Trace auf dem Gerät mitlaufen zu lassen um mitzubekommen, ob die valid oder preferred Lifetime des zugeteilten Präfixes abläuft.
Wird ein dynamisches Präfix mittels DHCPv6 zugeteilt wäre eventuell auch noch der 'dhcpv6-client' Trace hilfreich.
OnkelThomas
Beiträge: 7
Registriert: 27 Jul 2020, 16:21
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von OnkelThomas »

Danke für die Antworten.
Es bleibt interessant. Wenn es läuft liefert 'show ipv6-prefixes' das hier:

Code: Alles auswählen

> show ipv6-prefixes
delegated prefixes:

INTERNET-DEFAULT:
2a02:8070:XXXX:73fc::/62 (Type: DHCPv6 Client IA_PD) preferred: 3599s valid: 7199s

advertised prefixes:

GAESTE:
2a02:8070:XXXX:73ff::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


INTRANET:
2a02:8070:XXXX:73fd::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


LAGER:
2a02:8070:XXXX:73fe::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


deprecated prefixes:
Die Sekunden zählen dabei nicht herunter. Sind bei wiederholtem ausführen des Befehls also gleich. Wenn es dann plötzlich nicht mehr geht, sieht es so aus:

Code: Alles auswählen

> show ipv6-prefixes
delegated prefixes:

INTERNET-DEFAULT:
2a02:8070:XXXX:73fc::/62 (Type: DHCPv6 Client IA_PD) preferred: 0s valid: 1623s

advertised prefixes:

GAESTE:
2a02:8070:XXXX:73ff::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


INTRANET:
2a02:8070:XXXX:73fd::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


LAGER:
2a02:8070:XXXX:73fe::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


deprecated prefixes:
Die Sekunden bei INTERNET-DEFAULT valid zählen diesmal aber herunter. Ist null erreicht funktioniert wieder alles. :-)

Während für die Clients kein IPv6 läuft, kann man auf der LANCOM-Konsole pingen.

Code: Alles auswählen

> ping heise.de

    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=0 time=19.300 ms
    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=1 time=16.402 ms
    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=2 time=16.897 ms
    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=3 time=14.542 ms
    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=4 time=14.877 ms stop
    56 Byte Packet from 2a02:2e0:3fe:1001:302:: seq.no=5 time=14.666 ms

 ---2a02:2e0:3fe:1001:302:: ping statistic---
 56 Bytes Data, 6 Packets transmitted, 6 Packets received, 0% loss

Gibt man explizit eines der Netzte an, geht aber auch da nichts.

Code: Alles auswählen

> ping -a INTRANET heise.de
stop

 ---2a02:2e0:3fe:1001:302:: ping statistic---
 56 Bytes Data, 5 Packets transmitted, 0 Packets received, 100% loss

> ping -a LAGER heise.de
stop

 ---2a02:2e0:3fe:1001:302:: ping statistic---
 56 Bytes Data, 9 Packets transmitted, 0 Packets received, 100% loss

Bizarrer weiser scheinen während dieser Zeit Anfragen von thinkbroadband aber durchzukommen!
fdsa.png
fdsa.png (175.4 KiB) 385 mal betrachtet
Und das obwohl andere externe pings, z.B. https://dnschecker.org/ping-ipv6.php nicht durch kommen. (Es herrscht da also derselbe Zustand wie beim OpenVPN-Tunnel, der auch weiter läuft.)

Wie dem auch sei: Ist es z.B. irgendwie möglich, das der DHCPv6 Client aktiv wird wenn der Zustand:
INTERNET-DEFAULT:
2a02:8070:XXXX:73fc::/62 (Type: DHCPv6 Client IA_PD) preferred: 0s
eintritt?
OnkelThomas
Beiträge: 7
Registriert: 27 Jul 2020, 16:21
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von OnkelThomas »

Ach vergessen, Firmware 10.40.0291RU1 hab ich eingespielt.
GrandDixence
Beiträge: 686
Registriert: 19 Aug 2014, 22:41

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von GrandDixence »

OnkelThomas hat geschrieben: 09 Sep 2020, 14:11 Bizarrer weiser scheinen während dieser Zeit Anfragen von thinkbroadband aber durchzukommen!

Und das obwohl andere externe pings, z.B. https://dnschecker.org/ping-ipv6.php nicht durch kommen. (Es herrscht da also derselbe Zustand wie beim OpenVPN-Tunnel, der auch weiter läuft.)
Dieses Verhalten ist gemäss RFC 4862 korrekt:
IPv6 addresses are leased to an interface for a fixed (possibly
infinite) length of time. Each address has an associated lifetime
that indicates how long the address is bound to an interface. When a
lifetime expires, the binding (and address) become invalid and the
address may be reassigned to another interface elsewhere in the
Internet. To handle the expiration of address bindings gracefully,
an address goes through two distinct phases while assigned to an
interface. Initially, an address is "preferred", meaning that its
use in arbitrary communication is unrestricted. Later, an address
becomes "deprecated" in anticipation that its current interface
binding will become invalid. While an address is in a deprecated
state, its use is discouraged, but not strictly forbidden. New
communication (e.g., the opening of a new TCP connection) should use
a preferred address when possible. A deprecated address should be
used only by applications that have been using it and would have
difficulty switching to another address without a service disruption.
https://tools.ietf.org/html/rfc4862

Die "ICMP Echo Requests" (Ping's) von thinkbroadband werden von der SPI-Firewall als eine "bestehende Verbindung" behandelt. Dazu findet man auch einen entsprechenden Eintrag in der aktuellen Verbindungstabelle der SPI-Firewall. Die "ICMP Echo Requests" von dnschecker.org werden von der SPI-Firewall als eine neue Verbindung behandelt. Da die "Preferred"-Lebensdauer der ausgeliehenen IPv6-Adresse bereits abgelaufen ist, werden nur noch IPv6-Datenpakete von bestehenden Verbindungen akzeptiert oder weitergeleitet (bis die "Valid"-Lebensdauer abgelaufen ist).

https://de.wikipedia.org/wiki/Stateful_ ... Inspection
Die Sekunden bei INTERNET-DEFAULT valid zählen diesmal aber herunter. Ist null erreicht funktioniert wieder alles.
Stinkt nach einem Problem mit der "Reconfigure-Funktion". Offenbar funktioniert das DHCPv6 RENEW zur Verlängerung der "Preferrred"- und "Valid"-Lebensdauer nicht. Siehe dazu RFC 3633 (oder besser RFC 8415):
Each prefix has valid and preferred lifetimes whose durations are
specified in the IA_PD Prefix option for that prefix. The requesting
router uses Renew and Rebind messages to request the extension of the
lifetimes of a delegated prefix.
https://tools.ietf.org/html/rfc3633

https://tools.ietf.org/html/rfc8415

Ein sehr, sehr ähnliches Thema bei DHCPv4 ist das "DHCP-Refresh". Siehe für DHCPv4:
aktuelle-lancom-router-serie-f41/1781ef ... ml#p103659

=> Fehlersuche gemäss dem Beitrag von geho durchführen (dhcpv6-client' Trace).
Zuletzt geändert von GrandDixence am 10 Sep 2020, 22:30, insgesamt 7-mal geändert.
GrandDixence
Beiträge: 686
Registriert: 19 Aug 2014, 22:41

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von GrandDixence »

Wurde:

Setup > IPv6 > DHCPv6 > Client > Interface-Liste > Reconf-Erlauben

mit

JA

konfiguriert?

https://www.lancom-systems.de/docs/LCOS ... 2_1_8.html

https://www.lancom-systems.de/docs/LCOS ... ncept.html

RENEW mit dem DHCPv6-Client testen, gemäss den Angaben zum DHCPv6-Server:
https://www.lancom-systems.de/docs/LCOS ... ncept.html
geho
Beiträge: 10
Registriert: 11 Okt 2018, 20:55
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von geho »

Die Lifetimes von INTERNET-DEFAULT verringern sich im funktionierenden Fall also nicht? Das kann eigentlich nur passieren, wenn der DHCPv6-Client sekündlich Updates bekommet.
Ich habe mich mal mit dem Kollegen unterhalten, der den DHCPv6 betreut und er meinte, dass ein 'show dhcpv6-client' im funktionierenden und Fehlerfall weitere informationen bringen könnte und das ein dhcpv6-client trace während der Fehler auftrit zeigen könnte, ob Renews versendet werden und diese beantwortet werden.
OnkelThomas
Beiträge: 7
Registriert: 27 Jul 2020, 16:21
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von OnkelThomas »

GrandDixence hat geschrieben: 10 Sep 2020, 22:02 Wurde:

Setup > IPv6 > DHCPv6 > Client > Interface-Liste > Reconf-Erlauben

mit

JA

konfiguriert?
Ich habe den Internet-Zugang mit dem Setup-Assistent von LANconfig eingerichtet. (Eine neue Verbindung anlegen für IPv4 und IPv6 > Ethernet-Interface > WAN > Kabelmodem (mit DHCP) > Natives IPv6, IPv4 über Tunnel (DS-Lite)) Daher ist da alles leer. Werde ich bei Gelegenheit aber testen.
geho hat geschrieben: 11 Sep 2020, 15:10 Die Lifetimes von INTERNET-DEFAULT verringern sich im funktionierenden Fall also nicht? Das kann eigentlich nur passieren, wenn der DHCPv6-Client sekündlich Updates bekommet.
Ich habe (als blutiger Anfänger) eine Trace-Ausgabe erstellt und genau danach sieht es aus.
geho hat geschrieben: 11 Sep 2020, 15:10 Ich habe mich mal mit dem Kollegen unterhalten, der den DHCPv6 betreut und er meinte, dass ein 'show dhcpv6-client' im funktionierenden und Fehlerfall weitere informationen bringen könnte und das ein dhcpv6-client trace während der Fehler auftrit zeigen könnte, ob Renews versendet werden und diese beantwortet werden.
Wenn es läuft:

Code: Alles auswählen

> show ipv6-prefixes
delegated prefixes:

INTERNET-DEFAULT:
2a02:8070:XXXX:73fc::/62 (Type: DHCPv6 Client IA_PD) preferred: 3599s valid: 7199s

advertised prefixes:

GAESTE:
2a02:8070:XXXX:73ff::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


INTRANET:
2a02:8070:XXXX:73fd::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


LAGER:
2a02:8070:XXXX:73fe::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


deprecated prefixes:

> show dhcpv6-client

Client on interface INTERNET-DEFAULT is active
  Client ID                 : 0003000102a0574d14fb
  Solicit max timeout       : 3600s
  Info request max timeout  : 3600s
  Reconfigure negotiated    : No
  Info refresh time         : 86400s
  DNS servers request state : Running
    DNS server              : fd00::e228:6dff:fe55:4474
  Domain list request state : Running
  AFTR request state        : Off
  SNTP servers request state: Running
  Address request state     : Running
  PD prefix request state   : Running
    PD prefix               : 2a02:8070:XXXX:73fc::/62
      Preferred until       : 9/14/2020 14:03:50
      Valid until           : 9/14/2020 15:03:50
2020-09-14_13h23_02_IP_geht.png
2020-09-14_13h23_02_IP_geht.png (263.88 KiB) 217 mal betrachtet
Die Ausgabe wiederholt sich jede Sekunde.

Wenn es nicht läuft:

Code: Alles auswählen

> show ipv6-prefixes
delegated prefixes:

INTERNET-DEFAULT:
2a02:8070:XXXX:73fc::/62 (Type: DHCPv6 Client IA_PD) preferred: 2346s valid: 5946s

advertised prefixes:

GAESTE:
2a02:8070:XXXX:73ff::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


INTRANET:
2a02:8070:XXXX:73fd::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


LAGER:
2a02:8070:XXXX:73fe::/64 (Type: DHCPv6 Client IA_PD) preferred: 3600s valid: 7200s


deprecated prefixes:


> show dhcpv6-client

Client on interface INTERNET-DEFAULT is active
  Client ID                 : 0003000102a0574d14fb
  Solicit max timeout       : 3600s
  Info request max timeout  : 3600s
  Reconfigure negotiated    : No
  Info refresh time         : 86400s
  DNS servers request state : Running
    DNS server              : fd00::e228:6dff:fe55:4474
  Domain list request state : Running
  AFTR request state        : Off
  SNTP servers request state: Running
  Address request state     : Running
  PD prefix request state   : Running
    PD prefix               : 2a02:8070:XXXX:73fc::/62
      Preferred until       : 9/14/2020 15:43:23
      Valid until           : 9/14/2020 16:43:23
'show dhcpv6-client' sieht für mich genau gleich aus.
2020-09-14_15h09_42__IPv6_geht_nicht.png
2020-09-14_15h09_42__IPv6_geht_nicht.png (258.29 KiB) 217 mal betrachtet
Die Ausgabe wiederholt sich jede Sekunde.
GrandDixence
Beiträge: 686
Registriert: 19 Aug 2014, 22:41

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von GrandDixence »

Aus den abgebildeten Ausgaben ist ersichtlich, dass ein Problem mit der DAD vorliegt (Duplicate Address Detection). Diese schlägt stetig fehl, deshalb verwirft der LANCOM-Router im Sekundentakt die neue IPv6-Adresse und fordert im Sekundentakt beim DHCPv6-Server einen neuen IPv6-Addressbereich an.

Dieses Fehlverhalten sollte auch:

Code: Alles auswählen

# show ipv6-adresses

> TENTATIVE – Die Duplicate Address Detection (DAD) prüft die Adresse momentan. Sie steht
daher einer Verwendung für Unicast noch nicht zu Verfügung.
bestätigen. Siehe für mehr Informationen zu DAD das LCOS-Referenzhandbuch und die LCOS-Menüreferenz.

DAD ist eine Funktionalität von Neighbor Discovery Protocol (NDP):
https://en.wikipedia.org/wiki/Neighbor_ ... y_Protocol

Funktioniert NDP nicht korrekt auf diesem LANCOM-Router?

Und ja, nach dem Beheben des DAD-Problems ist dann das Problem der fehlenden Unterstützung der Reconfigure-Funktion des DHCPv6-Clients (auf dem LANCOM-Router) zu beheben.
geho
Beiträge: 10
Registriert: 11 Okt 2018, 20:55
Kontaktdaten:

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von geho »

Sowohl mein Kollege als auch ich haben uns das Ergebnis etwas genauer angeschaut.

Problematisch ist, dass der DHCPv6 Server hier keine IA_NA Adresse aus einem normalen Pool zuteilt, sondern explizit eine zu dem Identifier des Lancoms passende EUI-64 Adresse. Dumm daran ist, dass der Router sich diese ziemlich sicher schon selbst per Autoconfig zugeweisen hat, weswegen ein DHCPv6-Server normalerweise solche Adressen nicht zuteilen sollte.
Im Code gibt es da unglücklicherweise eine interne Duplicate Address Detection, die an der Stelle dann vermutlich zuschlägt, weswegen die Adresse abgelehnt wird. Ich hatte damals wohl nicht erwartet, dass ein DHCPv6 Server die Autoconfig-Adresse nochmal zuweist.
Hier kommt dann ein Fehlerverhalten des Servers zum Tragen: Wenn er mitgeteilt bekommt, dass die Adresse schon vergeben war, müsste er eigentlich eine andere Adresse zuweisen - dies passiert hier aber nicht, stattdessen wird weiter die problematische Adresse zugewiesen.

Ich werde mal schauen, wie ich der IPv6 Controlplane beibringe, in so einem Fall die IA_NA Adresse trotzdem anzunehemen.

Vermutlich kann das Problem aktuell erstmal dadurch behoben werden, das der DHCPv6-Client manuell so für die WAN Verbindung eingerichtet wird, dass er keine IA_NA Adresszuweisung akzeptiert. Dazu auf der Konsole nach /Setup/IPv6/DHCPv6/Client/Interface-List gehen (In der Webconfig von Extras/LCOS Menu Tree/Setup dorthin navigieren). Dort eine Zeile für die Wan Verbindung (vermutlich INTERNET-DEFAULT) anlegen, bei der Request-Address auf no gestellt ist.

Zum Vorschlag mit dem Reconfigure: Accept-Reconf ist bei einer nicht explizit konfigurierten Autoconfig immer gesetzt, laut Trace auch hier. Laut diesem liefert Unitymedia hier aber keinen ReconfigureKey aus.

Und noch eine allgemeine Anmerkung: Bitte, wenn möglich, in Zukunft Ausgaben als Text anhängen, dies ist im Regelfall besser zu lesen und auch besser zu zitieren.
GrandDixence
Beiträge: 686
Registriert: 19 Aug 2014, 22:41

Re: Aussetzer bei der IPv6-Konnektivität

Beitrag von GrandDixence »

geho hat geschrieben: 15 Sep 2020, 16:34Laut diesem liefert Unitymedia hier aber keinen ReconfigureKey aus.
Aus dem Trace entnehme ich nur, dass kein gültiger (valid) ReconfigureKey vom DHCPv6-Server ausgeliefert wird. Ob gar kein ReconfigureKey vom DHCPv6-Server an den DHCPv6-Client geliefert wurde, ist doch gar nicht in den Trace-Ausgaben ersichtlich? => Vielleicht mal mit Wireshark die Trace-Ausgaben kontrollieren.

Ohne gültigen ReconfigureKey vom DHCPv6-Server kann doch an diesem Internetanschluss gar kein über längere Zeit (> 2 h) stabiler und funktionstüchtigen Internetanschluss per IPv6 realisiert werden?! Ohne gültigen ReconfigureKey kein DHCPv6 RENEW oder REBIND. Ohne funktionstüchtigen DHCPv6 RENEW oder REBIND können nach einer Stunde keine neuen Verbindungen (TCP/UDP/ICMP6) aufgebaut werden (Ablauf "preferred lifetime") und nach 2 Stunden werden alle bestehenden Verbindungen zwangsgetrennt (Ablauf "valid lifetime"). Oder liege ich da falsch?
Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag

Zurück zu „Fragen zum Thema IPv6“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast