VXLAN in NSX-V — Troubleshooting Underlay

Guten Tag! Zunächst ein wenig persönliche Gedanken. Manchmal beneide ich meine Kollegen, die remote arbeiten — es ist einfach fantastisch, von überall auf der Welt, das mit dem Internet verbunden ist, arbeiten zu können. Urlaub zu jeder Zeit, Verantwortung für Projekte und Fristen, ohne von 8 bis 17 Uhr im Büro sein zu müssen. Meine Position und meine Aufgaben lassen kaum Raum für längere Abwesenheiten im Rechenzentrum. Dennoch gibt es gelegentlich interessante Fälle, wie den unten beschriebenen, und ich erkenne, dass es nur wenige Stellen gibt, die so viel Spielraum für kreative Lösungen bieten wie die eines internen Troubleshooters.

Ein kleiner Hinweis — zum Zeitpunkt des Schreibens dieses Artikels ist der Fall noch nicht vollständig gelöst, aber aufgrund der Reaktionsgeschwindigkeit der Anbieter kann die vollständige Lösung einige Monate in Anspruch nehmen. Ich möchte jedoch jetzt schon meine Erkenntnisse mit Ihnen teilen. Ich hoffe, verehrte Leser, dass Sie mir diese Eile verzeihen. Doch genug der Einleitung — wie steht es um den Fall?

Zunächst eine Einleitung: Es gibt ein Unternehmen (bei dem ich als Netzwerkingenieur arbeite), das Kundenlösungen in einer privaten VMWare-Cloud hostet. Die meisten neuen Lösungen sind mit VXLAN-Segmenten verbunden, die von NSX-V verwaltet werden — ich werde nicht bewerten, wie viel Zeit mir diese Lösung eingespart hat, kurz gesagt — es ist viel. Ich habe sogar geschafft, Kollegen in der Konfiguration von NSX ESG zu schulen, und kleine Kundenlösungen werden ohne mein Eingreifen bereitgestellt. Eine wichtige Anmerkung — der Steuerungsebene verwenden wir Unicast-Replikation. Die Hypervisoren sind redundant mit zwei Schnittstellen an verschiedene physische Juniper QFX5100-Switches (die in einem Virtual Chassis zusammengeschlossen sind) angeschlossen und die Routing-Politik basiert auf dem ursprünglichen virtuellen Port — das soll die vollständige Bild vermitteln.

Die Kundenlösungen sind sehr heterogen: von Windows IIS, bei dem alle Komponenten des Webservers auf einer Maschine installiert sind, bis hin zu ziemlich großen Lösungen — zum Beispiel Lastenausgeglichene Apache-Webfronten + LB MariaDB in Galera + Datei-Server, die mit GlusterFS synchronisiert sind. Praktisch jeder Server muss separat überwacht werden, und nicht alle Komponenten haben öffentliche Adressen — wenn Sie sich mit dieser Aufgabe auskennen und eine elegantere Lösung haben, würde ich mich über Ihren Rat freuen.
Meine Monitoring-Lösung besteht darin, die Firewall (Fortigate) in jedes interne Kundennetzwerk zu „integrieren“ (+SNAT und natürlich strenge Einschränkungen bezüglich des erlaubten Datenverkehrs) und die internen Adressen zu überwachen – auf diese Weise wird eine gewisse Vereinheitlichung und Vereinfachung der Überwachung erreicht. Die Überwachung erfolgt aus einem PRTG-Server-Cluster. Das Überwachungsschema sieht etwa so aus:

Solange wir nur mit VLANs arbeiteten, war alles ganz normal und funktionierte wie am Schnürchen. Nach der Einführung von NSX-V und VXLAN stießen wir auf die Frage – können wir die Überwachung wie gewohnt fortsetzen? Zu diesem Zeitpunkt war die "schnellste" Lösung die Bereitstellung von NSX ESG und das Anschließen des VXLAN-Trunk-Interfaces an das VTEP-Netzwerk. "Schnell" in Anführungszeichen – denn die Verwendung des GUIs zur Konfiguration von Kundennetzwerken, SNAT und Firewall-Regeln mag die Verwaltung in einem einzigen vSphere-Interface vereinheitlichen, aber meiner Meinung nach ist es ziemlich unhandlich und schränkt zudem die Werkzeugpalette für das Troubleshooting ein. Diejenigen, die NSX ESG als Ersatz für eine "echte" Firewall verwendet haben, werden dem denke ich zustimmen. Obwohl, so eine Lösung wäre wahrscheinlich stabiler – schließlich geschieht alles im Rahmen eines Anbieters.

