{"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\/sv\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN i NSX-V \u2014 fels\u00f6kning av underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, l\u00e5t mig f\u00f6rst s\u00e4ga lite lyssnartankar. Jag k\u00e4nner ibland avund p\u00e5 kollegor som arbetar p\u00e5 distans \u2013 det \u00e4r verkligen underbart att kunna arbeta fr\u00e5n vilken del av den internetanslutna v\u00e4rlden som helst, ta ledigt n\u00e4r som helst, ha ansvar f\u00f6r projekt och deadlines, ist\u00e4llet f\u00f6r att sitta p\u00e5 kontoret fr\u00e5n 8 till 17. Min position och arbetsuppgifter utesluter n\u00e4stan m\u00f6jligheten till l\u00e5ngvarig fr\u00e5nvaro fr\u00e5n datacentret. Men \u2013 d\u00e5 och d\u00e5 h\u00e4nder det intressanta fall, som det nedan beskrivna \u2013 och jag f\u00f6rst\u00e5r att det finns f\u00e5 positioner d\u00e4r man har s\u00e5 mycket utrymme f\u00f6r kreativt uttryck som intern troubleshooter.
\n<\/a><\/noindex>
\nEn liten disklaimer \u2014 vid tidpunkten f\u00f6r artikelns skrivande \u00e4r fallet inte helt l\u00f6st, men med tanke p\u00e5 svarstiden fr\u00e5n leverant\u00f6rer kan det dr\u00f6ja m\u00e5nader att f\u00e5 en fullst\u00e4ndig l\u00f6sning, och jag vill g\u00e4rna dela med mig av mina fynd redan nu. Jag hoppas att ni, k\u00e4ra l\u00e4sare, kan f\u00f6rl\u00e5ta mig denna br\u00e5dska. Men nog med vatten \u2014 vad h\u00e4nder med fallet? <\/p>\n

F\u00f6rst en introduktion: det finns ett f\u00f6retag (d\u00e4r jag arbetar som n\u00e4tverksingenj\u00f6r) som hostar kundl\u00f6sningar i en privat VMWare-moln. De flesta nya l\u00f6sningar ansluts till VXLAN-segment som hanteras av NSX-V \u2014 jag ska inte bed\u00f6ma hur mycket tid detta beslut har gett mig, kort sagt \u2014 mycket. Jag har till och med lyckats l\u00e4ra kollegor att konfigurera NSX ESG och sm\u00e5 kundl\u00f6sningar implementeras utan min inblandning. En viktig notering \u2014 kontrollplanet har vi med unicast-replikering. Hypervisorerna \u00e4r anslutna redundanta med tv\u00e5 gr\u00e4nssnitt till olika fysiska Juniper QFX5100-switchar (som \u00e4r ihopkopplade i ett Virtual Chassis) och en policy f\u00f6r rutning baserad p\u00e5 den ursprungliga virtuella porten \u2014 detta f\u00f6r att f\u00e5 en helhetsbild.<\/p>\n

Kundl\u00f6sningarna \u00e4r mycket skiftande: fr\u00e5n Windows IIS, d\u00e4r alla komponenter av webbservern \u00e4r installerade p\u00e5 en och samma maskin, till ganska stora \u2014 exempelvis lastbalanserade Apache-webbfronter + LB MariaDB i Galera + delad servrar, synkroniserade med GlusterFS. N\u00e4stan varje server m\u00e5ste \u00f6vervakas separat, och offentliga adresser finns inte f\u00f6r alla komponenter \u2014 om du har st\u00f6tt p\u00e5 denna uppgift och har en mer elegant l\u00f6sning, skulle jag uppskatta ett tips.
\nMin \u00f6vervakningsl\u00f6sning inneb\u00e4r att \"koppla\" brandv\u00e4ggen (Fortigate) till varje intern kundn\u00e4tverk (+SNAT och sj\u00e4lvklart strikt begr\u00e4nsning av till\u00e5ten trafik) och \u00f6vervaka interna adresser \u2013 p\u00e5 s\u00e5 s\u00e4tt uppn\u00e5s en form av enhetlighet och f\u00f6renkling av \u00f6vervakningen. Sj\u00e4lv \u00f6vervakning g\u00f6rs fr\u00e5n en kluster av PRTG-servrar. \u00d6vervakningsschemat ser ungef\u00e4r ut s\u00e5 h\u00e4r:<\/p>\n

\"VXLAN
\n
\nN\u00e4r vi endast arbetade med VLAN fungerade allt ganska vanligt och f\u00f6ruts\u00e4gbart, som en klocka. Efter implementeringen av NSX-V och VXLAN st\u00e4lldes vi inf\u00f6r fr\u00e5gan \u2013 kan vi forts\u00e4tta \u00f6vervaka som tidigare? Vid tidpunkten f\u00f6r denna fr\u00e5ga var den \"snabbaste\" l\u00f6sningen att distribuera NSX ESG och koppla VXLAN trunk-gr\u00e4nssnittet till VTEP-n\u00e4tverket. Snabbt i citat \u2013 eftersom anv\u00e4ndning av GUI f\u00f6r att konfigurera kundn\u00e4tverk, SNAT och brandv\u00e4ggsregler kanske enhetligg\u00f6r hanteringen i ett enda vSphere-grinterfaces, men enligt min \u00e5sikt \u00e4r det ganska klumpigt och, ut\u00f6ver allt, begr\u00e4nsar det verktygssatserna f\u00f6r fels\u00f6kning. De som har anv\u00e4nt NSX ESG som ers\u00e4ttning f\u00f6r en \"riktig\" brandv\u00e4gg kommer nog att h\u00e5lla med. \u00c4ven om, kanske, en s\u00e5dan l\u00f6sning skulle vara mer stabil \u2013 eftersom allt sker inom en leverant\u00f6rs ramverk.<\/p>\n

En annan l\u00f6sning \u00e4r att anv\u00e4nda NSX DLR i bridge-l\u00e4ge mellan VLAN och VXLAN. H\u00e4r tycker jag att allt \u00e4r klart \u2013 man f\u00f6rlorar helt enkelt f\u00f6rdelen med att anv\u00e4nda VXLAN \u2013 eftersom man fortfarande m\u00e5ste dra VLAN till \u00f6vervakningsinstallationen. F\u00f6r \u00f6vrigt st\u00f6tte jag under arbetet med den h\u00e4r l\u00f6sningen p\u00e5 ett problem d\u00e4r DLR-bryggan inte skickade paket till den virtuella maskin med vilken den befann sig p\u00e5 samma v\u00e4rd. Jag vet, jag vet \u2013 i b\u00f6cker och guider om NSX-V st\u00e5r det klart att en separat kluster ska tilldelas NSX Edge, men det \u00e4r i b\u00f6ckerna\u2026 Hur som helst, efter ett par m\u00e5nader med supporten l\u00f6ste vi inte problemet. I princip f\u00f6rstod jag logiken bakom \u2013 k\u00e4rnmodulen i hypervisorn, som \u00e4r ansvarig f\u00f6r inkapsling av VXLAN, aktiverades inte om DLR och den observerade servern befann sig p\u00e5 samma v\u00e4rd, eftersom trafiken inte l\u00e4mnar v\u00e4rden och enligt logiken skulle vara kopplad till VXLAN-segmentet \u2013 inkapsling beh\u00f6vs inte. Med supporten kom vi fram till det virtuella gr\u00e4nssnittet vdrPort, som logiskt f\u00f6renar uplinks och \u00e4ven utf\u00f6r bryggning\/inkapsling \u2013 d\u00e4r noterades en avvikelse i den inkommande trafiken, som jag tog med mig i det aktuella \u00e4rendet. Men som sagt, jag avslutade inte detta \u00e4rende helt, eftersom jag blev \u00f6verflyttad till ett annat projekt och dessutom var den grenen fr\u00e5n b\u00f6rjan en \u00e5terv\u00e4ndsgr\u00e4nd, och jag hade inte s\u00e4rskilt mycket lust att utveckla den. Om jag inte misstar mig observerades problemet i versionerna NSX 6.1.4 och 6.2. <\/p>\n

Och d\u00e4r - bingo! Fortinet tillk\u00e4nnager nativ st\u00f6d f\u00f6r VXLAN<\/a><\/noindex>. Och inte bara point-to-point eller VXLAN-over-IPSec, inte programvarubryggning av VLAN-VXLAN - allt detta b\u00f6rjade implementeras redan med version 5.4 (och finns representerat hos andra leverant\u00f6rer<\/a><\/noindex>), och riktig support av unicast control plane. Vid implementeringen av l\u00f6sningen st\u00f6tte jag p\u00e5 ett annat problem \u2014 de kontrollerade servrarna f\u00f6rsvann ibland fr\u00e5n \u00f6vervakningen, \u00e4ven om den virtuella maskinen var vid liv. Anledningen visade sig vara att jag gl\u00f6mt att till\u00e5ta Ping p\u00e5 VXLAN-gr\u00e4nssnittet. Under processen med ombalanseringen av kluster flyttades de virtuella maskinerna, och Ping avslutade vMotion f\u00f6r att indikera den nya ESXI-v\u00e4rden till vilken maskinen hade flyttats. Min dumhet, men detta problem skakade \u00e5terigen mitt f\u00f6rtroende f\u00f6r tillverkarens support \u2014 i det h\u00e4r fallet Fortinet. Jag n\u00e4mner inte ens att varje fall som r\u00f6r VXLAN b\u00f6rjar med fr\u00e5gan \"var har ni er mjukvarubrygga VLAN-VXLAN i inst\u00e4llningarna?\" Den h\u00e4r g\u00e5ngen r\u00e5dde de mig att \u00e4ndra MTU \u2014 det g\u00e4ller f\u00f6r Ping som \u00e4r 32 byte. Sedan \"leka\" med tcp-send-mss och tcp-receive-mss i policyn \u2014 f\u00f6r VXLAN som inkapslas i UDP. Puh, f\u00f6rl\u00e5t \u2014 det har samlats p\u00e5 h\u00f6g. Jag l\u00f6ste detta problem p\u00e5 egen hand. <\/p>\n

Efter att ha testat trafik framg\u00e5ngsrikt beslutades det att implementera denna l\u00f6sning. Och i produktion visade det sig att efter en eller tv\u00e5 dagar f\u00f6rsvann allt som \u00f6vervakades genom VXLAN gradvis. Deaktivering\/aktivering av gr\u00e4nssnittet hj\u00e4lpte, men bara f\u00f6r en kort stund. Med tanke p\u00e5 tillverkarens l\u00e5ngsamhet i support, satte jag ig\u00e5ng med fels\u00f6kningen fr\u00e5n min sida - i slut\u00e4ndan \u00e4r det mitt f\u00f6retag, mitt n\u00e4tverk - mitt ansvar. <\/p>\n

Under spoiler-texten finns fels\u00f6kningsprocessen. Den som tr\u00f6ttnat p\u00e5 bokst\u00e4ver och \u00f6verdrifter - hoppa \u00f6ver detta och g\u00e5 vidare till postanalysen.<\/p>\n

Fels\u00f6kningsprocessen<\/b>Tack f\u00f6r att du fortsatte l\u00e4sa - vi forts\u00e4tter!<\/p>\n

S\u00e5, \u00f6vervakningen fungerar under en tid, sedan bryter den ner av sig sj\u00e4lv. Det antyder att det f\u00f6rmodligen inte finns n\u00e5gra problem i brandv\u00e4ggens policyer. Men eftersom jag har st\u00f6tt p\u00e5 problemet med h\u00e4ngande systemprocesser i Fortigate versioner 5.6+, s\u00e5 kollar vi f\u00f6rst p\u00e5 \"diagnose debug flow\" - som v\u00e4ntat till\u00e5ts trafiken och skickas ut fr\u00e5n gr\u00e4nssnittet och som v\u00e4ntat kommer det inget svar. S\u00e5 vi gr\u00e4ver vidare i stacken. Tyv\u00e4rr m\u00e5ste vi d\u00f6lja adresser, \u00e4ven om de \u00e4r RFC1918, men jag hoppas kunna ge processen en tillr\u00e4cklig beskrivning f\u00f6r f\u00f6rst\u00e5else. Servern inom VXLAN har adress x.x.x.15, Fortigate-gr\u00e4nssnittet x.x.x.254, och alla andra adresser tillh\u00f6r VTEP-n\u00e4tverket.<\/p>\n

F\u00f6r en lyckad \u00f6verf\u00f6ring av VXLAN-kapslade paket kr\u00e4vs korrekt information i flera tabeller. F\u00f6r overlay \u00e4r det ARP och OVSDB, f\u00f6r underlay \u00e4r det ARP och CAM. I fallet med Fortigate \u00e4r VXLAN FDB och OVSDB samma sak. H\u00e4r b\u00f6rjar vi:<\/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
\nH\u00e4r \u00e4r allt ganska enkelt \u2014 MAC-adressen f\u00f6r den virtuella maskinen m\u00e5ste finnas p\u00e5 VTEP med adressen \u0443.\u0443.\u0443.47. Genom att titta p\u00e5 inneh\u00e5llet och inst\u00e4llningarna i ESXI-klustret finner jag att MAC-adressen f\u00f6r den virtuella maskinen \u00e4r korrekt, och adressen f\u00f6r VTEP likas\u00e5. Jag kontrollerar CAM\/ARP-tabellen p\u00e5 fortigate \u2014 \u00e5terigen st\u00e4mmer allt \u00f6verens med inst\u00e4llningarna p\u00e5 ESXI-v\u00e4rden:<\/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
\nTabellerna \u00e4r korrekta och trafiken g\u00e5r \u2014 kanske \u00e4r problemet inte p\u00e5 Fortigate? Jag har avsiktligt hoppat \u00f6ver att analysera trafikv\u00e4xlingen p\u00e5 Juniper \u2014 logiskt sett b\u00f6r n\u00e4sta steg i fels\u00f6kningen g\u00f6ras d\u00e4r, men mitt n\u00e4tverk \u00e4r enkelt \u2014 bara ett VLAN f\u00f6r VTEP och alla komponenter \u00e4r direktanslutna. Dessutom kommer jag ih\u00e5g fallet med DLR-bryggan, VDR och f\u00f6rsvinnande trafik \u2013 jag g\u00e5r f\u00f6r att sniffa p\u00e5 ESXI-v\u00e4rden, samtidigt som jag skapar ett fall till VMware. Nedan MAC \"97:6e\" tillh\u00f6r Fortigate, vmnic1 \u2014 det \u00e4r gr\u00e4nssnittet som har VTEP med adressen u.u.u.47, vi sniffar i b\u00e5da riktningarna \"\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
\nFramsteg \u2014 i sniffen ser jag ARP-f\u00f6rfr\u00e5gan och det inkommande svaret. Jag visar bara ARP-svaret och d\u00e4r \u00e4r allt korrekt. Jag n\u00e4mnde inte, men under hela denna tid pingade \u00f6vervakningsservern adressen \u0445.\u0445.\u0445.15 \u2014 var \u00e4r ICMP-trafiken? Jag minns att jag har tv\u00e5 uplinks. H\u00e4r kan man diskutera och s\u00e4ga att den virtuella portens k\u00e4lla \u00e4r densamma (min teaming policy), det vill s\u00e4ga f\u00f6r samma vNIC borde samma uplink v\u00e4ljas, men eftersom jag \u00e4r p\u00e5 v\u00e4rden \u00e4r det inget problem att kontrollera den andra uplinken:<\/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
\nJag f\u00e5r f\u00f6rfr\u00e5gningar fr\u00e5n Fortigate, men inget svar. Det vill s\u00e4ga att problemet inte ligger hos Fortigate. Tja, jag t\u00e4nker att det \u00e4r samma gamla problem med f\u00f6rlorad trafik p\u00e5 VDR, \u00e5terigen m\u00e5ste jag spendera ett par m\u00e5nader f\u00f6r att f\u00e5 till r\u00e4tt person med \u00e4rendet. Efter ett par dagar, n\u00e4r jag svalt ner det och inte ville acceptera situationen, best\u00e4mde jag mig f\u00f6r att samla fler sniffar f\u00f6r supporten f\u00f6r att p\u00e5skynda processen. Och h\u00e4r, \"av en slump\", dras min blick till Ethernet-inkapslingen underlay. Kungen \u00e4r inte verklig och MAC-adressen f\u00f6r VTEP \u00f6verensst\u00e4mmer inte med dess IP. Jag nollst\u00e4ller, sniffer, gr\u00e4ver \u2014 sant eller falskt. Jag kommer att visa ARP-tabellen bredvid, s\u00e5 att det \u00e4r l\u00e4ttare att j\u00e4mf\u00f6ra. Notera den f\u00f6rsta Ethernet-inkapslingen p\u00e5 bilden ovan:<\/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
\nS\u00e5, vad har vi kommit fram till \u2014 efter migreringen av den virtuella maskinen, f\u00f6rs\u00f6ker Fortigate skicka trafik till VTEP fr\u00e5n (korrekt) VXLAN FDB, men anv\u00e4nder fel DST MAC och trafiken kasseras som f\u00f6rv\u00e4ntat av den mottagande hypervisorgr\u00e4nssnittet. Och i en av fyra fall tillh\u00f6rde denna MAC den ursprungliga hypervisorn, fr\u00e5n vilken migreringen av maskinen p\u00e5b\u00f6rjades.<\/p>\n
Ig\u00e5r fick jag ett mejl fr\u00e5n Fortinet-supporten \u2014 de har \u00f6ppnat en bugg 615586 f\u00f6r mitt \u00e4rende. Jag vet inte om jag ska vara glad eller ledsen: \u00e5 ena sidan \u2014 problemet ligger inte i inst\u00e4llningarna, \u00e5 andra sidan \u2014 fixen kommer bara med n\u00e4sta firmware-uppdatering, i b\u00e4sta fall n\u00e4sta. Mitt ego f\u00e5r ocks\u00e5 en extra boost av en annan bugg som jag identifierade f\u00f6rra m\u00e5naden, dock vid HTML5 GUI vSphere. Det \u00e4r verkligen som en lokal QA-avdelning hos leverant\u00f6rer...<\/p>\n
Jag v\u00e5gar g\u00f6ra f\u00f6ljande antagande:<\/p>\n
1 \u2014 multicast-kontrollplanet kommer f\u00f6rmodligen inte att vara utsatt f\u00f6r det beskrivna problemet \u2014 eftersom MAC-adresserna f\u00f6r VTEP f\u00e5rs fr\u00e5n gruppens IP-adress som gr\u00e4nssnittet \u00e4r prenumererat p\u00e5. <\/p>\n
2 \u2014 f\u00f6rmodligen ligger felet hos Fortigate i avlastningen av sessioner till Network Processor (ungef\u00e4r som CEF) \u2014 om varje paket passerar genom CPU:n, kommer de att anv\u00e4nda tabeller som inneh\u00e5ller korrekt \u2014 i alla fall visuellt \u2014 information. Det st\u00f6der detta antagande att det hj\u00e4lper att st\u00e4nga\/\u00f6ppna gr\u00e4nssnittet eller v\u00e4nta en stund \u2014 mer \u00e4n 5 minuter. <\/p>\n
3 \u2014 att \u00e4ndra teaming-policy, till exempel till explicit failover, eller att inf\u00f6ra LAG kommer inte att l\u00f6sa problemet, eftersom det har observerats \"fastna\" MAC-adressen f\u00f6r den ursprungliga hypervisorn i inkapslade paket.<\/p>\n
I detta ljus kan jag dela med mig av att jag nyligen har uppt\u00e4ckt bloggen<\/a><\/noindex>, d\u00e4r en av artiklarna p\u00e5stod att stateful brandv\u00e4ggar och cachade data\u00f6verf\u00f6ringsmetoder \u00e4r tillf\u00e4lliga l\u00f6sningar. Tja, jag \u00e4r inte tillr\u00e4ckligt erfaren inom IT f\u00f6r att p\u00e5st\u00e5 n\u00e5got s\u00e5dant, dessutom h\u00e5ller jag inte alltid med om p\u00e5st\u00e5endena i blogginl\u00e4ggen. Men n\u00e5got s\u00e4ger mig att det finns en del sanning i Ivans ord.<\/p>\n
Tack f\u00f6r uppm\u00e4rksamheten! Jag ser fram emot att svara p\u00e5 fr\u00e5gor och h\u00f6ra konstruktiv kritik.
\n
K\u00e4lla: 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 i NSX-V \u2014 fels\u00f6ker underlay | ProHoster","description":"Jag h\u00e4lsar er och inledningsvis lite lyrik.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}