{"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\/ro\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN \u00een NSX-V \u2014 depan\u0103m underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bun\u0103, \u0219i mai \u00eent\u00e2i un pic de lir\u0103. Uneori invidiez colegii care lucreaz\u0103 de la distan\u021b\u0103 - e minunat s\u0103 ai posibilitatea de a lucra din orice col\u021b al lumii conectate la Internet, s\u0103 ai vacan\u021be oric\u00e2nd, responsabilitate pentru proiecte \u0219i termene limit\u0103, nu s\u0103 stai \u00een birou de la 8 la 17. Pozi\u021bia mea \u0219i responsabilit\u0103\u021bile mele de munc\u0103 practic exclud posibilitatea de a lipsi mult din data center. Totu\u0219i, ocazional apar cazuri interesante precum cel descris mai jos - \u0219i \u00eemi dau seama c\u0103 exist\u0103 pu\u021bine pozi\u021bii \u00een care exist\u0103 un asemenea spa\u021biu pentru exprimarea creativ\u0103 a unui troubleshooter interior.
\n<\/a><\/noindex>
\nO mic\u0103 precizare - \u00een momentul scrierii acestui articol, cazul nu este complet rezolvat, dar av\u00e2nd \u00een vedere viteza de r\u0103spuns a furnizorilor, solu\u021bia complet\u0103 poate dura \u00eenc\u0103 luni, iar eu vreau s\u0103 \u00eemp\u0103rt\u0103\u0219esc descoperirile mele deja acum. Sper, dragi cititori, c\u0103 \u00eemi ve\u021bi ierta aceast\u0103 grab\u0103. Dar destul cu introducerile - ce se \u00eent\u00e2mpl\u0103 cu cazul? <\/p>\n

Mai \u00eent\u00e2i, o introducere: exist\u0103 o firm\u0103 (unde lucrez ca inginer de re\u021bea), care g\u0103zduie\u0219te solu\u021bii pentru clien\u021bi \u00een cloud-ul privat VMWare. Cele mai multe solu\u021bii noi sunt conectate la segmentele VXLAN, care sunt gestionate de NSX-V - nu voi evalua c\u00e2t timp mi-a oferit aceast\u0103 solu\u021bie, pe scurt - mult. Am reu\u0219it chiar s\u0103 \u00eei \u00eenv\u0103\u021b pe colegi s\u0103 configureze NSX ESG, iar solu\u021biile mici pentru clien\u021bi sunt desf\u0103\u0219urate f\u0103r\u0103 interven\u021bia mea. O men\u021biune important\u0103 - control plane-ul nostru folose\u0219te replicare unicast. Hypervizorii sunt conecta\u021bi redundant prin dou\u0103 interfe\u021be la diferite comutatoare fizice Juniper QFX5100 (asambleaz\u0103 \u00een Virtual Chassis) \u0219i politica de temporizare a rutelor se bazeaz\u0103 pe portul virtual de origine - aceasta pentru a completa imaginea.<\/p>\n

Solu\u021biile pentru clien\u021bi sunt foarte variate: de la Windows IIS, unde toate componentele serverului web sunt instalate pe o singur\u0103 ma\u0219in\u0103, p\u00e2n\u0103 la solu\u021bii destul de mari - de exemplu, fronturi web Apache load-balanced + LB MariaDB \u00een Galera + servere de partajare, sincronizate cu GlusterFS. Practic, fiecare server trebuie monitorizat separat, iar adresele publice nu sunt disponibile pentru toate componentele - dac\u0103 a\u021bi \u00eent\u00e2lnit aceast\u0103 problem\u0103 \u0219i ave\u021bi o solu\u021bie mai elegant\u0103, a\u0219 fi recunosc\u0103tor pentru sfaturi.
\nSolu\u021bia mea de monitorizare const\u0103 \u00een \u201econectarea\u201d unui firewall (Fortigate) la fiecare re\u021bea intern\u0103 de client (+SNAT \u0219i, desigur, restric\u021bii stricte privind tipurile de trafic permise) \u0219i monitorizarea adreselor interne \u2014 astfel se realizeaz\u0103 o anumit\u0103 unificare \u0219i simplificare a monitoriz\u0103rii. Monitorizarea se efectueaz\u0103 dintr-un cluster de servere PRTG. Schema de monitorizare este aproximativ a\u0219a:<\/p>\n

\"VXLAN
\n
\nP\u00e2n\u0103 c\u00e2nd am operat doar cu VLAN, totul era destul de obi\u0219nuit \u0219i func\u021biona ca un ceas. Dup\u0103 implementarea NSX-V \u0219i VXLAN, am \u00eent\u00e2mpinat pregunta \u2014 putem continua monitorizarea a\u0219a cum am f\u0103cut p\u00e2n\u0103 acum? La momentul acestei \u00eentreb\u0103ri, cea mai \u201erapid\u0103\u201d solu\u021bie era s\u0103 desf\u0103\u0219ur\u0103m NSX ESG \u0219i s\u0103 conect\u0103m interfa\u021ba trunk VXLAN \u00een re\u021beaua VTEP. Rapid \u00een ghilimele \u2014 deoarece utilizarea GUI pentru configurarea re\u021belelor clientului, SNAT \u0219i regulile firewall-ului poate unifica managementul \u00eentr-un singur interfa\u021b\u0103 vSphere, dar, \u00een opinia mea, este destul de greoaie \u0219i, printre altele, limiteaz\u0103 setul de instrumente pentru depanare. Cei care au folosit NSX ESG ca \u00eenlocuire pentru un firewall \u201ereal\u201d cred c\u0103 vor fi de acord. De\u0219i, probabil, o astfel de solu\u021bie ar fi mai stabil\u0103 \u2014 av\u00e2nd \u00een vedere c\u0103 totul se desf\u0103\u0219oar\u0103 \u00een cadrul unui singur furnizor.<\/p>\n

O alt\u0103 solu\u021bie este utilizarea NSX DLR \u00een modul de bridge \u00eentre VLAN \u0219i VXLAN. Aici cred c\u0103 este clar \u2014 pur \u0219i simplu se pierde beneficiul utiliz\u0103rii VXLAN \u2014 deoarece \u00een acest caz trebuie s\u0103 aducem VLAN la instala\u021bia de monitorizare. Apropo, \u00een procesul de implementare a acestei solu\u021bii m-am confruntat cu problema \u00een care DLR-bridge nu trimitea pachete c\u0103tre ma\u0219ina virtual\u0103 cu care se afla pe acela\u0219i host. \u0218tiu, \u0219tiu \u2014 \u00een c\u0103r\u021bile \u0219i ghidurile despre NSX-V se spune clar c\u0103 pentru NSX Edge ar trebui s\u0103 fie alocat un cluster separat, dar asta este \u00een c\u0103r\u021bi... A\u0219a sau altfel, dup\u0103 c\u00e2teva luni de suport tehnic, problema nu a fost rezolvat\u0103. \u00cen principiu, am \u00een\u021beles logica de func\u021bionare \u2014 modulul nucleului hipervizorului, responsabil pentru \u00eencapsularea VXLAN, nu era activat dac\u0103 DLR \u0219i serverul observat se aflau pe acela\u0219i host, deoarece traficul nu p\u0103r\u0103se\u0219te hostul \u0219i, conform logicii, ar trebui s\u0103 fie conectat la segmentul VXLAN \u2014 \u00eencapsularea nu este necesar\u0103. Cu suportul tehnic, ne-am oprit la interfa\u021ba virtual\u0103 vdrPort, care une\u0219te logic uplink-urile \u0219i care realizeaz\u0103 bridging\/\u00eencapsulare \u2014 acolo a fost observat\u0103 o nepotrivire \u00een traficul de intrare, pe care am luat-o pentru a o analiza \u00een acest caz. Dar, a\u0219a cum am spus, nu am dus acest caz p\u00e2n\u0103 la cap\u0103t, deoarece am fost trasferit la un alt proiect, iar ramura era de la bun \u00eenceput f\u0103r\u0103 ie\u0219ire \u0219i nu aveam de g\u00e2nd s\u0103 o dezvolt foarte mult. Dac\u0103 nu m\u0103 \u00een\u0219el, problema a fost observat\u0103 \u00een versiunile NSX 6.1.4 \u0219i 6.2. <\/p>\n

\u0218i aici \u2014 bingo! Fortinet anun\u021b\u0103 suport nativ pentru VXLAN<\/a><\/noindex>. \u0218i nu doar point-to-point sau VXLAN-over-IPSec, nu bridging-ul software VLAN-VXLAN \u2014 toate acestea au \u00eenceput s\u0103 fie implementate \u00eenc\u0103 din versiunea 5.4 (\u0219i sunt disponibile la altele v\u00e2nz\u0103tori<\/a><\/noindex>), \u0219i un suport real pentru unicast control plane. C\u00e2nd am implementat solu\u021bia, m-am confruntat cu \u00eenc\u0103 o problem\u0103 - serverele verificate disp\u0103reau \u0219i reapareau periodic \u00een monitorizare, de\u0219i ma\u0219ina virtual\u0103 era activ\u0103. Cauza, cum s-a dovedit, era c\u0103 am uitat s\u0103 permit Ping pe interfa\u021ba VXLAN. \u00cen procesul de reechilibrare a clusterelor, ma\u0219inile virtuale se mutau, iar finalizarea vMotion era marcat\u0103 prin Ping, pentru a indica noul host ESXI pe care a fost mutat\u0103 ma\u0219ina. E o prostie de-a mea, dar aceast\u0103 problem\u0103 a zdruncinat din nou \u00eencrederea \u00een suportul furnizorului - \u00een acest caz, Fortinet. Nici m\u0103car nu mai vorbesc despre faptul c\u0103 fiecare caz legat de VXLAN \u00eencepe cu \u00eentrebarea \u201edar unde ave\u021bi \u00een set\u0103rile softswitch VLAN-VXLAN?\u201d De data aceasta mi s-a recomandat s\u0103 schimb MTU - aceasta pentru Ping, care are 32 de bytes. Apoi s\u0103 \u201em\u0103 joc\u201d cu tcp-send-mss \u0219i tcp-receive-mss \u00een politic\u0103 - pentru VXLAN, care este encapsulat \u00een UDP. Uf, \u00eemi pare r\u0103u - am avut sup\u0103rarea pe inim\u0103. \u00cen general, am rezolvat aceast\u0103 problem\u0103 pe cont propriu. <\/p>\n

Dup\u0103 ce am testat traficul, s-a decis implementarea acestei solu\u021bii. \u0218i \u00een produc\u021bie s-a dovedit c\u0103, dup\u0103 o zi sau dou\u0103, tot ce era monitorizat prin VXLAN \u00eencepea s\u0103 se deconecteze treptat. Dezactivarea\/activarea interfe\u021bei ajuta, dar doar temporar. \u021ain\u00e2nd cont de lentoarea suportului produc\u0103torului, m-am apucat de troubleshooting din partea mea \u2014 la urma urmei, compania mea, re\u021beaua mea \u2014 responsabilitatea mea. <\/p>\n

Sub spoilerul acesta se afl\u0103 procesul de troubleshooting. Cine s-a s\u0103turat de cuvinte \u0219i laude \u2014 poate s\u0103 sar\u0103 \u0219i s\u0103 treac\u0103 la post-analis\u0103.<\/p>\n

Procesul de troubleshooting<\/b>Mul\u021bumesc c\u0103 a\u021bi continuat s\u0103 citi\u021bi \u2014 s\u0103 continu\u0103m!<\/p>\n

A\u0219adar, monitorizarea func\u021bioneaz\u0103 o vreme, apoi se deconecteaz\u0103 singur\u0103. Asta \u00eenseamn\u0103 c\u0103, cel mai probabil, nu sunt probleme \u00een politicile de firewall. Totu\u0219i, deoarece m-am confruntat cu problema proceselor de sistem blocate \u00een Fortigate versiunilor 5.6+, \u00eencepem cu \u201ediagnose debug flow\u201d \u2014 a\u0219a cum era de a\u0219teptat, traficul se permite \u0219i iese pe interfa\u021b\u0103, iar a\u0219a cum era de a\u0219teptat, nu vine nimic \u00eenapoi. Asta \u00eenseamn\u0103 c\u0103 trebuie s\u0103 c\u0103ut\u0103m mai departe \u00een stiv\u0103. Va trebui, din p\u0103cate, s\u0103 ascund adresele, chiar dac\u0103 sunt RFC1918, dar sper c\u0103 voi asigura procesul cu o descriere suficient\u0103 pentru \u00een\u021belegere. Serverul din interiorul VXLAN are adresa x.x.x.15, interfa\u021ba fortigate x.x.x.254, toate celelalte adrese apar\u021bin re\u021belei VTEP.<\/p>\n

Pentru un transfer de pachete VXLAN \u00eenf\u0103\u0219urate cu succes, este necesar\u0103 informa\u021bia corect\u0103 \u00een mai multe tabele. Pentru overlay, acestea sunt ARP \u0219i OVSDB, iar pentru underlay, ARP \u0219i CAM. \u00cen cazul Fortigate, VXLAN FDB \u0219i OVSDB sunt acelea\u0219i. S\u0103 \u00eencepem de acolo:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=u.u.u.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nAici totul este destul de simplu \u2013 adresa MAC a ma\u0219inii virtuale trebuie s\u0103 se afle pe VTEP cu adresa u.u.u.47. Verific\u00e2nd con\u021binutul \u0219i configura\u021bia clusterului ESXI, constat c\u0103 adresa MAC a ma\u0219inii virtuale este corect\u0103, adresa VTEP de asemenea. Verific ARP\/CAM tabela de pe Fortigate \u2013 din nou, totul se potrive\u0219te cu set\u0103rile gazdei ESXI:<\/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
\nTabelele sunt corecte \u0219i traficul pleac\u0103 - poate problema nu este la Fortigate? Am omis inten\u021bionat analiza comut\u0103rii traficului pe Juniper - logic, ar trebui s\u0103 fac urm\u0103torul pas \u00een troubleshooting pe el, dar re\u021beaua mea este simpl\u0103 - un singur VLAN pentru VTEP \u0219i toate componentele sunt conectate direct. \u00cen plus, \u00eemi aduc aminte un caz cu DLR-bridge, VDR \u0219i trafic disp\u0103rut - merg s\u0103 sniff pe hostul ESXI, \u00een acela\u0219i timp cre\u00e2nd un caz la VMWare. Mai jos, MAC \u201e97:6e\u201d apar\u021bine forti, vmnic1 - acesta este interfa\u021ba care are VTEP cu adresa u.u.u.47, sniff\u0103m \u00een ambele direc\u021bii \"\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
\nProgres \u2013 \u00een monitorizare v\u0103d un request ARP \u0219i un r\u0103spuns venit. Aduc doar r\u0103spunsul ARP \u0219i acolo totul este corect. Nu am men\u021bionat, dar tot acest timp serverul de monitorizare trimite ping c\u0103tre adresa h.h.h.15 \u2013 unde este traficul ICMP? \u00cemi amintesc c\u0103 am dou\u0103 uplink-uri. Aici se poate argumenta \u0219i spune c\u0103 portul virtual surs\u0103 este acela\u0219i (politica mea de teaming), deci pentru aceea\u0219i vNIC ar trebui s\u0103 se selecteze acela\u0219i uplink, dar cum sunt pe gazd\u0103, verificarea unui alt uplink nu este o problem\u0103:<\/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
\nSunt cereri de la Fortigate, dar nu este niciun r\u0103spuns. Asta \u00eenseamn\u0103 c\u0103 problema nu este la Fortigate. Ei bine, m\u0103 g\u00e2ndesc eu, iar\u0103\u0219i aceea\u0219i problem\u0103 cu traficul disp\u0103rut pe VDR, iar\u0103\u0219i va trebui s\u0103 direc\u021bionez cazul vreo c\u00e2teva luni. Dup\u0103 c\u00e2teva zile, r\u0103cindu-m\u0103 \u0219i nesim\u021bindu-m\u0103 confortabil cu acest blocaj, am decis s\u0103 caut \u00eenc\u0103 ni\u0219te sniffuri pentru suport, pentru a accelera procesul. \u0218i aici, \u201e\u00eent\u00e2mpl\u0103tor\u201d, privirea mea cade pe encapsularea Ethernet underlay. \u00cemp\u0103ratul nu este adev\u0103rat, iar adresa MAC a VTEP nu corespunde cu IP-ul s\u0103u. Resetez, sniff, sap \u2014 corect, ce nu e corect. Voi aduce \u00een apropiere tabela ARP, pentru a fi mai u\u0219or de comparat. V\u0103 rog s\u0103 observa\u021bi prima encapsulare Ethernet din imaginea de sus:<\/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
\nA\u0219adar, ce avem \u00een final \u2014 dup\u0103 migrarea ma\u0219inii virtuale, Fortigate \u00eencearc\u0103 s\u0103 trimit\u0103 trafic c\u0103tre VTEP din (corecta) VXLAN FDB, dar folose\u0219te un MAC DST gre\u0219it, iar traficul este, a\u0219a cum era de a\u0219teptat, respins de interfa\u021ba care-l prime\u0219te a hypervizorului. De altfel, \u00een unul din patru cazuri, acest MAC apar\u021binea hypervizorului ini\u021bial de la care a \u00eenceput migrarea ma\u0219inii.<\/p>\n
Ieri am primit un e-mail de la suportul tehnic Fortinet \u2014 \u00een cazul meu au deschis un bug 615586. Nu \u0219tiu dac\u0103 s\u0103 m\u0103 bucur sau s\u0103 m\u0103 \u00eentristez: pe de o parte \u2014 problema nu este \u00een set\u0103ri, pe de alt\u0103 parte \u2014 fixul va veni doar cu o actualizare a firmware-ului, \u00een cel mai bun caz, \u00een urm\u0103toarea versiune. Ego-ul meu este alimentat \u0219i de un alt bug pe care l-am descoperit luna trecut\u0103, de data aceasta \u00een GUI HTML5 vSphere. Chiar un departament local de QA pentru furnizori...<\/p>\n
\u00cemi asum riscul de a presupune urm\u0103toarele:<\/p>\n
1 \u2014 este foarte probabil ca planul de control multicast s\u0103 nu fie supus problemei descrise \u2014 deoarece adresele MAC ale VTEP sunt ob\u021binute din adresa IP a grupului la care este abonat\u0103 interfa\u021ba. <\/p>\n
2 \u2014 problema Fortigate-ului este, probabil, legat\u0103 de desc\u0103rcarea sesiunilor pe Processorul de Re\u021bea (aproximativ echivalent cu CEF) \u2014 dac\u0103 fiecare pachet este procesat prin CPU, vor fi utilizate tabele care con\u021bin informa\u021bii corecte \u2014 cel pu\u021bin vizual. \u00cen favoarea acestei presupuneri este \u0219i faptul c\u0103 ajut\u0103 s\u0103 \u00eenchizi\/ deschizi interfa\u021ba sau s\u0103 a\u0219tep\u021bi un timp \u2014 mai mult de 5 minute. <\/p>\n
3 \u2014 modificarea politicii de teaming, de exemplu, \u00een explicit failover, sau implementarea LAG nu va rezolva problema, deoarece s-a observat \u201eblocarea\u201d MAC-ului hypervizorului ini\u021bial \u00een pachetele encapsulate.<\/p>\n
\u00cen lumina acestui lucru, pot s\u0103 \u00eemp\u0103rt\u0103\u0219esc c\u0103 recent am descoperit blog<\/a><\/noindex>, unde \u00eentr-unul dintre articole s-a afirmat c\u0103 firewalls-urile stetfull \u0219i metodele de transmitere a datelor care pot fi cache-uite sunt doar solu\u021bii de avarie. Ei bine, nu sunt at\u00e2t de experimentat \u00een IT \u00eenc\u00e2t s\u0103 fac astfel de afirma\u021bii, de asemenea nu sunt de acord cu toate afirma\u021biile din articolele blogului. Totu\u0219i, ceva \u00eemi spune c\u0103 exist\u0103 o parte de adev\u0103r \u00een cuvintele lui Ivan.<\/p>\n
V\u0103 mul\u021bumesc pentru aten\u021bie! Voi fi bucuros s\u0103 r\u0103spund la \u00eentreb\u0103ri \u0219i s\u0103 aud critici constructive.
\n
Sursa: 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\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 \u00een NSX-V \u2014 diagnostic\u0103m underlay | ProHoster","description":"Salut, \u0219i mai \u00eent\u00e2i pu\u021bin\u0103 poezie.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}