🐜 👨🏿‍⚕️ 🍍 VXLAN in NSX-V - Unruhige Unterlage 💪🏽 🚍 🧖

Grüße und zuerst ein paar Texte. Ich beneide manchmal Kollegen, die remote arbeiten - es ist großartig, von überall auf der Welt aus mit dem Internet verbunden zu sein, jederzeit Urlaub zu machen, Verantwortung für Projekte und Fristen zu übernehmen und nicht von 8 bis 17 im Büro zu sein. Meine Position und meine Arbeitsverantwortung sind praktisch ausgeschlossen die Möglichkeit einer langen Abwesenheit im Rechenzentrum. Es treten jedoch gelegentlich interessante Fälle wie der unten beschriebene auf, und ich verstehe, dass es nur wenige Positionen gibt, an denen ein solcher Spielraum für den kreativen Ausdruck einer internen Fehlerbehebung besteht.

Ein kleiner Haftungsausschluss - zum Zeitpunkt des Schreibens war der Fall noch nicht vollständig geklärt, aber angesichts der Geschwindigkeit der Antwort der Anbieter kann eine vollständige Lösung weitere Monate dauern, und ich möchte meine Ergebnisse jetzt mitteilen. Ich hoffe, liebe Leser, Sie werden mir diese Eile vergeben. Aber genug Wasser - was ist mit dem Fall?

Erste Einführung: Es gibt ein Unternehmen (in dem ich als Netzwerktechniker arbeite), das Client-Lösungen in der privaten Cloud von VMWare hostet. Die meisten neuen Lösungen stellen eine Verbindung zu den VXLAN-Segmenten her, die von NSX-V gesteuert werden. Ich werde nicht bewerten, wie viel Zeit mir diese Lösung, kurz gesagt, viel Zeit gekostet hat. Ich habe es sogar geschafft, meine Kollegen für die Konfiguration von NSX ESG zu schulen, und Small Client-Lösungen werden ohne meine Teilnahme bereitgestellt. Ein wichtiger Hinweis ist die Steuerebene mit Unicast-Replikation. Hypervisoren sind über zwei Schnittstellen redundant mit verschiedenen physischen Juniper QFX5100-Switches (in Virtual Chassis montiert) verbunden, und die Route der Timing-Richtlinien basierend auf dem ursprünglichen virtuellen Port dient der Vollständigkeit.

Client-Lösungen sind sehr heterogen: von Windows IIS, wo alle Webserver-Komponenten auf einem Computer installiert sind, bis hin zu recht großen - zum Beispiel Apache-Webfronten mit Lastenausgleich + LB MariaDB in Galera + Server-Ballons, die mit GlusterFS synchronisiert wurden. Fast jeder Server muss separat überwacht werden, und nicht alle Komponenten haben öffentliche Adressen. Wenn Sie auf dieses Problem gestoßen sind und eine elegantere Lösung gefunden haben, berate ich Sie gerne.
Meine Überwachungslösung besteht darin, die Firewall (Fortigate) mit jedem internen Client-Netzwerk (+ SNAT und natürlich strengen Einschränkungen hinsichtlich der Art des zulässigen Datenverkehrs) zu verbinden und die internen Adressen zu überwachen. Auf diese Weise wird eine gewisse Vereinheitlichung und Vereinfachung der Überwachung erreicht. Die Überwachung selbst erfolgt über einen Cluster von PRTG-Servern. Das Überwachungsschema sieht ungefähr so aus:

Bild

Während wir nur mit VLAN arbeiteten, war alles ganz normal und funktionierte vorhersehbar wie eine Uhr. Nach der Implementierung standen NSX-V und VXLAN vor der Frage: Ist es möglich, die Überwachung auf die alte Weise fortzusetzen? Zum Zeitpunkt dieser Frage bestand die schnellste Lösung darin, das NSX ESG bereitzustellen und die VXLAN-Trunk-Schnittstelle mit dem VTEP-Netzwerk zu verbinden. Schnelle Anführungszeichen - da die Verwendung der GUI zum Konfigurieren von Client-Netzwerken SNAT- und Firewall-Regeln die Verwaltung in einer einzigen vSphere-Schnittstelle vereinheitlichen können, ist dies meiner Meinung nach ziemlich umständlich und schränkt unter anderem die Tools zur Fehlerbehebung ein. Diejenigen, die die NSX ESG als Ersatz für eine „echte“ Firewall verwendet haben, würden dem zustimmen. Obwohl eine solche Lösung wahrscheinlich stabiler wäre - schließlich geschieht alles im Rahmen eines Anbieters.

