IPv6 Frage - NDP Cache, MaxRtrAdvInterval etc... wenn CARP im Spiel ist.

[Monviech (Cedrik)]

Ich hatte vor ein paar Wochen die CARP Dokumentation um IPv6 erweitert: https://docs.opnsense.org/manual/how-tos/carp.html#configuring-carp-with-ipv6

Ich würde jetzt noch gerne das Verhalten besser erklären können, wenn ein Failover mit IPv6 passiert, und benötige dafür mehr Wissen.

Ich interpretiere es so, dass wenn der Failover passiert, die virtuelle MAC der CARP Link Local IPv6 Adresse gleich bleibt. Die Master Rolle geht auf die zweite Firewall über. Das sendende physikalische Interface hat jetzt aber eine andere MAC Adresse, deswegen funktioniert IPv6 nicht mehr, bis die neue MAC Adresse bei den Clients angekommen ist (z.B. durch Router Advertisements). Jetzt kann es also passieren, dass IPv6 für mehrere Minuten nicht richtig funktioniert, bis alle Clients ihren NDP Cache gelöscht haben und neue Router Advertisements erhalten haben (und auch akzeptiert haben).

Zusätzlich gibt es noch die "Unsolicited Neighbor Advertisements" (RFC 2461 - 7.2.6.), würden die in diesem Failover Fall gesendet werden um das aktualisieren des NDP Cache auf den Clients zu beschleunigen?

Oder ist alles vom NDP Cache Timeouts der Clients abhängig, und vom Sendeintervall der "Unsolicited Router Advertisements" (RFC 2461 6.2.4)

Hier würde IPv6 theoretisch so lange nicht funktionieren wenn MaxRtrAdvInterval auf Standard ist:

Code: [Select]

      MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

                     Default: 600 seconds
 

Code: [Select]

     AdvDefaultLifetime
                     The value to be placed in the Router Lifetime field
                     of Router Advertisements sent from the interface,
                     in seconds.  MUST be either zero or between
                     MaxRtrAdvInterval and 9000 seconds.  A value of
                     zero indicates that the router is not to be used as
                     a default router.

                     Default: 3 * MaxRtrAdvInterval
3 * 600 = 1800 Sekunden = 30 Minuten

Würde der Failover von IPv6 geringer ausfallen, wenn man MaxRtrAdvInterval auf 4 Sekunden stellt (Minimaler Wert erlaubt nach RFC)?

Dann wäre es theoretisch 12 Sekunden bis alle Clients wieder funktionieren.

Ich bin für Hinweise dankbar.


Ich hab mal mit GPT4 darüber geredet und das sind die Ergebnisse:

Code: [Select]

In einer CARP-Umgebung (Common Address Redundancy Protocol) gibt es im Kontext von IPv6 einige wichtige Punkte, die du erwähnst, und die sich auf den Failover und das Verhalten der Clients auswirken können. Ich versuche, deine Fragen so präzise und technisch wie möglich zu beantworten:

NDP Cache und Failover: Du hast richtig verstanden, dass bei einem Failover die virtuelle MAC-Adresse konstant bleibt, aber die physikalische MAC-Adresse des sendenden Interfaces sich ändert. Das erfordert ein Update im NDP (Neighbor Discovery Protocol) Cache der Clients, welches durch Router Advertisements oder Unsolicited Neighbor Advertisements beschleunigt werden kann.

Unsolicited Neighbor Advertisements: Diese Pakete werden in der Regel gesendet, um den NDP Cache der Clients schneller zu aktualisieren. In einem Failover-Szenario wären sie äußerst nützlich, um die Zeit bis zur Wiederherstellung der Konnektivität zu minimieren.

MaxRtrAdvInterval und NDP Cache Timeouts: Du hast Recht, dass diese Parameter entscheidend für die Zeit sind, die benötigt wird, um alle Clients wieder zu einem funktionalen Zustand zu bringen. Wenn MaxRtrAdvInterval auf den Standardwert von 600 Sekunden gesetzt ist, dann könnte es theoretisch bis zu 30 Minuten dauern, bis die Konnektivität vollständig wiederhergestellt ist, da das Standard AdvDefaultLifetime 3 * MaxRtrAdvInterval beträgt.

Optimierung durch Anpassung von MaxRtrAdvInterval: Ja, die Reduzierung des MaxRtrAdvInterval auf den minimalen Wert von 4 Sekunden würde den Failover erheblich beschleunigen. Das AdvDefaultLifetime würde dann theoretisch auf 12 Sekunden fallen, was bedeutet, dass die Clients schneller aktualisiert würden.

Beachte jedoch, dass eine zu aggressive Konfiguration von MaxRtrAdvInterval auch Nachteile haben kann, wie eine erhöhte Last auf dem Netzwerk und den beteiligten Geräten.

