{"id":73232,"date":"2020-03-08T08:42:18","date_gmt":"2020-03-08T05:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay"},"modified":"2020-03-08T08:42:18","modified_gmt":"2020-03-08T05:42:18","slug":"vxlan-v-nsx-v-trablshutim-underlay","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN in NSX-V \u2014 Troubleshooting Underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Guten Tag! Zun\u00e4chst ein wenig Poetisches. Manchmal beneide ich meine Kollegen, die aus der Ferne arbeiten \u2014 es ist einfach gro\u00dfartig, die Freiheit zu haben, von \u00fcberall auf der Welt, das mit dem Internet verbunden ist, zu arbeiten. Die M\u00f6glichkeit, jederzeit Urlaub zu nehmen, und Verantwortung f\u00fcr Projekte und Deadlines zu tragen, statt von 8 bis 17 Uhr im B\u00fcro zu sitzen. Meine Position und meine Aufgaben lassen kaum Raum f\u00fcr l\u00e4ngere Abwesenheiten im Rechenzentrum. Doch hin und wieder treten spannende F\u00e4lle auf, wie der folgende, und ich erkenne, dass es nur wenige Positionen gibt, die so viel Raum f\u00fcr kreatives Ausdrucksverm\u00f6gen eines internen Troubleshooters bieten.
\n<\/a><\/noindex>
\nEin kleiner Hinweis \u2014 zum Zeitpunkt des Schreibens dieses Artikels ist der Fall noch nicht vollst\u00e4ndig gel\u00f6st, aber aufgrund der Reaktionsgeschwindigkeit der Anbieter kann die vollst\u00e4ndige L\u00f6sung einige Monate in Anspruch nehmen. Ich m\u00f6chte jedoch jetzt schon meine Erkenntnisse mit Ihnen teilen. Ich hoffe, verehrte Leser, dass Sie mir diese Eile verzeihen. Doch genug der Einleitung \u2014 wie steht es um den Fall? <\/p>\n

Zun\u00e4chst eine Einleitung: Es gibt ein Unternehmen (bei dem ich als Netzwerkingenieur arbeite), das Kundenl\u00f6sungen in einer privaten VMWare-Cloud hostet. Die meisten neuen L\u00f6sungen sind mit VXLAN-Segmenten verbunden, die von NSX-V verwaltet werden \u2014 ich werde nicht bewerten, wie viel Zeit mir diese L\u00f6sung eingespart hat, kurz gesagt \u2014 es ist viel. Ich habe sogar geschafft, Kollegen in der Konfiguration von NSX ESG zu schulen, und kleine Kundenl\u00f6sungen werden ohne mein Eingreifen bereitgestellt. Eine wichtige Anmerkung \u2014 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\u00fcnglichen virtuellen Port \u2014 das soll die vollst\u00e4ndige Bild vermitteln.<\/p>\n

Die Kundenl\u00f6sungen sind sehr heterogen: von Windows IIS, bei dem alle Komponenten des Webservers auf einer Maschine installiert sind, bis hin zu ziemlich gro\u00dfen L\u00f6sungen \u2014 zum Beispiel Lastenausgeglichene Apache-Webfronten + LB MariaDB in Galera + Datei-Server, die mit GlusterFS synchronisiert sind. Praktisch jeder Server muss separat \u00fcberwacht werden, und nicht alle Komponenten haben \u00f6ffentliche Adressen \u2014 wenn Sie sich mit dieser Aufgabe auskennen und eine elegantere L\u00f6sung haben, w\u00fcrde ich mich \u00fcber Ihren Rat freuen.
\nMeine Monitoring-L\u00f6sung besteht darin, die Firewall (Fortigate) in jedes interne Kundennetzwerk zu \u201eintegrieren\u201c (+SNAT und nat\u00fcrlich strenge Einschr\u00e4nkungen bez\u00fcglich des erlaubten Datenverkehrs) und die internen Adressen zu \u00fcberwachen \u2013 auf diese Weise wird eine gewisse Vereinheitlichung und Vereinfachung der \u00dcberwachung erreicht. Die \u00dcberwachung erfolgt aus einem PRTG-Server-Cluster. Das \u00dcberwachungsschema sieht etwa so aus:<\/p>\n