Eine andere Lösung besteht darin, das NSX-DLR im Bridge-Modus zwischen VLAN und VXLAN zu verwenden. Hier denke ich, dass alles klar ist - der Vorteil der Verwendung von VXLAN ist kitschig -, da Sie in diesem Fall das VLAN immer noch zur Überwachungsinstallation ziehen müssen. Übrigens stieß ich bei der Ausarbeitung dieser Lösung auf ein Problem, als die DLR-Brücke keine Pakete an die virtuelle Maschine sendete, mit der sie sich auf demselben Host befand. Ich weiß, ich weiß - in Büchern und Handbüchern zu NSX-V wird ausdrücklich angegeben, dass ein separater Cluster für NSX Edge zugewiesen werden sollte, aber dies steht in den Büchern ... Wie auch immer, nach ein paar Monaten mit Unterstützung haben wir das Problem nicht gelöst. Im Prinzip habe ich die Logik der Aktion verstanden - das für die VXLAN-Kapselung verantwortliche Hypervisor-Kernmodul wurde nicht aktiviert, wenn sich das DLR und der überwachte Server auf demselben Host befanden, da der Datenverkehr den Host nicht verlässt und logischerweise mit dem VXLAN-Segment verbunden sein sollte - eine Kapselung ist nicht erforderlich.Mit Unterstützung haben wir uns für die virtuelle Schnittstelle vdrPort entschieden, die Uplinks logisch kombiniert und auch Bridging / Kapselung durchführt. Dort wurde eine Nichtübereinstimmung im eingehenden Datenverkehr festgestellt, die ich im aktuellen Fall ausgearbeitet habe. Aber wie gesagt, ich habe diesen Fall nicht bis zum Ende abgeschlossen, da er auf ein anderes Projekt übertragen wurde und die Niederlassung anfangs in einer Sackgasse lag und kein besonderer Wunsch bestand, ihn weiterzuentwickeln. Wenn ich mich nicht irre, wurde das Problem in den Versionen NSX und 6.1.4 und 6.2 beobachtet.da es auf ein anderes Projekt übertragen wurde und die Niederlassung anfänglich in einer Sackgasse lag und kein besonderer Wunsch bestand, es zu entwickeln. Wenn ich mich nicht irre, wurde das Problem in den Versionen NSX und 6.1.4 und 6.2 beobachtet.da es auf ein anderes Projekt übertragen wurde und die Niederlassung anfangs in einer Sackgasse lag und kein besonderer Wunsch bestand, es weiterzuentwickeln. Wenn ich mich nicht irre, wurde das Problem in den Versionen NSX und 6.1.4 und 6.2 beobachtet.

Und hier - Bingo! Fortinet annonsiruet native Unterstützung VXLAN . Und nicht nur Punkt-zu-Punkt- oder VXLAN-over-IPSec, nicht softwarebasiertes VLAN-VXLAN-Bridging - all dies wurde seit Version 5.4 implementiert (und von anderen Anbietern vorgestellt)), aber echte Unterstützung für Unicast-Steuerebene. Bei der Implementierung der Lösung stieß ich auf ein anderes Problem: Die überprüften Server „verschwanden“ regelmäßig und traten manchmal bei der Überwachung auf, obwohl die virtuelle Maschine selbst noch am Leben war. Der Grund dafür war, dass ich vergessen habe, Ping auf der VXLAN-Schnittstelle zu aktivieren. Beim Neuausgleich der Cluster wurden die virtuellen Maschinen verschoben, und vMotion endete mit Ping, um den neuen ESXI-Host anzugeben, auf den die Maschine verschoben wurde. Meine Dummheit, aber dieses Problem untergrub erneut die Glaubwürdigkeit der Unterstützung - in diesem Fall Fortinet. Ich sage nicht, dass jeder Fall im Zusammenhang mit VXLAN mit der Frage beginnt, wo sich der VLAN-VXLAN-Softswitch in Ihren Einstellungen befindet. Diesmal wurde mir geraten, die MTU zu ändern - dies ist für Ping, das sind 32 Bytes. Dann "herumspielen" mit tcp-send-mss und tcp-receive-mss in der Richtlinie - für VXLAN,welches in UDP gekapselt ist. Fuf, es tut mir leid - es kocht. Im Allgemeinen habe ich dieses Problem selbst gelöst.

