{"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\/fr\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN dans NSX-V \u2014 d\u00e9pannage de l'underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour, tout d'abord un peu de lyrisme. Parfois, j'envie mes coll\u00e8gues qui travaillent \u00e0 distance - c'est merveilleux d'avoir la possibilit\u00e9 de travailler de n'importe quel endroit du monde connect\u00e9 \u00e0 Internet, de prendre des cong\u00e9s \u00e0 tout moment, d'avoir la responsabilit\u00e9 des projets et des d\u00e9lais, plut\u00f4t que d'\u00eatre coinc\u00e9 dans un bureau de 8 \u00e0 17 heures. Mon poste et mes responsabilit\u00e9s professionnelles excluent pratiquement la possibilit\u00e9 de rester longtemps en dehors du datacenter. Cependant, il arrive parfois des cas int\u00e9ressants, comme celui d\u00e9crit ci-dessous - et je r\u00e9alise qu'il existe peu de postes o\u00f9 il y a autant de place pour l'expression cr\u00e9ative de l'int\u00e9rieur d'un d\u00e9panneur.
\n<\/a><\/noindex>
\nUn petit avertissement \u2014 au moment de la r\u00e9daction de cet article, le cas n'est pas compl\u00e8tement r\u00e9solu, mais compte tenu de la rapidit\u00e9 de r\u00e9ponse des fournisseurs, une solution compl\u00e8te pourrait prendre encore des mois, et j'aimerais d\u00e9j\u00e0 partager mes d\u00e9couvertes. J'esp\u00e8re, chers lecteurs, que vous me pardonnerez cette h\u00e2te. Mais assez de blabla \u2014 que se passe-t-il avec le cas ? <\/p>\n

Tout d'abord, un peu de contexte : il y a une entreprise (o\u00f9 je travaille comme ing\u00e9nieur r\u00e9seau) qui h\u00e9berge des solutions clients dans un cloud priv\u00e9 VMWare. La plupart des nouvelles solutions sont connect\u00e9es \u00e0 des segments VXLAN, g\u00e9r\u00e9s par NSX-V \u2014 je ne vais pas \u00e9valuer combien de temps cette solution m'a fait gagner, pour faire court \u2014 beaucoup. J'ai m\u00eame r\u00e9ussi \u00e0 former des coll\u00e8gues \u00e0 la configuration de NSX ESG, et de petites solutions clients sont d\u00e9ploy\u00e9es sans ma participation. Remarque importante \u2014 notre plan de contr\u00f4le utilise la r\u00e9plication unicast. Les hyperviseurs sont connect\u00e9s de mani\u00e8re redondante via deux interfaces \u00e0 diff\u00e9rents commutateurs physiques Juniper QFX5100 (assembl\u00e9s en Ch\u00e2ssis Virtuel) et avec une politique de synchronisation bas\u00e9e sur le port virtuel d'origine \u2014 c'est pour compl\u00e9ter le tableau.<\/p>\n

Les solutions clients sont tr\u00e8s vari\u00e9es : allant de Windows IIS, o\u00f9 tous les composants du serveur web sont install\u00e9s sur une seule machine, \u00e0 des configurations plus importantes \u2014 par exemple, des fronts web Apache \u00e9quilibr\u00e9s par charge + LB MariaDB en Galera + serveurs de fichiers synchronis\u00e9s \u00e0 l'aide de GlusterFS. Pratiquement chaque serveur doit \u00eatre surveill\u00e9 s\u00e9par\u00e9ment, et tous les composants n'ont pas d'adresses publiques \u2014 si vous avez d\u00e9j\u00e0 \u00e9t\u00e9 confront\u00e9 \u00e0 cette t\u00e2che et disposez d'une solution plus \u00e9l\u00e9gante, je serais ravi de recevoir vos conseils.
\nMa solution de surveillance consiste \u00e0 \"connecter\" un pare-feu (Fortigate) \u00e0 chaque r\u00e9seau client interne (+SNAT et, bien s\u00fbr, des restrictions strictes sur le type de trafic autoris\u00e9) et \u00e0 surveiller les adresses internes. Cela permet d'atteindre une certaine uniformit\u00e9 et de simplifier la surveillance. La surveillance elle-m\u00eame se fait \u00e0 partir d'un cluster de serveurs PRTG. Le sch\u00e9ma de surveillance est \u00e0 peu pr\u00e8s le suivant :<\/p>\n

\"VXLAN
\n
\nTant que nous ne travaillions qu'avec des VLAN, tout fonctionnait de mani\u00e8re assez ordinaire et pr\u00e9visible, comme une horloge. Apr\u00e8s la mise en \u0153uvre de NSX-V et VXLAN, nous avons \u00e9t\u00e9 confront\u00e9s \u00e0 la question : peut-on continuer \u00e0 surveiller de l'ancienne mani\u00e8re ? \u00c0 ce moment-l\u00e0, la solution la plus \"rapide\" \u00e9tait de d\u00e9ployer NSX ESG et de connecter l'interface trunk VXLAN au r\u00e9seau VTEP. Rapide entre guillemets, car utiliser l'interface graphique pour configurer les r\u00e9seaux clients, SNAT et les r\u00e8gles du pare-feu peut unifier la gestion dans une seule interface vSphere, mais \u00e0 mon avis, cela reste assez lourd et, en plus, cela limite les outils disponibles pour le d\u00e9pannage. Ceux qui ont utilis\u00e9 NSX ESG comme remplacement d'un v\u00e9ritable pare-feu seront d'accord, je suppose. Bien que, probablement, une telle solution serait plus stable, car tout se d\u00e9roule au sein d'un m\u00eame fournisseur.<\/p>\n

Une autre solution consiste \u00e0 utiliser NSX DLR en mode bridge entre VLAN et VXLAN. Ici, je pense que tout est clair : l'avantage d'utiliser VXLAN est perdu, car dans ce cas, il faut toujours tirer le VLAN vers l'installation de surveillance. D'ailleurs, en travaillant sur cette solution, j'ai rencontr\u00e9 un probl\u00e8me o\u00f9 le bridge DLR n'envoyait pas de paquets \u00e0 la VM avec laquelle il se trouvait sur le m\u00eame h\u00f4te. Je sais, je sais \u2014 dans les livres et les guides sur NSX-V, il est clairement dit qu'un cluster distinct doit \u00eatre d\u00e9di\u00e9 \u00e0 NSX Edge, mais cela reste dans les livres\u2026 Quoi qu'il en soit, apr\u00e8s quelques mois avec le support, nous n'avons pas r\u00e9solu le probl\u00e8me. En gros, j'ai compris la logique : le module du noyau de l'hyperviseur responsable de l'encapsulation VXLAN n'\u00e9tait pas utilis\u00e9, car le DLR et le serveur observ\u00e9 se trouvaient sur le m\u00eame h\u00f4te, le trafic ne quittant pas l'h\u00f4te et logiquement devant \u00eatre reli\u00e9 au segment VXLAN \u2014 l'encapsulation n'\u00e9tait pas n\u00e9cessaire. Avec le support, nous nous sommes arr\u00eat\u00e9s sur l'interface virtuelle vdrPort, qui unit logiquement les uplinks et assure le bridging\/l'encapsulation \u2014 c'est l\u00e0 que nous avons constat\u00e9 une incoh\u00e9rence dans le trafic entrant, que j'ai pris en charge pour le cas actuel. Mais comme il a \u00e9t\u00e9 dit, je n'ai pas pouss\u00e9 ce cas jusqu'au bout, car j'ai \u00e9t\u00e9 transf\u00e9r\u00e9 sur un autre projet et de plus, la branche \u00e9tait initialement sans issue et je n'avais pas vraiment l'envie de la d\u00e9velopper. Si je ne me trompe pas, le probl\u00e8me \u00e9tait observ\u00e9 dans les versions NSX 6.1.4 et 6.2. <\/p>\n

Et l\u00e0 \u2014 bingo ! Fortinet annonce le support natif de VXLAN<\/a><\/noindex>. Et pas seulement du point \u00e0 point ou du VXLAN-over-IPSec, pas de bridging logiciel VLAN-VXLAN \u2014 tout cela a commenc\u00e9 \u00e0 \u00eatre mis en \u0153uvre depuis la version 5.4 (et pr\u00e9sent\u00e9 par d'autres fournisseurs<\/a><\/noindex>), et un v\u00e9ritable support du plan de contr\u00f4le unicast. Lors de la mise en \u0153uvre de la solution, je me suis heurt\u00e9 \u00e0 un autre probl\u00e8me - les serveurs contr\u00f4l\u00e9s disparaissaient parfois de la surveillance, bien que la machine virtuelle soit vivante. La raison, comme il s'est av\u00e9r\u00e9, \u00e9tait que j'avais oubli\u00e9 de permettre le Ping sur l'interface VXLAN. Dans le processus de rebalancement des clusters, les machines virtuelles \u00e9taient d\u00e9plac\u00e9es, et le vMotion se terminait par un Ping pour signaler le nouvel h\u00f4te ESXI sur lequel la machine avait \u00e9t\u00e9 d\u00e9plac\u00e9e. C'\u00e9tait une erreur de ma part, mais ce probl\u00e8me a de nouveau sap\u00e9 ma confiance dans le support du fabricant - en l'occurrence Fortinet. Je ne parle m\u00eame pas du fait que chaque cas li\u00e9 \u00e0 VXLAN commence par la question \"o\u00f9 se trouve votre param\u00e8tre softswitch VLAN-VXLAN ?\" Cette fois, on m'a conseill\u00e9 de modifier le MTU - c'est pour le Ping, qui fait 32 octets. Ensuite, \"joue\" avec tcp-send-mss et tcp-receive-mss dans la politique - pour VXLAN, qui est encapsul\u00e9 dans UDP. Ouf, d\u00e9sol\u00e9 - j'avais besoin de le dire. En gros, j'ai r\u00e9solu ce probl\u00e8me par mes propres moyens. <\/p>\n

Apr\u00e8s avoir test\u00e9 le trafic avec succ\u00e8s, il a \u00e9t\u00e9 d\u00e9cid\u00e9 de mettre en \u0153uvre cette solution. Et en production, il s'est av\u00e9r\u00e9 qu'apr\u00e8s un jour ou deux, tout ce qui \u00e9tait surveill\u00e9 via VXLAN commen\u00e7ait progressivement \u00e0 tomber en panne. La d\u00e9sactivation\/r\u00e9activation de l'interface aidait, mais seulement pour un temps. Souvenant de la lenteur du support du fabricant, je me suis attel\u00e9 au d\u00e9pannage de mon c\u00f4t\u00e9 - apr\u00e8s tout, ma soci\u00e9t\u00e9, mon r\u00e9seau - ma responsabilit\u00e9. <\/p>\n

Sous spoiler le d\u00e9roulement du d\u00e9pannage. Ceux qui sont fatigu\u00e9s des lettres et des vantardises - passez et allez \u00e0 l'analyse post\u00e9rieure.<\/p>\n

D\u00e9roulement du d\u00e9pannage<\/b>Merci d'avoir continu\u00e9 la lecture - continuons !<\/p>\n

Donc, la surveillance fonctionne un certain temps, puis se d\u00e9connecte d'elle-m\u00eame. Cela signifie qu'il n'y a probablement pas de probl\u00e8mes dans les politiques du pare-feu. Cependant, comme j'ai rencontr\u00e9 des probl\u00e8mes de processus syst\u00e8me suspendus dans Fortigate versions 5.6+, commen\u00e7ons par regarder \u00ab diagnose debug flow \u00bb - comme pr\u00e9vu, le trafic est autoris\u00e9 et s'en va de l'interface avec aucune r\u00e9ponse attendue. Cela signifie que nous approfondissons la pile. Je vais malheureusement devoir masquer les adresses m\u00eame si elles sont RFC1918, mais j'esp\u00e8re fournir un descriptif suffisant pour la compr\u00e9hension. Le serveur \u00e0 l'int\u00e9rieur du VXLAN a l'adresse x.x.x.15, l'interface de Fortigate x.x.x.254, toutes les autres adresses appartiennent au r\u00e9seau VTEP.<\/p>\n

Pour le transfert r\u00e9ussi des paquets VXLAN encapsul\u00e9s, il est n\u00e9cessaire d'avoir des informations correctes dans plusieurs tables. Pour l'overlay, ce sont ARP et OVSDB, pour l'underlay, ce sont ARP et CAM. Dans le cas de Fortigate, VXLAN FDB est OVSDB. Commen\u00e7ons l\u00e0.<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=x.x.x.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nIci, c'est assez simple \u2014 l'adresse MAC de la machine virtuelle doit \u00eatre pr\u00e9sente sur le VTEP avec l'adresse x.x.x.47. En examinant le contenu et les param\u00e8tres du cluster ESXI, je constate que l'adresse MAC de la machine virtuelle est correcte, tout comme l'adresse VTEP. Je v\u00e9rifie la table CAM\/ARP sur le Fortigate \u2014 tout correspond \u00e0 la configuration de l'h\u00f4te ESXI :<\/p>\n
fortigate (root) #get sys arp | grep x.x.x.47\nx.x.x.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nLes tables sont correctes et le trafic s'\u00e9chappe - peut-\u00eatre que le probl\u00e8me ne vient pas de Fortigate ? J'ai intentionnellement omis l'analyse de la commutation de trafic sur Juniper - logiquement, il faudrait effectuer la prochaine \u00e9tape de d\u00e9pannage l\u00e0-bas, mais mon r\u00e9seau est simple - il n'y a qu'un VLAN pour le VTEP et tous les composants sont connect\u00e9s directement. De plus, je me souviens d'un cas avec le pont DLR, VDR et un trafic disparu - je vais sniffer sur l'h\u00f4te ESXI, tout en cr\u00e9ant un dossier avec VMware. Ci-dessous, l'adresse MAC \"97:6e\" appartient \u00e0 Fortinet, vmnic1 - c'est l'interface qui a le VTEP avec l'adresse u.u.u.47, sniffons dans les deux directions \"\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
\nProgr\u00e8s \u2014 dans le sniffer, je vois une requ\u00eate ARP et la r\u00e9ponse qui arrive. Je ne mentionne que la r\u00e9ponse ARP et tout est correct. Je n'ai pas mentionn\u00e9, mais pendant tout ce temps, le serveur de surveillance ping x.x.x.15 \u2014 o\u00f9 est le trafic ICMP ? Je me souviens que j'ai deux uplinks. On pourrait d\u00e9battre et dire que le port virtuel source est le m\u00eame (ma politique de teaming), c'est-\u00e0-dire qu'un m\u00eame uplink doit \u00eatre s\u00e9lectionn\u00e9 pour la m\u00eame vNIC, mais comme je suis sur l'h\u00f4te, v\u00e9rifier un autre uplink ne pose pas de probl\u00e8me :<\/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
\nDes requ\u00eates provenant de Fortigate arrivent, mais il n'y a pas de r\u00e9ponse. Donc, le probl\u00e8me ne vient pas de Fortigate. Eh bien, je pense \u00e0 nouveau \u00e0 ce m\u00eame probl\u00e8me de trafic qui dispara\u00eet sur le VDR, encore quelques mois \u00e0 diriger le cas dans la bonne direction. Apr\u00e8s quelques jours de r\u00e9flexion et ne souhaitant pas rester coinc\u00e9, j'ai d\u00e9cid\u00e9 de r\u00e9cup\u00e9rer d'autres sniffers pour le support afin d'acc\u00e9l\u00e9rer le processus. Et l\u00e0, mon regard \u00ab tombe par hasard \u00bb sur l'encapsulation Ethernet sous-jacente. Le roi n'est pas vrai et l'adresse MAC VTEP ne correspond pas \u00e0 son IP. Je remets \u00e0 z\u00e9ro, je sniffe, je creuse - c'est vrai que ce n'est pas vrai. Je vais fournir la table ARP \u00e0 c\u00f4t\u00e9 pour facilit\u00e9 la comparaison. Faites attention \u00e0 la premi\u00e8re encapsulation Ethernet sur l'image ci-dessus :<\/p>\n
fortigate (root) #get sys arp | grep x.x.x.47\nx.x.x.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep x.x.x.42\nx.x.x.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nAlors, que nous avons au final - apr\u00e8s la migration de la machine virtuelle, Fortigate essaie d'envoyer du trafic sur VTEP \u00e0 partir de (correctement) VXLAN FDB, mais utilise une mauvaise MAC DST et le trafic est donc rejet\u00e9 par l'interface de l'hyperviseur qui le re\u00e7oit. En un cas sur quatre, cette MAC appartenait \u00e0 l'hyperviseur d'origine, \u00e0 partir duquel nous avons commenc\u00e9 la migration de la machine.<\/p>\n
Hier, j'ai re\u00e7u un e-mail du support technique de Fortinet - un bug 615586 a \u00e9t\u00e9 ouvert sur mon cas. Je ne sais pas vraiment si je dois me r\u00e9jouir ou me lamenter : d'un c\u00f4t\u00e9, le probl\u00e8me ne vient pas des param\u00e8tres, de l'autre, le correctif viendra seulement avec la mise \u00e0 jour du firmware, au mieux lors de la prochaine. Mon \u00e9go est \u00e9galement aliment\u00e9 par un autre bug que j'ai d\u00e9couvert le mois dernier, bien que cette fois-ci dans l'interface HTML5 de vSphere. C'est comme un d\u00e9partement local QA des fournisseurs...<\/p>\n
Je vais tenter de faire l'hypoth\u00e8se suivante :<\/p>\n
1 \u2014 le plan de contr\u00f4le multicast ne sera probablement pas sujet au probl\u00e8me d\u00e9crit \u2014 en effet, les adresses MAC VTEP sont obtenues \u00e0 partir de l'adresse IP du groupe, auquel l'interface est abonn\u00e9e. <\/p>\n
2 \u2014 il est probable que le probl\u00e8me de Fortigate vienne du d\u00e9chargement des sessions sur le processeur r\u00e9seau (en gros, similaire \u00e0 CEF) \u2014 si chaque paquet passe par le CPU, des tables contenant les bonnes informations \u2014 du moins visuellement \u2014 seront utilis\u00e9es. Cela est soutenu par le fait que fermer \/ ouvrir l'interface ou attendre un certain temps \u2014 plus de 5 minutes \u2014 aide. <\/p>\n
3 \u2014 changer la politique de teaming, par exemple en explicit failover, ou mettre en \u0153uvre LAG ne r\u00e9soudra pas le probl\u00e8me, car il a \u00e9t\u00e9 observ\u00e9 que l'adresse MAC de l'hyperviseur d'origine se \u00ab fige \u00bb dans les paquets encapsul\u00e9s.<\/p>\n
\u00c0 la lumi\u00e8re de cela, je peux partager que j'ai r\u00e9cemment d\u00e9couvert blog<\/a><\/noindex>, o\u00f9 l'un des articles pr\u00e9tendait que les pare-feux stateful et les m\u00e9thodes de transmission de donn\u00e9es mises en cache ne sont que des solutions de contournement. Eh bien, je ne suis pas assez exp\u00e9riment\u00e9 en IT pour affirmer cela, et de plus, je ne suis pas d'accord avec toutes les affirmations des articles de blog. Cependant, quelque chose me dit qu'il y a une part de v\u00e9rit\u00e9 dans les propos d'Ivan.<\/p>\n
Merci pour votre attention ! Je serai ravi de r\u00e9pondre \u00e0 vos questions et d'entendre des critiques constructives.
\n
Source : 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 dans NSX-V \u2014 d\u00e9pannons l'underlay | ProHoster","description":"Bonjour, et tout d'abord un peu de lyrisme.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}