\"VXLAN
\n
\nSolange wir nur mit VLANs arbeiteten, war alles ganz normal und funktionierte wie am Schn\u00fcrchen. Nach der Einf\u00fchrung von NSX-V und VXLAN stie\u00dfen wir auf die Frage \u2013 k\u00f6nnen wir die \u00dcberwachung wie gewohnt fortsetzen? Zu diesem Zeitpunkt war die \"schnellste\" L\u00f6sung die Bereitstellung von NSX ESG und das Anschlie\u00dfen des VXLAN-Trunk-Interfaces an das VTEP-Netzwerk. \"Schnell\" in Anf\u00fchrungszeichen \u2013 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\u00e4nkt zudem die Werkzeugpalette f\u00fcr das Troubleshooting ein. Diejenigen, die NSX ESG als Ersatz f\u00fcr eine \"echte\" Firewall verwendet haben, werden dem denke ich zustimmen. Obwohl, so eine L\u00f6sung w\u00e4re wahrscheinlich stabiler \u2013 schlie\u00dflich geschieht alles im Rahmen eines Anbieters.<\/p>\n

Eine weitere L\u00f6sung besteht darin, den NSX DLR im Bridge-Modus zwischen VLAN und VXLAN zu verwenden. Hier ist alles klar \u2013 die Vorteile von VXLAN werden durch die Notwendigkeit, VLAN zu den Monitoring-Installationen zu ziehen, zunichte gemacht. \u00dcbrigens stie\u00df ich bei der Implementierung dieser L\u00f6sung auf ein Problem, bei dem der DLR-Bridge keine Pakete an die VM \u00fcbermittelte, die sich auf demselben Host befand. Ich wei\u00df, ich wei\u00df \u2013 in den B\u00fcchern und Leitf\u00e4den zu NSX-V steht ausdr\u00fccklich, dass f\u00fcr NSX Edge ein eigener Cluster eingerichtet werden muss, aber das steht nur in den B\u00fcchern\u2026 Jedenfalls konnten wir das Problem nach ein paar Monaten mit dem Support nicht l\u00f6sen. Grunds\u00e4tzlich habe ich die Logik verstanden \u2013 das Kernel-Modul des Hypervisors, das f\u00fcr 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\u00e4sst und logischerweise an den VXLAN-Segment angeschlossen sein sollte \u2013 Kapselung ist nicht notwendig. Mit dem Support kamen wir auf die virtuelle Schnittstelle vdrPort, die logisch die UpLinks zusammenf\u00fchrt und auch die Bridging\/Kapselung durchf\u00fchrt \u2013 dort wurde eine Diskrepanz im eingehenden Verkehr festgestellt, die ich f\u00fcr den aktuellen Fall bearbeitet habe. Aber wie gesagt, ich habe diesen Fall nicht vollst\u00e4ndig bearbeitet, da ich auf ein anderes Projekt umgeschichtet wurde und die \u00c4ste urspr\u00fcnglich 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. <\/p>\n

Und hier \u2014 Bingo! Fortinet k\u00fcndigt native Unterst\u00fctzung f\u00fcr VXLAN<\/a><\/noindex>. Und nicht nur Point-to-Point oder VXLAN-over-IPSec, keine Software-Bridging von VLAN-VXLAN \u2013 all das wurde bereits mit Version 5.4 eingef\u00fchrt (und ist auch bei anderen Anbietern<\/a><\/noindex>), und die tats\u00e4chliche Unterst\u00fctzung des Unicast-Control-Planes. Bei der Implementierung der L\u00f6sung stie\u00df ich auf ein weiteres Problem - die \u00fcberwachten Server verschwanden gelegentlich und tauchten im Monitoring wieder auf, obwohl die virtuelle Maschine selbst aktiv war. Der Grund daf\u00fcr war, dass ich vergessen hatte, Ping auf dem VXLAN-Interface zuzulassen. W\u00e4hrend des Rebalancierungsprozesses der Cluster wurden die virtuellen Maschinen verschoben, und der Ping beendete den vMotion, um den neuen ESXi-Host anzuzeigen, auf den die Maschine verschoben wurde. Mein Fehler, aber dieses Problem hat erneut das Vertrauen in den Support des Herstellers, in diesem Fall Fortinet, ersch\u00fcttert. Ich m\u00f6chte gar nicht erw\u00e4hnen, dass jeder Fall, der mit VXLAN verbunden ist, mit der Frage beginnt: \u201eWo haben Sie in Ihren Einstellungen den Softswitch VLAN-VXLAN?\u201c Diesmal wurde mir geraten, MTU zu \u00e4ndern - das betrifft den Ping, der 32 Bytes betr\u00e4gt. Dann \u201espielen Sie\u201c mit tcp-send-mss und tcp-receive-mss in der Richtlinie - f\u00fcr VXLAN, das in UDP eingekapselt ist. Puh, Entschuldigung - es hat mich gestresst. Insgesamt habe ich dieses Problem selbst gel\u00f6st. <\/p>\n