Eine weitere Lösung besteht darin, den NSX DLR im Bridge-Modus zwischen VLAN und VXLAN zu verwenden. Hier ist alles klar – die Vorteile von VXLAN werden durch die Notwendigkeit, VLAN zu den Monitoring-Installationen zu ziehen, zunichte gemacht. Übrigens stieß ich bei der Implementierung dieser Lösung auf ein Problem, bei dem der DLR-Bridge keine Pakete an die VM übermittelte, die sich auf demselben Host befand. Ich weiß, ich weiß – in den Büchern und Leitfäden zu NSX-V steht ausdrücklich, dass für NSX Edge ein eigener Cluster eingerichtet werden muss, aber das steht nur in den Büchern… Jedenfalls konnten wir das Problem nach ein paar Monaten mit dem Support nicht lösen. Grundsätzlich habe ich die Logik verstanden – das Kernel-Modul des Hypervisors, das für die VXLAN-Kapselung verantwortlich ist, wurde nicht aktiviert, wenn DLR und der beobachtete Server auf demselben Host waren, da der Verkehr den Host nicht verlässt und logischerweise an den VXLAN-Segment angeschlossen sein sollte – Kapselung ist nicht notwendig. Mit dem Support kamen wir auf die virtuelle Schnittstelle vdrPort, die logisch die UpLinks zusammenführt und auch die Bridging/Kapselung durchführt – dort wurde eine Diskrepanz im eingehenden Verkehr festgestellt, die ich für den aktuellen Fall bearbeitet habe. Aber wie gesagt, ich habe diesen Fall nicht vollständig bearbeitet, da ich auf ein anderes Projekt umgeschichtet wurde und die Äste ursprünglich ohne Ausweg waren, sodass ich nicht wirklich daran interessiert war, sie weiterzuentwickeln. Wenn ich mich nicht irre, trat das Problem in den Versionen NSX 6.1.4 und 6.2 auf.

Und hier — Bingo! Fortinet kündigt native Unterstützung für VXLAN. Und nicht nur Point-to-Point oder VXLAN-over-IPSec, keine Software-Bridging von VLAN-VXLAN – all das wurde bereits mit Version 5.4 eingeführt (und ist auch bei anderen Anbietern), sondern echte Unterstützung des Unicast-Control-Planes. Bei der Implementierung der Lösung stieß ich auf ein weiteres Problem – die überwachten Server verschwanden gelegentlich und tauchten wieder im Monitoring auf, obwohl die virtuelle Maschine aktiv war. Der Grund war, wie sich herausstellte, dass ich vergessen hatte, Ping auf dem VXLAN-Interface zuzulassen. Während des Rebalancierens der Cluster wurden die VMs verschoben, und der vMotion wurde durch einen Ping abgeschlossen, um den neuen ESXI-Host zu kennzeichnen, auf den die Maschine verschoben wurde. Ein Fehler meinerseits, aber dieses Problem hat mein Vertrauen in den Support des Herstellers – in diesem Fall Fortinet – erneut erschüttert. Ich möchte nicht einmal erwähnen, dass jeder Fall im Zusammenhang mit VXLAN mit der Frage beginnt: „Wo finden wir in Ihren Einstellungen den Softswitch VLAN-VXLAN?“ Dieses Mal wurde mir geraten, die MTU zu ändern – das betrifft den Ping, der 32 Bytes beträgt. Danach „spiele“ mit tcp-send-mss und tcp-receive-mss in der Richtlinie – für VXLAN, das in UDP enkapsuliert wird. Puh, entschuldigen Sie – das musste raus. Insgesamt habe ich dieses Problem selbst gelöst.