Insgesamt hängt die Effektivität des Failovers von einer Reihe von Faktoren ab, einschließlich, aber nicht beschränkt auf, die Konfiguration der Router Advertisements, die NDP-Cache-Politik auf den Clients und wie schnell Unsolicited Neighbor Advertisements verschickt werden können. Es könnte sinnvoll sein, diese Parameter in einer Testumgebung zu optimieren und dann die Ergebnisse zu überwachen.

Code: [Select]

User
Würde eine Firewall überhaupt ein Unsolicited Neighbor Advertisement senden? Bei einer CARP Umgebung würde bei einem Hardware Ausfall ja kein "hot swap" der Netzwerkkarte geschehen, sodass auf der gleichen Firewall die MAC Adresse geändert wird. Sondern es gibt einen Failover auf eine andere Hardware. Warum sollte die zweite Firewall das Advertisement senden, an ihr hat sich ja nichts geändert.
ChatGPT
Du bringst einen wichtigen Punkt auf. In einer typischen CARP-Umgebung, bei der die zweite (Backup-) Firewall die Master-Rolle übernimmt, ändert sich die physikalische MAC-Adresse für die zugehörige IPv6-Adresse. Die Backup-Firewall hat keinen Grund, ein Unsolicited Neighbor Advertisement für die vorherige (nun ausgefallene) Master-Firewall zu senden, da sie selbst keine Änderungen erfahren hat.

In der Regel senden Systeme Unsolicited Neighbor Advertisements, um den NDP Cache auf den Clients zu aktualisieren, wenn sich ihre eigenen Link-Layer-Adressinformationen ändern. In einem CARP-Failover-Szenario ändern sich jedoch die Link-Layer-Adressinformationen der virtuellen IP nicht; es ändert sich nur die physikalische Firewall, die die virtuelle IP bedient.

Aus diesem Grund würden Unsolicited Neighbor Advertisements in diesem Kontext nicht automatisch gesendet. Das System, das die Master-Rolle übernimmt, sieht sich selbst nicht als "geändert", auch wenn es die Master-Rolle für die virtuelle IP von einer anderen Firewall übernimmt.

Daher wäre es in einem solchen Szenario wichtig, das Verhalten der NDP Caches der Clients durch andere Mechanismen zu steuern, z. B. durch Anpassung des MaxRtrAdvInterval wie du bereits erwähnt hast. Einige fortgeschrittene CARP-Implementierungen könnten auch Skripte oder spezielle Konfigurationsoptionen bieten, um nach einem Failover gezielt Unsolicited Neighbor Advertisements auszusenden, aber das wäre eine spezielle und keine standardmäßige Funktion.

Code: [Select]

User
Warum senden Clients nicht an die virtuelle MAC Addresse sondern an die physikalische Adresse wenn NDP verwendet wird?
ChatGPT
In einem CARP-Setup (Common Address Redundancy Protocol) wird die virtuelle MAC-Adresse in der Regel nicht für den tatsächlichen Datenverkehr zwischen Client und Server (oder Firewall) verwendet. Stattdessen dient sie als gemeinsame "Anlaufstelle" für ARP- oder NDP-Anfragen, sodass die physikalische Hardware transparent wechseln kann, ohne die IP-Adresse zu ändern.

Im Kontext von IPv6 und dem Neighbor Discovery Protocol (NDP) arbeitet es wie folgt:

Der Client erhält Router Advertisements, die von der Master-Firewall gesendet werden, und fügt die empfangene Information in seinen NDP-Cache ein. Die Information enthält die Link-Layer-Adresse (MAC-Adresse) des Routers (der Master-Firewall) für eine bestimmte IPv6-Adresse.

Wenn der Client Daten an eine externe IPv6-Adresse senden möchte, prüft er seinen NDP-Cache, um die entsprechende Link-Layer-Adresse für die IPv6-Adresse des Routers zu finden.

Der Client sendet dann das Paket an die physikalische MAC-Adresse der Master-Firewall, da diese Information im NDP-Cache hinterlegt ist.

Im Falle eines Failovers:

Die Backup-Firewall übernimmt die Master-Rolle und beginnt, Router Advertisements mit ihrer eigenen physikalischen MAC-Adresse zu senden.

Die Clients aktualisieren schließlich ihren NDP-Cache mit der neuen physikalischen MAC-Adresse, sobald sie die neuen Router Advertisements empfangen.

Die virtuelle MAC-Adresse dient also hauptsächlich dazu, den Failover-Prozess zu erleichtern und die Auswahl der Master-Firewall zu steuern. Der eigentliche Datenverkehr erfolgt jedoch über die physikalische MAC-Adresse der jeweiligen aktiven (Master-) Firewall. Das ist der Grund, warum bei einem Failover eine Aktualisierung des NDP-Caches erforderlich ist, um die neue physikalische MAC-Adresse aufzunehmen.