WatchGuard Cluster in Verbindung mit Dynamic Arp Inspection (DAI)

WatchGuard verwendet im Cluster-Betrieb virtuelle Mac-Adressen. Bei einem Cluster-Failover wird dann ein Gratious Arp Paket gesendet, damit alle beteiligten Switches ihre ARP-Table bzw. ihre Mac-Adress-Port-Table anpassen können. Dies kann bei leistungsfähigen Switches mit aktueller Firmware möglicherweise zu Problemen führen, wenn man die Konfiguration nicht entsprechend anpasst.

Hintergrund

Zum Beispiel (diese Woche in der Praxis erlebt): Cisco Core Switch C6807-XL

Dort können Ports prinzipiell als Trunk-Ports oder als Access-Ports konfiguriert werden.

Trunk-Ports

• Verwendung als Uplink-Ports für die Kaskade zu anderen Access-Switches
• Diese Ports sind i.d.R. Hybrid-Ports (d.h. sie unterstützen VLANS und akzeptieren Pakete sowohl Tagged als auch Untagged)
• i.d.R. zunächst keine Einschränkung der verwendeten VLANs (transparent)
• ARP-Pakete und insbesondere Gratious ARP Informationen werden akzeptiert, um die lokalen Tables zu aktualisieren.

Access-Ports

• Verwendung zum Anschluss von “Endgeräten”, also z.B. PCs, Server, Router, Gateways, etc.
• Diese Ports werden i.d.R. definiert konfiguriert, ob Tagged oder Untagged, und es wird explizit definiert, welche VLANs erlaubt sind.
• Gratious ARP Pakete werden möglicherweise per default abgelehnt.

Was passiert hier?

Dies führt dazu, dass bei einem Konstrukt mit verteilten Switches (Core-Switch physikalisch auf zwei RZs aufgeteilt, aber logisch ein Switch) im Failover-Fall folgendes Szenario auftreten kann:

• WatchGuard in RZ1 ist aktiv
• Failover der WatchGuard wird eingeleitet
• die zweite WatchGuard im RZ2 sendet einen Gratious Arp
• der kommt nur auf dem Switch in RZ2 an und wird möglicherweise dort lokal akzeptiert aber nicht an den Switch in RZ1 weitergeleitet
• damit haben die beiden physikalischen Core-Switche-Hälften unterschiedliche Informationen bzgl. Mac-Adress-Port-Zuordnung der aktiven Firewall
• der Spaß im Netzwerk beginnt je nachdem ob ein Endgerät an der “linken” oder “rechten” Core-Switch-Hälfte hängt, funktioniert sein Zugang ins Internet (über die Firewall), oder eben nicht.
• nach ca. 10 min (abhängig vom Arp-Table-Timeout) löst sich das Problem von selbst.
• bei einem Failback wird das Problem möglicherweise gespiegelt, und die andere Hälfte der Endgeräte kann die Firewall/das Internet erreichen.
• nach ca. 10 min (abhängig vom Arp-Table-Timeout) löst sich das Problem von selbst.
• ein Power-Cycle beider Firewall-Nodes führt zum Reset der Arp-Einträge auf dem Core-Switch, und das Problem ist ebenfalls gelöst.

Prüfung

Ein Prüfen der entsprechenden Ports kann wie folgt erfolgen; ein “Untrusted” bewirkt ein Verwerfen der Gratious Arp Pakete.

sw-core#show ip arp inspection interfaces TenGigabitEthernet2/1/24
Interface       Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Te2/1/24        Untrusted           15              1
sw-core#show ip arp inspection interfaces TenGigabitEthernet1/1/24
Interface       Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Te1/1/24        Untrusted           15              1
sw-core#

Umkonfigurieren

Die abschließende Prüfung sollte “Trusted” anzeigen.

sw-core#conf ter
sw-core(config)#interface TenGigabitEthernet2/1/24
sw-core(config-if)#ip arp inspection trust 
sw-core(config-if)#interface TenGigabitEthernet1/1/24
sw-core(config-if)#ip arp inspection trust 
sw-core(config-if)#end
sw-core#show ip arp inspection interfaces TenGigabitEthernet1/1/24
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Te1/1/24        Trusted           None            N/A
sw-core#show ip arp inspection interfaces TenGigabitEthernet2/1/24
Interface Trust State Rate (pps) Burst Interval
--------------- ----------- ---------- --------------
Te1/2/24        Trusted           None            N/A
sw-core#

Das Ganze muss natürlich für möglicherweise alle Portgruppen/VLANs passieren, die über den entsprechenden Coreswitch laufen. Im obigen Fall war “nur” das Trusted Interface der WatchGuard direkt mit dem Core-Switch verbunden, während die anderen Zonen (DMZs, und WLAN-VLAN-Trunks etc.) über Access-Switches gelaufen und somit beim Core-Switch über Trunk-Ports angekommen sind.

Je nach Firmware-Version und Hersteller kann natürlich

• der Default abweichen (dann fällt es ggf. gar nicht auf)
• die genaue Syntax abweichen (dann bitte im entsprechenden Manual nachsehen)

Ein abschließender Test des Failovers sollte das normale Verhalten zeigen:

• Failover über Firebox System Manager einleiten
• typisch 1 Ping Verlust nach außen
• BOVPNs sollten übernommen werden
• TCP-Sessions sollten übernommen werden
• Mobile-VPN-User müssen sich neu einloggen (passiert ggf. im Hintergrund transparent je nach Konfiguration)
• Sessions über TCP-Proxies (SMTP-Proxy, HTTPs-Proxy, HTTP-Proxy etc.) werden terminiert.

Quellen:

• Gratious Arp (Wireshark Wiki)
• Dynamic Arp Inspection (Cisco Dokumentation)
• Befehlssyntax (Cisco Dokumentaion)