Nach dem erfolgreichen Testverkehr wurde beschlossen, diese Lösung einzuführen. In der Produktionsumgebung stellte sich jedoch heraus, dass nach ein oder zwei Tagen alles, was über VXLAN überwacht wurde, allmählich ausfiel. Das Deaktivieren und Aktivieren der Schnittstelle half, aber nur für eine gewisse Zeit. Angesichts der langsamen Reaktionszeiten des Supports habe ich selbst mit dem Troubleshooting begonnen — schließlich ist meine Firma, mein Netzwerk — meine Verantwortung.

Unter dem Spoiler findet sich der Verlauf des Troubleshootings. Wer von Buchstaben und Prahlerei genug hat — überspringt und geht zur Nachanalyse über.

Verlauf des TroubleshootingsDanke, dass Sie weitergelesen haben — wir machen weiter!

Das Monitoring funktioniert eine Weile, fällt dann aber von selbst aus. Das deutet darauf hin, dass es wahrscheinlich keine Probleme mit den Firewall-Richtlinien gibt. Da ich jedoch mit hängenden Systemprozessen in Fortigate-Versionen 5.6+ konfrontiert war, schauen wir zuerst mit „diagnose debug flow“ nach. Der erwartete Verkehr wird zugelassen und verlässt die Schnittstelle, jedoch kommt erwartungsgemäß nichts als Antwort zurück. Also müssen wir weiter im Stack graben. Leider müssen die Adressen, selbst wenn es sich um RFC1918-Adressen handelt, verborgen werden, aber ich hoffe, den Prozess mit ausreichend Beschreibung für das Verständnis zu versehen. Der Server innerhalb des VXLAN hat die Adresse x.x.x.15, die Schnittstelle des Fortigate hat die Adresse x.x.x.254, alle anderen Adressen gehören zum VTEP-Netzwerk.

Für die erfolgreiche Übertragung von VXLAN-kapsulierten Paketen ist die korrekte Information in mehreren Tabellen erforderlich. Für Overlay sind das ARP und OVSDB, für Underlay ARP und CAM. Bei Fortigate sind VXLAN FDB und OVSDB identisch. Dort beginnen wir:

 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

Hier ist alles ziemlich einfach — die MAC-Adresse der virtuellen Maschine sollte sich auf dem VTEP mit der Adresse u.u.u.47 befinden. Nachdem ich den Inhalt und die Einstellungen des ESXi-Clusters überprüft habe, stelle ich fest, dass die MAC der virtuellen Maschine korrekt ist und die VTEP-Adresse ebenfalls. Ich prüfe die CAM/ARP-Tabelle auf dem Fortigate — auch hier stimmen alle Einstellungen mit denen des ESXi-Hosts überein:

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

Die Tabellen sind korrekt und der Verkehr läuft — könnte das Problem nicht bei Fortigate liegen? Ich habe absichtlich die Analyse des Traffic-Switchings auf dem Juniper ausgelassen — logisch wäre der nächste Schritt zur Fehlersuche dort, aber mein Netzwerk ist einfach — nur ein VLAN für VTEP und alle Komponenten sind direkt verbunden. Außerdem erinnere ich mich an den Fall mit dem DLR-Bridge, VDR und dem verschwundenen Verkehr — ich gehe daraufhin zur Analyse auf dem ESXi-Host und erstelle parallel dazu einen Fall bei VMWare. Unten gehört die MAC „97:6e“ zu Fortigate, vmnic1 — das ist das Interface, das VTEP mit der Adresse u.u.u.47 hat. Wir schnüffeln in beide Richtungen "—dir 2":

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

Der Fortschritt — im Sniffer sehe ich die ARP-Anfrage und die ankommende Antwort. Ich bringe nur die ARP-Antwort, und da ist alles korrekt. Ich habe nicht erwähnt, dass der Monitoring-Server die Adresse x.x.x.15 anpingt — wo bleibt der ICMP-Verkehr? Ich erinnere mich, dass ich zwei Uplinks habe. Hier könnte man argumentieren, dass der virtuelle Quellport derselbe ist (meine Teaming-Richtlinie), das heißt, für dasselbe vNIC sollte immer derselbe Uplink ausgewählt werden. Aber da ich auf dem Host bin, ist es kein Problem, einen anderen Uplink zu überprüfen:

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

