IPv6: Clients verlieren Verbindung ins Internet

[Zapad]

Tja heute wieder mal.... IPv6 vom Wan ist zwar da aber von keiner Seite erkannt.


habe nun Promiscous Modus ausgehackt, übernommen und siehe da die IP6 ist wieder da!


Anscheinend liegt es nicht an promiscous sondern das beim übernehmen irgendendwas neuinitialisiert/gestartet wird!


wäre nett wenn man das identifiziert und behebt.

[meyergru]

Sicherlich nicht, ohne dass jemand einen Bugreport auf Github schreibt, der nachvollziehbare Schritte zur Nachbildung des Problems enthält... und wer könnte das besser, als jemand, der das Problem hat? ;-)

[bamf]

BTW: Wie vergibst Du eigentlich die ULAs auf den (V)LANs? Als Virtual IPs?

Genau, ich habe auf LAN und GUEST je eine Virtual IP gesetzt.

Nein. Die ersten 56 Bits sind gleich, dann musst Du 8 Bits selbst - aber anders - setzen, als auf dem LAN-Interface, dann die EUI-64 des WAN-Interfaces. Und ja, mit /64er Netzmaske. Oder eben, wie Patrick sagt: DHCPv6 auf dem WAN, aber die (V)LANs mit statischer Konfiguration. Da gilt dann das selbe, jedes Interface muss die 8 Bits anders gesetzt haben.

Ich verstehe noch nicht ganz, wie ich das nun machen muss. Brauche ich dafür nicht auch die Default Route? Und dafür auch einen Scope? Die muss ich dann auch händisch konfigurieren?

Auf dem WAN-Interface zeigt mir die CLI aktuell das hier an:

Code Select Expand

WAN_Telekom (pppoe0) -> v4/PPPoE: 87.128.39.65/32
                    v6/DHCP6: fe80::227c:14ff:fef5:9cf9%pppoe0/64

Code Select Expand

pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN_Telekom (opt1)
        options=0
        inet 87.128.39.65 --> 62.156.244.47 netmask 0xffffffff
        inet6 fe80::227c:14ff:fef5:9cf9%pppoe0 prefixlen 64 scopeid 0x10
        inet6 fe80::227c:14ff:fef5:9cfb%pppoe0 prefixlen 64 scopeid 0x10
        inet6 2003:a:37f:a71a:227c:14ff:fef5:9cf9 prefixlen 64 autoconf pltime 1800 vltime 14400
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

[bamf]

Ich konnte das Problem leider immer noch nicht lösen.

Ich habe den kompletten log Ordner gesichert vor dem Reboot. Gerade war es wieder kaputt.

Wonach muss ich suchen in den Logs?

[bamf]

Es scheint so, als ob ich das Problem gefunden habe. 2 Tage sind vergangen und IPv6 funktioniert immer noch.

Was ich getan habe: Alle Hardware Offloading-Funktionen deaktiviert.

Hardware CRC Disable hardware checksum offload
Hardware TSO Disable hardware TCP segmentation offload
Hardware LRO Disable hardware large receive offload

Wie lässt sich das erklären? Das war alles aktiv und es hat vorher monatelang funktioniert.

[JamesFrisch]

Checksum offloading is broken in some hardware, particularly some Realtek cards. Rarely, drivers may have problems with checksum offloading and some specific NICs.

This offloading is broken in some hardware drivers, and may impact performance with some specific NICs.

This offloading is broken in some hardware drivers, and may impact performance with some specific NICs.

Scheint fast, als wäre es aus guten Grund per default ausgeschaltet ;)

[bamf]

Klar, aber es hat ja eben monatelang ohne Probleme funktioniert. Wenn meine NIC da einen Bug hätte, hätte es ja schon von Anfang an Probleme geben müssen.

Die NIC ist ein Intel X553.