{"id":628,"date":"2016-06-16T17:39:06","date_gmt":"2016-06-16T15:39:06","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=628"},"modified":"2018-08-06T15:43:27","modified_gmt":"2018-08-06T13:43:27","slug":"wie-auto-negotiation-auf-ha-port-abschalten","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2016\/06\/wie-auto-negotiation-auf-ha-port-abschalten\/","title":{"rendered":"Wie Auto Negotiation auf HA Port abschalten?"},"content":{"rendered":"<p>In einem Hochverf\u00fcgbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang &#8220;klassisch&#8221; per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL\/Glasfasern verbundene Serverr\u00e4ume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuf\u00fchrung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische &#8220;Static IP&#8221; Konfiguration.<\/p>\n<p>F\u00fcr alle im Einsatz befindlichen Interfaces (hier: External, Trusted und eine DMZ) wurde pro Serverraum jeweils ein dedizierter Cisco-Switch bereitgestellt, die per LWL direkt miteinander verbunden sind. Die HA-Ports der Fireboxen wurden jedoch NICHT \u00fcber Switche, sondern DIREKT miteinander verbunden &#8211; mit zwei Medienkonvertern, die RJ45 auf LWL umsetzen. Bei Inbetriebnahme des Clusters stellte sich heraus, dass die Heartbeats zwischen den Fireboxen nicht korrekt liefen, die Synchronisation der Konfiguration nur teilweise funktionierte und h\u00e4ufig zuf\u00e4llige Failovers ausgel\u00f6st wurden.<\/p>\n<p>Problemursache war das offenbar nicht korrekt funktionierende Auto-Sensing zwischen Firebox und Medienkonverter am HA-Interface. Die Konverter waren nicht managebar, also musste seitens der Firebox ein fester Wert f\u00fcr den Betrieb des HA-Interfaces eingestellt werden, z.B. 100 Mbit Full-Duplex. Die GUI des Policy Managers erlaubt dies aber nicht! Sobald HA auf einem Interface aktiviert wird, wird dort automatisch &#8220;Auto-Sensing&#8221; eingestellt &#8211; auch wenn das Interface vorher fest mit 100 Mbit Full-Duplex konfiguriert wurde&#8230;<\/p>\n<p>Abhilfe schafft hier der manuelle Eingiff in die XML-Konfigurationsdatei. Nach Aktivierung von HA kann in der XML-Datei f\u00fcr das entsprechende Interface der Wert f\u00fcr &lt; auto-sensing &gt; von 1 auf 0 ge\u00e4ndert und die gew\u00fcnschten Parameter (100 Mbit, Full Duplex) eingetragen werden. Im vorliegenden Fall musste diese Einstellung anschlie\u00dfend auch noch f\u00fcr diezweite Firebox manuell in deren Konfigurationsdatei ge\u00e4ndert werden, denn die Synchronisation der Konfigurationen lief auch nach Anpassung der ersten Firebox noch immer nicht korrekt. Danach funktionierte der HA Cluster jedoch korrekt.<\/p>\n<p>Hinweis: Manuelle Eingriffe in die XML-Konfigurationsdatei werden von WatchGuard offiziell &#8220;nicht supported&#8221; und erfolgen auf &#8220;eigene Gefahr&#8221;.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In einem Hochverf\u00fcgbarkeits-Projekt sollten zwei WatchGuard Firebox X5000 mit Fireware 10.2.11, die bislang &#8220;klassisch&#8221; per Crossover-Patchkabel miteinander verbunden waren, auf zwei mehrere Hundert Meter auseinander liegende, aber mit ausreichend LWL\/Glasfasern verbundene Serverr\u00e4ume verteilt werden. Die Telekom stellte zudem eine Zweiwege-Zuf\u00fchrung bereit. Die beteiligten Router regeln die dynamische Umschaltung der IP-Adressen im Bedarfsfall selbst. Aus Sicht des Firebox-Clusters handelt es sich also um eine einfache, klassische &hellip; <a href=\"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2016\/06\/wie-auto-negotiation-auf-ha-port-abschalten\/\" class=\"more-link\">Weiterlesen <span class=\"screen-reader-text\">Wie Auto Negotiation auf HA Port abschalten?<\/span> <span class=\"meta-nav\">&raquo;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[63,62,129],"class_list":["post-628","post","type-post","status-publish","format-standard","hentry","category-watchguard-technischer-blog","tag-auto-sense","tag-ethernet","tag-high-availability"],"_links":{"self":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/628"}],"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\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/comments?post=628"}],"version-history":[{"count":1,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/628\/revisions"}],"predecessor-version":[{"id":629,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/posts\/628\/revisions\/629"}],"wp:attachment":[{"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/media?parent=628"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/categories?post=628"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/wp-json\/wp\/v2\/tags?post=628"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}