{"id":5725,"date":"2018-12-08T13:13:54","date_gmt":"2018-12-08T12:13:54","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=5725"},"modified":"2024-07-23T15:20:30","modified_gmt":"2024-07-23T13:20:30","slug":"watchguard-cluster-in-verbindung-mit-dynamic-arp-inspection-dai","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2018\/12\/watchguard-cluster-in-verbindung-mit-dynamic-arp-inspection-dai\/","title":{"rendered":"WatchGuard Cluster in Verbindung mit Dynamic Arp Inspection (DAI)"},"content":{"rendered":"<p>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\u00f6nnen. Dies kann bei leistungsf\u00e4higen Switches mit aktueller Firmware m\u00f6glicherweise zu Problemen f\u00fchren, wenn man die Konfiguration nicht entsprechend anpasst.<\/p>\n<p><!--more--><\/p>\n<h4>Hintergrund<\/h4>\n<p>Zum Beispiel (diese Woche in der Praxis erlebt): Cisco Core Switch C6807-XL<\/p>\n<p>Dort k\u00f6nnen Ports prinzipiell als Trunk-Ports oder als Access-Ports konfiguriert werden.<\/p>\n<h4>Trunk-Ports<\/h4>\n<ul>\n<li>Verwendung als Uplink-Ports f\u00fcr die Kaskade zu anderen Access-Switches<\/li>\n<li>Diese Ports sind i.d.R. Hybrid-Ports (d.h. sie unterst\u00fctzen VLANS und akzeptieren Pakete sowohl Tagged als auch Untagged)<\/li>\n<li>i.d.R. zun\u00e4chst keine Einschr\u00e4nkung der verwendeten VLANs (transparent)<\/li>\n<li>ARP-Pakete und insbesondere Gratious ARP Informationen werden akzeptiert, um die lokalen Tables zu aktualisieren.<\/li>\n<\/ul>\n<h4>Access-Ports<\/h4>\n<ul>\n<li>Verwendung zum Anschluss von &#8220;Endger\u00e4ten&#8221;, also z.B. PCs, Server, Router, Gateways, etc.<\/li>\n<li>Diese Ports werden i.d.R. definiert konfiguriert, ob Tagged oder Untagged, und es wird explizit definiert, welche VLANs erlaubt sind.<\/li>\n<li>Gratious ARP Pakete werden m\u00f6glicherweise per default abgelehnt.<\/li>\n<\/ul>\n<h4>Was passiert hier?<\/h4>\n<p>Dies f\u00fchrt 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:<\/p>\n<ul>\n<li>WatchGuard in RZ1 ist aktiv<\/li>\n<li>Failover der WatchGuard wird eingeleitet<\/li>\n<li>die zweite WatchGuard im RZ2 sendet einen Gratious Arp<\/li>\n<li>der kommt nur auf dem Switch in RZ2 an und wird m\u00f6glicherweise dort lokal akzeptiert aber nicht an den Switch in RZ1 weitergeleitet<\/li>\n<li>damit haben die beiden physikalischen Core-Switche-H\u00e4lften unterschiedliche Informationen bzgl. Mac-Adress-Port-Zuordnung der aktiven Firewall<\/li>\n<li>der Spa\u00df im Netzwerk beginnt je nachdem ob ein Endger\u00e4t an der &#8220;linken&#8221; oder &#8220;rechten&#8221; Core-Switch-H\u00e4lfte h\u00e4ngt, funktioniert sein Zugang ins Internet (\u00fcber die Firewall), oder eben nicht.<\/li>\n<li>nach ca. 10 min (abh\u00e4ngig vom Arp-Table-Timeout) l\u00f6st sich das Problem von selbst.<\/li>\n<li>bei einem Failback wird das Problem m\u00f6glicherweise gespiegelt, und die andere H\u00e4lfte der Endger\u00e4te kann die Firewall\/das Internet erreichen.<\/li>\n<li>nach ca. 10 min (abh\u00e4ngig vom Arp-Table-Timeout) l\u00f6st sich das Problem von selbst.<\/li>\n<li>ein Power-Cycle beider Firewall-Nodes f\u00fchrt zum Reset der Arp-Eintr\u00e4ge auf dem Core-Switch, und das Problem ist ebenfalls gel\u00f6st.<\/li>\n<\/ul>\n<h4>Pr\u00fcfung<\/h4>\n<p>Ein Pr\u00fcfen der entsprechenden Ports kann wie folgt erfolgen; ein &#8220;Untrusted&#8221; bewirkt ein Verwerfen der Gratious Arp Pakete:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">sw-core#show ip arp inspection interfaces TenGigabitEthernet2\/1\/24\r\nInterface       Trust State Rate (pps) Burst Interval\r\n--------------- ----------- ---------- --------------\r\nTe2\/1\/24        Untrusted           15              1\r\nsw-core#show ip arp inspection interfaces TenGigabitEthernet1\/1\/24\r\nInterface       Trust State Rate (pps) Burst Interval\r\n--------------- ----------- ---------- --------------\r\nTe1\/1\/24        Untrusted           15              1\r\nsw-core#<\/pre>\n<h4>Umkonfigurieren<\/h4>\n<p>Die abschlie\u00dfende Pr\u00fcfung sollte &#8220;Trusted&#8221; anzeigen:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">sw-core#conf ter\r\nsw-core(config)#interface TenGigabitEthernet2\/1\/24\r\nsw-core(config-if)#ip arp inspection trust \r\nsw-core(config-if)#interface TenGigabitEthernet1\/1\/24\r\nsw-core(config-if)#ip arp inspection trust \r\nsw-core(config-if)#end\r\nsw-core#show ip arp inspection interfaces TenGigabitEthernet1\/1\/24\r\nInterface Trust State Rate (pps) Burst Interval\r\n--------------- ----------- ---------- --------------\r\nTe1\/1\/24        Trusted           None            N\/A\r\nsw-core#show ip arp inspection interfaces TenGigabitEthernet2\/1\/24\r\nInterface Trust State Rate (pps) Burst Interval\r\n--------------- ----------- ---------- --------------\r\nTe1\/2\/24        Trusted           None            N\/A\r\nsw-core#<\/pre>\n<p>Das Ganze muss nat\u00fcrlich f\u00fcr m\u00f6glicherweise alle Portgruppen\/VLANs passieren, die \u00fcber den entsprechenden Coreswitch laufen. Im obigen Fall war &#8220;nur&#8221; das Trusted Interface der WatchGuard direkt mit dem Core-Switch verbunden, w\u00e4hrend die anderen Zonen (DMZs, und WLAN-VLAN-Trunks etc.) \u00fcber Access-Switches gelaufen und somit beim Core-Switch \u00fcber Trunk-Ports angekommen sind.<\/p>\n<p>Je nach Firmware-Version und Hersteller kann nat\u00fcrlich<\/p>\n<ul>\n<li>der Default abweichen (dann f\u00e4llt es ggf. gar nicht auf)<\/li>\n<li>die genaue Syntax abweichen (dann bitte im entsprechenden Manual nachsehen)<\/li>\n<\/ul>\n<p>Ein abschlie\u00dfender Test des Failovers sollte das normale Verhalten zeigen:<\/p>\n<ul>\n<li>Failover \u00fcber Firebox System Manager einleiten<\/li>\n<li>typisch 1 Ping Verlust nach au\u00dfen<\/li>\n<li>BOVPNs sollten \u00fcbernommen werden<\/li>\n<li>TCP-Sessions sollten \u00fcbernommen werden<\/li>\n<li>Mobile-VPN-User m\u00fcssen sich neu einloggen (passiert ggf. im Hintergrund transparent je nach Konfiguration)<\/li>\n<li>Sessions \u00fcber TCP-Proxies (SMTP-Proxy, HTTPs-Proxy, HTTP-Proxy etc.) werden terminiert.<\/li>\n<\/ul>\n<h4>Quellen<\/h4>\n<ul>\n<li><a href=\"https:\/\/wiki.wireshark.org\/Gratuitous_ARP\" target=\"_blank\" rel=\"noopener\">Gratious Arp (Wireshark Wiki)<\/a><\/li>\n<li><a href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/switches\/lan\/catalyst4500\/12-2\/25ew\/configuration\/guide\/conf\/dynarp.html\" target=\"_blank\" rel=\"noopener\">Dynamic Arp Inspection (Cisco Dokumentation)<\/a><\/li>\n<li><a href=\"https:\/\/www.cisco.com\/c\/m\/en_us\/techdoc\/dc\/reference\/cli\/n5k\/commands\/ip-arp-inspection-trust.html\" target=\"_blank\" rel=\"noopener\">Befehlssyntax (Cisco Dokumentaion)<\/a><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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\u00f6nnen. Dies kann bei leistungsf\u00e4higen Switches mit aktueller Firmware m\u00f6glicherweise zu Problemen f\u00fchren, wenn man die Konfiguration nicht entsprechend anpasst.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[507,84,506,86,504,505,290,503,502],"class_list":["post-5725","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-arp","tag-arp-table","tag-cisco","tag-cluster","tag-dai","tag-dynamic-arp-inspection","tag-failover","tag-gratious-arp","tag-switch"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/5725"}],"collection":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/comments?post=5725"}],"version-history":[{"count":6,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/5725\/revisions"}],"predecessor-version":[{"id":21199,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/5725\/revisions\/21199"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=5725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=5725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=5725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}