Nach dem erfolgreichen Testverkehr wurde beschlossen, diese L\u00f6sung einzuf\u00fchren. In der Produktionsumgebung stellte sich jedoch heraus, dass nach ein oder zwei Tagen alles, was \u00fcber VXLAN \u00fcberwacht wurde, allm\u00e4hlich ausfiel. Das Deaktivieren und Aktivieren der Schnittstelle half, aber nur f\u00fcr eine gewisse Zeit. Angesichts der langsamen Reaktionszeiten des Supports habe ich selbst mit dem Troubleshooting begonnen \u2014 schlie\u00dflich ist meine Firma, mein Netzwerk \u2014 meine Verantwortung. <\/p>\n

Unter dem Spoiler findet sich der Verlauf des Troubleshootings. Wer von Buchstaben und Prahlerei genug hat \u2014 \u00fcberspringt und geht zur Nachanalyse \u00fcber.<\/p>\n

Verlauf des Troubleshootings<\/b>Danke, dass Sie weitergelesen haben \u2014 wir machen weiter!<\/p>\n

Das Monitoring funktioniert eine Weile, f\u00e4llt dann aber von selbst aus. Das deutet darauf hin, dass es wahrscheinlich keine Probleme mit den Firewall-Richtlinien gibt. Da ich jedoch mit h\u00e4ngenden Systemprozessen in Fortigate-Versionen 5.6+ konfrontiert war, schauen wir zuerst mit \u201ediagnose debug flow\u201c nach. Der erwartete Verkehr wird zugelassen und verl\u00e4sst die Schnittstelle, jedoch kommt erwartungsgem\u00e4\u00df nichts als Antwort zur\u00fcck. Also m\u00fcssen wir weiter im Stack graben. Leider m\u00fcssen die Adressen, selbst wenn es sich um RFC1918-Adressen handelt, verborgen werden, aber ich hoffe, den Prozess mit ausreichend Beschreibung f\u00fcr das Verst\u00e4ndnis 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\u00f6ren zum VTEP-Netzwerk.<\/p>\n