Es kommen Anfragen vom FortiGate, aber es gibt keine Antwort. Das heißt, das Problem liegt nicht beim FortiGate. Nun gut, denke ich, wieder das gleiche Problem mit dem fehlenden Verkehr auf dem VDR, wieder ein paar Monate, um den Fall in die richtige Richtung zu lenken. Nach ein paar Tagen, etwas abgekühlt und nicht bereit, mich mit dem Stillstand abzufinden, beschloss ich, weitere Sniff-Daten für den Support zu sammeln, um den Prozess zu beschleunigen. Und da „zufällig“ mein Blick auf die Ethernet-Kapselung unterlay fällt. Der König ist nicht echt, und die MAC-Adresse des VTEP stimmt nicht mit seiner IP überein. Ich setze alles zurück, schnüffle, grabe — richtig, dass es nicht richtig ist. Ich werde die ARP-Tabelle daneben anführen, um den Vergleich zu erleichtern. Bitte beachten Sie die erste Ethernet-Kapselung im oberen Bild:

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

Also, was haben wir am Ende — nach der Migration der virtuellen Maschine versucht Fortigate, den Verkehr zum VTEP aus der (korrekten) VXLAN FDB zu senden, verwendet jedoch die falsche DST MAC, und der Verkehr wird erwartungsgemäß vom empfangenden Schnittstelle des Hypervisors verworfen. Darüber hinaus gehörte in einem von vier Fällen diese MAC dem ursprünglichen Hypervisor, von dem die Migration der Maschine begann.

Gestern erhielt ich eine E-Mail vom technischen Support von Fortinet — in meinem Fall wurde der Bug 615586 eröffnet. Ich weiß nicht, ob ich mich freuen oder trauern soll: einerseits liegt das Problem nicht an den Einstellungen, andererseits wird die Behebung nur mit einem Firmware-Update kommen, im besten Fall mit dem nächsten. Auch ein weiterer Bug, den ich letzten Monat entdeckt habe, heizt mein Ego an, dieser jedoch im HTML5 GUI vSphere. Ich habe das Gefühl, dass es wie ein lokales QA-Team bei den Anbietern ist...

Ich wage zu vermuten, dass Folgendes zutrifft:

1 — Es ist sehr wahrscheinlich, dass der Multicast-Control-Plane nicht von dem beschriebenen Problem betroffen sein wird — denn die MAC-Adressen des VTEP stammen aus der IP-Adresse der Gruppe, auf die die Schnittstelle abonniert ist.

2 — höchstwahrscheinlich handelt es sich um ein Problem des Fortigate mit dem Offload von Sitzungen auf dem Network Processor (vergleichbar mit CEF) — wenn jedes Paket durch die CPU geleitet wird, werden die Tabellen verwendet, die die korrekten — zumindest visuell — Informationen enthalten. Zu dieser Annahme spricht, dass es hilft, das Interface zu schließen oder zu öffnen oder einige Zeit zu warten — länger als 5 Minuten.

3 — eine Änderung der Teaming-Policy, zum Beispiel auf explicit failover, oder die Implementierung von LAG wird das Problem nicht lösen, da ein 'Feststecken' der MAC des ursprünglichen Hypervisors in den inkapsulierten Paketen beobachtet wurde.

In diesem Zusammenhang möchte ich teilen, dass ich kürzlich entdeckt habe dem Blog, wo in einem der Artikel behauptet wurde, dass stateful Firewalls und caching Methoden zur Datenübertragung — ein Strohhalm sind. Nun, ich bin nicht so erfahren in der IT, um so etwas zu behaupten, und außerdem stimme ich nicht sofort mit allen Aussagen der Blogartikel überein. Dennoch sagt mir etwas, dass da ein Körnchen Wahrheit in den Worten von Ivan steckt.

Vielen Dank für Ihre Aufmerksamkeit! Ich freue mich darauf, Fragen zu beantworten und konstruktive Kritik zu hören.

Quelle: habr.com