{"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 \u2013 Fehlerbehebung im Underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo und zun\u00e4chst ein wenig Lyrik. Manchmal beneide ich meine Kollegen, die remote arbeiten \u2013 es ist wunderbar, von jedem Ort der Welt, der mit dem Internet verbunden ist, zu arbeiten, Urlaub zu jeder Zeit, Verantwortung f\u00fcr Projekte und Deadlines zu haben, anstatt von 8 bis 17 Uhr im B\u00fcro zu sein. Meine Position und Arbeitsaufgaben schlie\u00dfen praktisch die M\u00f6glichkeit eines langen Fehlens im Rechenzentrum aus. Dennoch gibt es gelegentlich interessante F\u00e4lle, wie den unten beschriebenen \u2013 und ich verstehe, dass es nur wenige Positionen gibt, in denen es so viel Raum f\u00fcr kreative Ausdrucksweise des inneren Troubleshooters gibt.
\n<\/a><\/noindex>
\nEin kleiner Disclaimer \u2014 zum Zeitpunkt des Schreibens des Artikels war der Fall noch nicht vollst\u00e4ndig gel\u00f6st, aber angesichts der Reaktionsgeschwindigkeit der Anbieter kann es noch Monate dauern, bis eine vollst\u00e4ndige L\u00f6sung erarbeitet wird; ich m\u00f6chte aber meine Entdeckungen schon jetzt teilen. Ich hoffe, verehrte Leser, Sie verzeihen mir diese Eile. Aber genug der Vorrede \u2014 was ist mit dem Fall? <\/p>\n

Zun\u00e4chst eine Einleitung: Es gibt eine Firma (in der ich als Netzwerkingenieur arbeite), die 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 m\u00f6chte nicht bewerten, wie viel Zeit mir dieses System geschenkt hat; kurz gesagt \u2014 es ist viel. Ich konnte sogar meinen Kollegen die Einrichtung von NSX ESG beibringen, und kleinere Kundenl\u00f6sungen werden ohne mein Zutun implementiert. Ein wichtiger Hinweis \u2014 der Control Layer bei uns verwendet Unicast-Replikation. Die Hypervisoren sind \u00fcber zwei Schnittstellen redundant an verschiedene physische Juniper QFX5100-Switches (zu einem Virtual Chassis zusammengeschaltet) angeschlossen und die Routing-Politik basiert auf dem urspr\u00fcnglichen virtuellen Port \u2014 zur Vollst\u00e4ndigkeit der Darstellung.<\/p>\n

Die Kundenl\u00f6sungen sind sehr unterschiedlich: von Windows IIS, wo alle Komponenten des Webservers auf einem einzigen Rechner installiert sind, bis hin zu gr\u00f6\u00dferen L\u00f6sungen \u2014 beispielsweise Lastverteilung f\u00fcr Apache-Web-Frontends + LB MariaDB in Galera + Share-Server, die mit GlusterFS synchronisiert werden. Praktisch jeder Server muss einzeln \u00fcberwacht werden, und nicht alle Komponenten haben \u00f6ffentliche Adressen \u2014 falls Sie sich mit dieser Herausforderung auseinandergesetzt haben und elegantere L\u00f6sungen zur Verf\u00fcgung stehen, w\u00fcrde ich mich \u00fcber Ratschl\u00e4ge freuen.
\nMeine \u00dcberwachungsentscheidung besteht darin, die Firewall (Fortigate) an jedes interne Kundennetzwerk anzuschlie\u00dfen (+SNAT und nat\u00fcrlich strenge Einschr\u00e4nkungen hinsichtlich des erlaubten Datenverkehrs) und die internen Adressen zu beobachten \u2013 auf diese Weise wird eine gewisse Vereinheitlichung und Vereinfachung der \u00dcberwachung erreicht. Die \u00dcberwachung erfolgt aus einem Cluster von PRTG-Servern. Das \u00dcberwachungsschema sieht ungef\u00e4hr so aus:<\/p>\n

\"VXLAN
\n
\nSolange wir nur mit VLANs gearbeitet haben, war alles ganz \u00fcblich und vorhersehbar, es funktionierte wie ein Uhrwerk. Nach der Einf\u00fchrung von NSX-V und VXLAN standen wir vor der Frage \u2013 k\u00f6nnen wir die \u00dcberwachung wie gewohnt fortsetzen? Zu dem Zeitpunkt war die \u201eschnellste\u201c L\u00f6sung, NSX ESG zu implementieren und den VXLAN-Trunk-Schnittstellen in das VTEP-Netzwerk anzuschlie\u00dfen. Schnell in Anf\u00fchrungszeichen \u2013 denn die Verwendung der GUI zur Konfiguration der Kundennetzwerke, SNAT und Firewall-Regeln vereinheitlicht zwar die Verwaltung in einer einzigen vSphere-Oberfl\u00e4che, ist meiner Meinung nach jedoch recht umst\u00e4ndlich und schr\u00e4nkt zudem die Werkzeugsammlung f\u00fcr das Troubleshooting ein. Diejenigen, die NSX ESG als Ersatz f\u00fcr eine \u201eechte\u201c Firewall verwendet haben, werden dem vermutlich zustimmen. Obwohl eine solche L\u00f6sung wahrscheinlich stabiler w\u00e4re \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 denke ich, ist alles klar \u2013 es verliert einfach die Vorteile der Anwendung von VXLAN \u2013 denn in diesem Fall muss man das VLAN doch an die Monitoring-Installation anbinden. \u00dcbrigens bin ich bei der Ausarbeitung dieser L\u00f6sung auf ein Problem gesto\u00dfen, bei dem der DLR-Bridge keine Pakete an die virtuelle Maschine sendete, mit der sie 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 separater Cluster bereitgestellt werden muss, aber das steht in den B\u00fcchern... So oder so, nach ein paar Monaten mit dem Support konnten wir das Problem nicht l\u00f6sen. Im Prinzip habe ich die Logik verstanden \u2013 das Hypervisor-Kernel-Modul, das f\u00fcr die Kapselung von VXLAN verantwortlich ist, wurde nicht genutzt, wenn DLR und der \u00fcberwachte Server sich auf demselben Host befanden, da der Verkehr den Host nicht verl\u00e4sst und laut Logik an das VXLAN-Segment angeschlossen sein sollte \u2013 die Kapselung ist nicht notwendig. Mit dem Support haben wir uns auf das virtuelle Interface vdrPort geeinigt, das logisch die Uplinks vereint und auch die Bridging\/Kapselung durchf\u00fchrt \u2013 dort wurde eine Diskrepanz im eingehenden Traffic festgestellt, die ich in diesem Fall weiterverfolgt habe. Aber wie gesagt, ich habe diesen Fall nicht zu Ende gebracht, da ich auf ein anderes Projekt versetzt wurde und der Ast urspr\u00fcnglich eine Sackgasse war und ich nicht wirklich das Bed\u00fcrfnis hatte, ihn weiterzuentwickeln. Wenn ich mich nicht irre, trat das Problem in den Versionen NSX 6.1.4 und 6.2 auf. <\/p>\n

Und hier \u2013 Bingo! Fortinet k\u00fcndigt die native Unterst\u00fctzung f\u00fcr VXLAN<\/a><\/noindex>an. Und es handelt sich nicht nur um Point-to-Point oder VXLAN-over-IPSec, nicht um softwarebasiertes Bridging zwischen VLAN und VXLAN \u2013 all dies wurde bereits seit Version 5.4 implementiert (und bei anderen Anbietern vorgestellt.<\/a><\/noindex>), und eine echte Unterst\u00fctzung des Unicast-Control-Planes. Beim Implementieren der L\u00f6sung stie\u00df ich auf ein weiteres Problem \u2013 die \u00fcberwachten Server \u201everschwanden\u201c zeitweise aus der \u00dcberwachung, obwohl die Virtuelle Maschine selbst aktiv war. Der Grund war, dass ich vergessen hatte, Ping auf dem VXLAN-Interface zu aktivieren. W\u00e4hrend des Rebalancierens der Cluster bewegten sich die virtuellen Maschinen, und der Ping beendete das vMotion, um den neuen ESXi-Host anzuzeigen, auf den die Maschine verschoben wurde. Mein Fehler, aber dieses Problem hat das Vertrauen in den Support des Herstellers \u2013 in diesem Fall Fortinet \u2013 erneut ersch\u00fcttert. Ich will gar nicht erst erw\u00e4hnen, dass jeder Fall, der mit VXLAN zu tun hat, mit der Frage beginnt: \u201eWo in Ihren Einstellungen haben Sie den Softswitch VLAN-VXLAN?\u201c Diesmal wurde mir geraten, das MTU zu \u00e4ndern \u2013 das betrifft Ping, das 32 Byte gro\u00df ist. Dann \u201espiel mal\u201c mit tcp-send-mss und tcp-receive-mss in der Policy \u2013 f\u00fcr VXLAN, das in UDP eingekapselt wird. Puh, Entschuldigung \u2013 es musste mal raus. Jedenfalls habe ich dieses Problem selbst gel\u00f6st. <\/p>\n

Nachdem ich den Testverkehr erfolgreich durchlaufen hatte, wurde beschlossen, diese L\u00f6sung einzuf\u00fchren. Und in der Produktionsumgebung stellte sich heraus, dass nach ein oder zwei Tagen all das, was \u00fcber VXLAN \u00fcberwacht wurde, allm\u00e4hlich ausfiel. Das Deaktivieren\/Aktivieren des Interfaces half, aber nur vor\u00fcbergehend. In Anbetracht der Langsamkeit des Herstellersupports habe ich mit dem Troubleshooting von meiner Seite aus begonnen \u2013 schlie\u00dflich ist meine Firma, mein Netzwerk \u2013 meine Verantwortung. <\/p>\n

Der Fortschritt des Troubleshootings unter Spoiler. Wer von Buchstaben und Prahlerei m\u00fcde ist \u2013 \u00fcberspringt und geht zur Nachanalyse.<\/p>\n

Fortschritt des Troubleshootings<\/b>Danke, dass Sie weiter gelesen haben \u2013 wir machen weiter!<\/p>\n

Also, die \u00dcberwachung funktioniert eine Weile, dann f\u00e4llt sie von selbst aus. Das bedeutet, dass es in der Firewall-Policy wahrscheinlich keine Probleme gibt. Da ich jedoch auf Probleme mit h\u00e4ngenden Systemprozessen in Fortigate-Versionen 5.6+ gesto\u00dfen bin, schauen wir uns zuerst \u201ediagnose debug flow\u201c an \u2013 erwartungsgem\u00e4\u00df wird der Datenverkehr genehmigt und verl\u00e4sst das Interface, und erwartungsgem\u00e4\u00df kommt nichts als Antwort zur\u00fcck. Das bedeutet, wir m\u00fcssen weiter im Stack graben. Leider muss ich die Adressen sogar RFC1918-sichtbar verstecken, 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, das Interface des Fortigates 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 das Overlay sind dies ARP und OVSDB, f\u00fcr das Underlay ARP und CAM. Bei Fortigate ist VXLAN FDB und OVSDB vorhanden. Dort fangen wir an:<\/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 recht einfach \u2013 die MAC-Adresse der virtuellen Maschine muss sich am VTEP mit der Adresse \u0443.\u0443.\u0443.47 befinden. Bei der \u00dcberpr\u00fcfung des Inhalts und der Einstellungen des ESXi-Clusters stelle ich fest, dass die MAC-Adresse der virtuellen Maschine korrekt ist und auch die Adresse des VTEP. Ich \u00fcberpr\u00fcfe die CAM\/ARP-Tabelle auf dem Fortigate \u2013 erneut stimmen die Einstellungen mit dem ESXi-Host \u00fcberein:<\/p>\n
fortigate (root) #get sys arp | grep \u0443.\u0443.\u0443.47\n\u0443.\u0443.\u0443.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nDie Tabellen sind korrekt und der Traffic geht weg \u2013 ist das vielleicht ein Problem, das nicht auf dem Fortigate liegt? Ich habe absichtlich die Analyse des Datenverkehrs auf Juniper \u00fcbersprungen \u2013 logisch betrachtet sollte der n\u00e4chste Schritt des Troubleshootings dort erfolgen, aber mein Netzwerk ist einfach \u2013 insgesamt 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 verschwindendem Traffic \u2013 ich gehe schn\u00fcffeln auf dem ESXi-Host und erstelle nebenbei bereits einen Fall bei VMWare. Unten geh\u00f6rt die MAC \u201e97:6e\u201c zur Fortigate, vmnic1 \u2013 das ist das Interface, das VTEP mit der Adresse u.u.u.47 hat, 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
\nFortschritt \u2013 im Schn\u00fcffelprotokoll sehe ich ARP-Anfragen und die eingehende Antwort. Ich f\u00fchre nur die ARP-Antwort an und dort stimmt alles. Ich habe nicht erw\u00e4hnt, dass der \u00dcberwachungsserver die Adresse \u0445.\u0445.\u0445.15 anpingt \u2013 wo bleibt der ICMP-Traffic? Ich erinnere mich, dass ich zwei Uplinks habe. Hier kann man argumentieren und sagen, dass der virtuelle Ausgangsport der gleiche ist (meine Teaming-Politik), also f\u00fcr dieselbe vNIC derselbe Uplink ausgew\u00e4hlt werden sollte, aber da ich bereits auf dem Host bin, ist es kein Problem, den 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 am Fortigate. Also denke ich: Wieder das gleiche Problem mit dem verschwindenden Verkehr auf dem VDR, wieder ein paar Monate, um den Fall in die richtige Richtung zu lenken. Nach ein paar Tagen, nach einem kurzen Besinnungsprozess und um nicht mit dem Stau zu leben, beschloss ich, weitere Sniffs f\u00fcr den Support zu sammeln, um den Prozess zu beschleunigen. Und hier f\u00e4llt mein Blick \u201ezuf\u00e4llig\u201c auf die Ethernet-Kapselung der Underlay. Der K\u00f6nig ist also nicht echt und die MAC-Adresse des VTEP stimmt nicht mit seiner IP \u00fcberein. Ich setze alles auf null, sniffle, grabe weiter \u2013 recht, was nicht recht ist. Ich werde die ARP-Tabelle daneben bringen, um den Vergleich zu erleichtern. Beachten Sie die erste Ethernet-Kapselung auf dem Bild oben:<\/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
\nWas haben wir also als Ergebnis \u2013 nach der Migration der virtuellen Maschine versucht der Fortigate, den Verkehr an den VTEP aus der (korrekten) VXLAN-FDB zu senden, verwendet aber die falsche DST-MAC und der Verkehr wird erwartungsgem\u00e4\u00df vom empfangenden Interface des Hypervisors verworfen. In einem von vier F\u00e4llen geh\u00f6rte diese MAC zum urspr\u00fcnglichen Hypervisor, von dem die Migration der Maschine begann.<\/p>\n
Gestern erhielt ich eine Nachricht vom Fortinet-Support \u2013 zu meinem Fall wurde ein Bug 615586 er\u00f6ffnet. Ich wei\u00df nicht, ob ich mich freuen oder trauern soll: Einerseits liegt das Problem nicht an den Einstellungen, andererseits kommt der Fix nur mit einem Firmware-Update, bestenfalls im n\u00e4chsten. Mein Ego wird auch von einem weiteren Bug angeheizt, den ich letzten Monat entdeckt habe, allerdings diesmal im HTML5 GUI vSphere. Da haben wir eine lokale QA-Abteilung der Anbieter\u2026<\/p>\n
Ich wage folgende Vermutung:<\/p>\n
1 \u2013 Der Multicast-Control-Plane wird wahrscheinlich nicht von dem beschriebenen Problem betroffen sein \u2013 denn die MAC-Adressen des VTEP werden aus der IP-Adresse der Gruppe gewonnen, auf die das Interface abonniert ist. <\/p>\n
2 \u2013 Wahrscheinlich liegt das Problem beim Fortigate im Offloading von Sessions auf dem Network Processor (\u00e4hnlich wie CEF) \u2013 wenn man jedes Paket durch die CPU leitet, werden die Tabellen verwendet, die die korrekten \u2013 zumindest visuell \u2013 Informationen enthalten. Dies st\u00fctzt die Vermutung, dass es hilft, das Interface zu schlie\u00dfen\/zu \u00f6ffnen oder eine gewisse Zeit abzuwarten \u2013 l\u00e4nger als 5 Minuten. <\/p>\n
3 \u2013 Eine \u00c4nderung der Teaming-Policy, zum Beispiel auf explizites Failover, oder die Einf\u00fchrung von LAG wird das Problem nicht l\u00f6sen, da das \u201eSteckenbleiben\u201c der MAC des urspr\u00fcnglichen Hypervisors in den gekapselten Paketen beobachtet wurde.<\/p>\n
In diesem Licht kann ich teilen, dass ich k\u00fcrzlich Blog<\/a><\/noindex>, wo in einem der Artikel behauptet wurde, dass Stateful-Firewalls und cachef\u00e4hige Methoden zur Daten\u00fcbertragung eine Kr\u00fccke sind. Nun, ich bin nicht so erfahren in IT, um so etwas zu behaupten, au\u00dferdem stimme ich nicht sofort mit allen Aussagen der Blogartikel \u00fcberein. Doch etwas sagt mir, dass ein K\u00f6rnchen Wahrheit in Ivans Worten steckt.<\/p>\n
Danke 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 Unterlage | ProHoster","description":"Ich begr\u00fc\u00dfe Sie und zun\u00e4chst ein wenig Lyrik.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}