F\u00fcr die erfolgreiche \u00dcbertragung von VXLAN-kapsulierten Paketen ist die korrekte Information in mehreren Tabellen erforderlich. F\u00fcr Overlay sind das ARP und OVSDB, f\u00fcr Underlay ARP und CAM. Bei Fortigate sind VXLAN FDB und OVSDB identisch. Dort beginnen wir:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=\u0443.\u0443.\u0443.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nHier ist alles ziemlich einfach \u2014 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 \u00fcberpr\u00fcft habe, stelle ich fest, dass die MAC der virtuellen Maschine korrekt ist und die VTEP-Adresse ebenfalls. Ich pr\u00fcfe die CAM\/ARP-Tabelle auf dem Fortigate \u2014 auch hier stimmen alle Einstellungen mit denen des ESXi-Hosts \u00fcberein:<\/p>\n
fortigate (root) #get sys arp | grep u.u.u.47\nu.u.u.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nDie Tabellen sind korrekt, und der Datenverkehr flie\u00dft \u2014 k\u00f6nnte das Problem nicht am Fortigate liegen? Ich habe die Analyse des Datenverkehrs auf dem Juniper absichtlich ausgelassen \u2014 logisch betrachtet sollte der n\u00e4chste Schritt zur Fehlersuche dort stattfinden, aber mein Netzwerk ist einfach \u2014 nur ein VLAN f\u00fcr VTEP und alle Komponenten sind direkt verbunden. Au\u00dferdem erinnere ich mich an den Fall mit dem DLR-Bridge, VDR und dem verschwundenen Datenverkehr \u2014 ich gehe schn\u00fcffeln auf dem ESXi-Host und erstelle gleichzeitig einen Fall bei VMware. Unten geh\u00f6rt die MAC \u00ab97:6e\u00bb zu dem Fortigate, vmnic1 ist das Interface, das VTEP mit der Adresse u.u.u.47 hat; wir schn\u00fcffeln in beide Richtungen \"\u2014dir 2\".<\/p>\n
pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nDer Fortschritt \u2014 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\u00e4hnt, dass der Monitoring-Server die Adresse x.x.x.15 anpingt \u2014 wo bleibt der ICMP-Verkehr? Ich erinnere mich, dass ich zwei Uplinks habe. Hier k\u00f6nnte man argumentieren, dass der virtuelle Quellport derselbe ist (meine Teaming-Richtlinie), das hei\u00dft, f\u00fcr dasselbe vNIC sollte immer derselbe Uplink ausgew\u00e4hlt werden. Aber da ich auf dem Host bin, ist es kein Problem, einen anderen Uplink zu \u00fcberpr\u00fcfen:<\/p>\n
pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nEs kommen Anfragen vom FortiGate, aber es gibt keine Antwort. Das hei\u00dft, 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\u00fchlt und nicht bereit, mich mit dem Stillstand abzufinden, beschloss ich, weitere Sniff-Daten f\u00fcr den Support zu sammeln, um den Prozess zu beschleunigen. Und da \u201ezuf\u00e4llig\u201c mein Blick auf die Ethernet-Kapselung unterlay f\u00e4llt. Der K\u00f6nig ist nicht echt, und die MAC-Adresse des VTEP stimmt nicht mit seiner IP \u00fcberein. Ich setze alles zur\u00fcck, schn\u00fcffle, grabe \u2014 richtig, dass es nicht richtig ist. Ich werde die ARP-Tabelle daneben anf\u00fchren, um den Vergleich zu erleichtern. Bitte beachten Sie die erste Ethernet-Kapselung im oberen Bild:<\/p>\n
fortigate (root) #get sys arp | grep u.u.u.47\nu.u.u.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep u.u.u.42\nu.u.u.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nAlso, was haben wir am Ende \u2014 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\u00e4\u00df vom empfangenden Schnittstelle des Hypervisors verworfen. Dar\u00fcber hinaus geh\u00f6rte in einem von vier F\u00e4llen diese MAC dem urspr\u00fcnglichen Hypervisor, von dem die Migration der Maschine begann.<\/p>\n
Gestern erhielt ich eine E-Mail vom technischen Support von Fortinet \u2014 in meinem Fall wurde der Bug 615586 er\u00f6ffnet. Ich wei\u00df 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\u00e4chsten. Auch ein weiterer Bug, den ich letzten Monat entdeckt habe, heizt mein Ego an, dieser jedoch im HTML5 GUI vSphere. Ich habe das Gef\u00fchl, dass es wie ein lokales QA-Team bei den Anbietern ist...<\/p>\n
Ich wage zu vermuten, dass Folgendes zutrifft:<\/p>\n
1 \u2014 Es ist sehr wahrscheinlich, dass der Multicast-Control-Plane nicht von dem beschriebenen Problem betroffen sein wird \u2014 denn die MAC-Adressen des VTEP stammen aus der IP-Adresse der Gruppe, auf die die Schnittstelle abonniert ist. <\/p>\n
2 \u2014 h\u00f6chstwahrscheinlich handelt es sich um ein Problem des Fortigate mit dem Offload von Sitzungen auf dem Network Processor (vergleichbar mit CEF) \u2014 wenn jedes Paket durch die CPU geleitet wird, werden die Tabellen verwendet, die die korrekten \u2014 zumindest visuell \u2014 Informationen enthalten. Zu dieser Annahme spricht, dass es hilft, das Interface zu schlie\u00dfen oder zu \u00f6ffnen oder einige Zeit zu warten \u2014 l\u00e4nger als 5 Minuten. <\/p>\n
3 \u2014 eine \u00c4nderung der Teaming-Policy, zum Beispiel auf explicit failover, oder die Implementierung von LAG wird das Problem nicht l\u00f6sen, da ein 'Feststecken' der MAC des urspr\u00fcnglichen Hypervisors in den inkapsulierten Paketen beobachtet wurde.<\/p>\n
In diesem Zusammenhang m\u00f6chte ich teilen, dass ich k\u00fcrzlich entdeckt habe dem Blog<\/a><\/noindex>, wo in einem der Artikel behauptet wurde, dass stateful Firewalls und caching Methoden zur Daten\u00fcbertragung \u2014 ein Strohhalm sind. Nun, ich bin nicht so erfahren in der IT, um so etwas zu behaupten, und au\u00dferdem stimme ich nicht sofort mit allen Aussagen der Blogartikel \u00fcberein. Dennoch sagt mir etwas, dass da ein K\u00f6rnchen Wahrheit in den Worten von Ivan steckt.<\/p>\n
Vielen Dank f\u00fcr Ihre Aufmerksamkeit! Ich freue mich darauf, Fragen zu beantworten und konstruktive Kritik zu h\u00f6ren.
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438. \u042f \u0438\u043d\u043e\u0433\u0434\u0430 \u0437\u0430\u0432\u0438\u0434\u0443\u044e \u043a\u043e\u043b\u043b\u0435\u0433\u0430\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0438\u043c \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u043e \u2014 \u0432\u0435\u0434\u044c \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u043a\u043e\u043d\u0446\u0430 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0451\u043d\u043d\u043e\u0433\u043e \u043a Internet \u043c\u0438\u0440\u0430, \u043a\u0430\u043d\u0438\u043a\u0443\u043b\u044b \u0432 \u043b\u044e\u0431\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u0438 \u0434\u0435\u0434\u043b\u0430\u0439\u043d\u044b, \u0430 \u043d\u0435 \u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u0444\u0438\u0441\u0435 \u0441 8 \u0434\u043e 17. \u041c\u043e\u044f \u043f\u043e\u0437\u0438\u0446\u0438\u044f \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u0438\u0441\u043a\u043b\u044e\u0447\u0430\u044e\u0442 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0434\u043e\u043b\u0433\u043e\u0433\u043e \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u0432 \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u0435. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73232","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47VXLAN in NSX-V \u2013 Troubleshooting des Underlays | ProHoster","description":"Ich begr\u00fc\u00dfe Sie und m\u00f6chte zun\u00e4chst etwas Poetisches sagen. Manchmal beneide ich meine Kollegen, die remote arbeiten \u2013 es ist wirklich wunderbar, die Freiheit zu haben, von \u00fcberall auf der Welt mit Internetverbindung zu arbeiten, Urlaub wann immer man m\u00f6chte, Verantwortung f\u00fcr Projekte und Deadlines zu tragen, anstatt von 8 bis 17 Uhr im B\u00fcro zu sitzen. Meine Position und Aufgaben im Unternehmen schlie\u00dfen nahezu die M\u00f6glichkeit eines l\u00e4ngeren Fehlens im Rechenzentrum aus.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47VXLAN \u0432 NSX-V \u2014 \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043c underlay | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438. \u042f \u0438\u043d\u043e\u0433\u0434\u0430 \u0437\u0430\u0432\u0438\u0434\u0443\u044e \u043a\u043e\u043b\u043b\u0435\u0433\u0430\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0438\u043c \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u043e \u2014 \u0432\u0435\u0434\u044c \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u043a\u043e\u043d\u0446\u0430 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0451\u043d\u043d\u043e\u0433\u043e \u043a Internet \u043c\u0438\u0440\u0430, \u043a\u0430\u043d\u0438\u043a\u0443\u043b\u044b \u0432 \u043b\u044e\u0431\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u0438 \u0434\u0435\u0434\u043b\u0430\u0439\u043d\u044b, \u0430 \u043d\u0435 \u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u0444\u0438\u0441\u0435 \u0441 8 \u0434\u043e 17. \u041c\u043e\u044f \u043f\u043e\u0437\u0438\u0446\u0438\u044f \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u0438\u0441\u043a\u043b\u044e\u0447\u0430\u044e\u0442 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0434\u043e\u043b\u0433\u043e\u0433\u043e \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u0432 \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u0435.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-08T05:42:18+00:00","article:modified_time":"2020-03-08T05:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73232","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:36:23","updated":"2022-09-27 15:26:08"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}