Nachdem der Testverkehr erfolgreich zurückgesetzt wurde, wurde beschlossen, diese Lösung zu implementieren. Und in der Produktion stellte sich heraus, dass nach ein oder zwei Tagen alles, was über VXLAN überwacht wird, allmählich ganz abfällt. Das Deaktivieren / Aktivieren der Schnittstelle hat geholfen, aber nur vorübergehend. Angesichts der Verlangsamung des Supports begann ich meinerseits mit der Fehlerbehebung - am Ende liegt es in meiner Verantwortung, mein Unternehmen und mein Netzwerk.

Unter dem Spoiler befindet sich der Verlauf der Fehlersuche. Wer müde von Briefen und Prahlerei ist - überspringen und zur Postanalyse gehen.

Fehlerbehebung

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

Was haben wir also am Ende? Nach der Migration der virtuellen Maschine versucht der Fortigate, Datenverkehr von der (richtigen) VXLAN-FDB an VTEP zu senden, verwendet jedoch den falschen DST-MAC und der Datenverkehr wird voraussichtlich von der empfangenden Hypervisor-Schnittstelle verworfen. Darüber hinaus gehörte dieser MAC in einem von vier Fällen zum ursprünglichen Hypervisor, von dem aus die Migration der Maschine begann.

Gestern erhielt ich einen Brief vom technischen Support von Fortinet - in meinem Fall wurde der Fehler 615586 geöffnet. Ich weiß nicht, wie ich mich freuen oder trauern soll: Einerseits liegt das Problem nicht in den Einstellungen, andererseits wird das Update nur mit dem Firmware-Update geliefert, im besten Fall im Folgenden. Die FAQ heizt auch einen weiteren Fehler auf, den ich letzten Monat entdeckt habe, allerdings zu diesem Zeitpunkt in der HTML5-GUI vSphere. Nun, die lokale QS-Abteilung der Anbieter ist direkt ...

Ich werde Folgendes vorschlagen:

1 - Multicast-Steuerebene wird höchstwahrscheinlich nicht von dem beschriebenen Problem betroffen sein - schließlich werden die VTEP-MAC-Adressen von der IP-Adresse der Gruppe erhalten, für die die Schnittstelle abonniert ist.

2 - höchstwahrscheinlich das Problem von Fortics in Offload-Sitzungen auf dem Netzwerkprozessor (ungefähr analog zu CEF) - Wenn jedes Paket durch die CPU geleitet wird, werden Tabellen verwendet, die - zumindest visuell - die richtigen Informationen enthalten. Für diese Annahme ist es hilfreich, die Schnittstelle zu schließen / zu öffnen oder eine Weile zu warten - mehr als 5 Minuten.

3 - Wenn Sie beispielsweise die Teaming-Richtlinie in ein explizites Failover ändern oder die LAG einführen, wird das Problem nicht gelöst, da der MAC, der in gekapselten Paketen auf dem ursprünglichen Hypervisor steckt, beobachtet wurde.

Vor diesem Hintergrund kann ich mitteilen, was ich kürzlich in einem Blog entdeckt habeIn einem der Artikel wurde festgestellt, dass stetige Firewalls und zwischengespeicherte Datenübertragungsmethoden Krücken sind. Nun, ich bin nicht so erfahren in der IT, um dasselbe zu sagen, und ich stimme nicht sofort allen Aussagen der Blog-Artikel zu. Etwas sagt mir jedoch, dass Iwans Worte etwas Wahres enthalten.

Vielen Dank für Ihre Aufmerksamkeit! Gerne beantworte ich Fragen und höre konstruktive Kritik.

VXLAN in NSX-V - Unruhige Unterlage

More articles: