{"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\/sk\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN v NSX-V \u2014 rie\u0161ime probl\u00e9my underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

V\u00edtam v\u00e1s a na za\u010diatok trochu lyriky. Niekedy z\u00e1vid\u00edm svojim kolegom, ktor\u00ed pracuj\u00fa na dia\u013eku \u2013 je to predsa skvel\u00e9 ma\u0165 mo\u017enos\u0165 pracova\u0165 z ktor\u00e9hoko\u013evek miesta na svete pripojen\u00e9ho k Internetu, \u010derpa\u0165 pr\u00e1zdniny kedyko\u013evek, ma\u0165 zodpovednos\u0165 za projekty a term\u00edny, a nie by\u0165 zavret\u00fd v kancel\u00e1rii od 8 do 17. Moja poz\u00edcia a pracovn\u00e9 povinnosti takmer vylu\u010duj\u00fa mo\u017enos\u0165 dlhodobo ch\u00fdba\u0165 v d\u00e1tovom centre. Av\u0161ak, pravidelne sa objavia zauj\u00edmav\u00e9 pr\u00edpady, podobn\u00e9 tomuto ni\u017e\u0161ie \u2013 a ch\u00e1pem, \u017ee existuje len m\u00e1lo poz\u00edci\u00ed, kde je tak\u00fd priestor na kreat\u00edvne vyjadrenie vn\u00fatorn\u00e9ho troubleshooter'a.
\n<\/a><\/noindex>
\nMal\u00fd disklejmer \u2014 v \u010dase p\u00edsania \u010dl\u00e1nku nebol pr\u00edpad \u00faplne vyrie\u0161en\u00fd, ale vzh\u013eadom na r\u00fdchlos\u0165 odpoved\u00ed dod\u00e1vate\u013eov m\u00f4\u017ee \u00fapln\u00e9 rie\u0161enie trva\u0165 e\u0161te mesiace, a chcem sa podeli\u0165 o svoje n\u00e1lezy u\u017e teraz. D\u00fafam, v\u00e1\u017een\u00ed \u010ditatelia, \u017ee mi odpust\u00edte t\u00fato ukvapenos\u0165. Ale dos\u0165 o vode \u2014 \u010do sa deje s pr\u00edpadom? <\/p>\n

Na za\u010diatku Kontext: existuje firma (kde pracujem ako sie\u0165ov\u00fd in\u017einier), ktor\u00e1 hos\u0165uje klientsk\u00e9 rie\u0161enia v priv\u00e1tnom cloude VMWare. V\u00e4\u010d\u0161ina nov\u00fdch rie\u0161en\u00ed sa prip\u00e1ja k VXLAN-segmentom, ktor\u00e9 s\u00fa spravovan\u00e9 NSX-V \u2014 nebudem hodnoti\u0165, ko\u013eko \u010dasu mi toto rie\u0161enie u\u0161etrilo, stru\u010dne povedan\u00e9 \u2014 ve\u013ea. Dok\u00e1zal som dokonca za\u0161koli\u0165 kolegov v nastaven\u00ed NSX ESG a mal\u00e9 klientsk\u00e9 rie\u0161enia sa nasadzuj\u00fa bez mojej \u00fa\u010dasti. D\u00f4le\u017eit\u00e1 pozn\u00e1mka \u2014 riadiaca rovina m\u00e1 unicast replik\u00e1ciu. Hyperv\u00edzory s\u00fa pripojen\u00e9 redundantne dvoma rozhran\u00edm k r\u00f4znym fyzick\u00fdm prep\u00edna\u010dom Juniper QFX5100 (zostaven\u00fdm v Virtual Chassis) a politikou \u010dasovania route based on originating virtual port \u2014 to pre \u00faplnos\u0165 obrazu.<\/p>\n

Klientsk\u00e9 rie\u0161enia s\u00fa ve\u013emi r\u00f4znorod\u00e9: od Windows IIS, kde s\u00fa v\u0161etky komponenty webov\u00e9ho servera nain\u0161talovan\u00e9 na jednom zariaden\u00ed, a\u017e po skuto\u010dne ve\u013ek\u00e9 \u2014 napr\u00edklad load-balanced Apache webov\u00e9 fronty + LB MariaDB v Galera + zdie\u013ean\u00e9 servery synchronizovan\u00e9 pomocou GlusterFS. Prakticky ka\u017ed\u00fd server je potrebn\u00e9 monitorova\u0165 osobitne, a verejn\u00e9 adresy nem\u00e1 v\u0161etky komponenty \u2014 ak ste sa s touto \u00falohou u\u017e stretli a m\u00e1te elegantnej\u0161ie rie\u0161enie, budem r\u00e1d za radu.
\nMoje rie\u0161enie monitorovania spo\u010d\u00edva v \"pripojen\u00ed\" firewallu (Fortigate) k ka\u017edej vn\u00fatornej klientskej sieti (+SNAT a samozrejme pr\u00edsne obmedzenia t\u00fdkaj\u00face sa povolen\u00e9ho prenosu) a sledovan\u00ed intern\u00fdch adries - takto sa dosahuje ur\u010dit\u00e1 unifik\u00e1cia a zjednodu\u0161enie monitorovania. Samotn\u00e9 monitorovanie prebieha z klasteru serverov PRTG. Sch\u00e9ma monitorovania vyzer\u00e1 pribli\u017ene takto:<\/p>\n

\"VXLAN
\n
\nK\u00fdm sme pracovali iba s VLAN, v\u0161etko bolo celkom be\u017en\u00e9 a predv\u00eddate\u013en\u00e9, fungovalo to ako hodinky. Po zaveden\u00ed NSX-V a VXLAN sme sa stretli s ot\u00e1zkou - m\u00f4\u017ee sa pokra\u010dova\u0165 v monitorovan\u00ed star\u00fdm sp\u00f4sobom? V \u010dase tejto ot\u00e1zky bolo najr\u00fdchlej\u0161\u00edm rie\u0161en\u00edm nasadi\u0165 NSX ESG a pripoji\u0165 VXLAN trunk-interface do siete VTEP. R\u00fdchle v \u00favodzovk\u00e1ch - preto\u017ee pou\u017eitie GUI na nastavenie klientskych siet\u00ed, SNAT a pravidiel firewallu s\u00edce m\u00f4\u017ee unifikova\u0165 spr\u00e1vu v jedin\u00e9ho rozhran\u00ed vSphere, ale pod\u013ea m\u00f4jho n\u00e1zoru je to dos\u0165 nepreh\u013eadn\u00e9 a okrem in\u00e9ho obmedzuje sadu n\u00e1strojov na rie\u0161enie probl\u00e9mov. T\u00ed, ktor\u00ed pou\u017e\u00edvali NSX ESG ako n\u00e1hradu za \"skuto\u010dn\u00fd\" firewall, si mysl\u00edm, s\u00fahlas\u00ed. Hoci, pravdepodobne, tak\u00e9to rie\u0161enie by bolo stabilnej\u0161ie - ve\u010f v\u0161etko prebieha v r\u00e1mci jedn\u00e9ho dod\u00e1vate\u013ea.<\/p>\n

\u010eal\u0161\u00edm rie\u0161en\u00edm je pou\u017ei\u0165 NSX DLR v re\u017eime mosta medzi VLAN a VXLAN. Tu mysl\u00edm, \u017ee je v\u0161etko jasn\u00e9 \u2014 jednoducho sa strat\u00ed v\u00fdhoda z pou\u017eit\u00ed VXLAN \u2014 ve\u010f v tomto pr\u00edpade aj tak treba \u0165aha\u0165 VLAN k monitorovacej in\u0161tal\u00e1cii. Mimochodom, pri pr\u00e1ci na tomto rie\u0161en\u00ed som sa stretol s probl\u00e9mom, ke\u010f DLR most neodosielal pakety virtu\u00e1lke, s ktorou sa nach\u00e1dzal na jedinom hoste. Viem, viem \u2014 v knih\u00e1ch a pr\u00edru\u010dk\u00e1ch o NSX-V priamo povedan\u00e9, \u017ee pre NSX Edge by mal by\u0165 vyhraden\u00fd samostatn\u00fd klaster, ale to je v knih\u00e1ch\u2026 Tak \u010di onak, po p\u00e1r mesiacoch s podporou sme probl\u00e9m nevyrie\u0161ili. V z\u00e1sade som pochopil logiku fungovania \u2014 modul jadra hyperv\u00edzora zodpovedn\u00fd za enkapsul\u00e1ciu VXLAN nebol vyu\u017e\u00edvan\u00fd, ak DLR a monitorovan\u00fd server boli na jednom hoste, preto\u017ee prev\u00e1dzka neopustila host a pod\u013ea logiky by mala by\u0165 pripojen\u00e1 k VXLAN segmentu \u2014 enkapsul\u00e1cia nie je potrebn\u00e1. S podporou sme sa zastavili na virtu\u00e1lnom rozhran\u00ed vdrPort, ktor\u00e9 logicky sp\u00e1ja uplinky a ono samo uskuto\u010d\u0148uje mostovanie\/enkapsul\u00e1ciu \u2014 tam bolo pozorovan\u00e9 nes\u00falad vo vch\u00e1dzaj\u00facej prev\u00e1dzke, ktor\u00fd som zobrala na spracovanie v aktu\u00e1lnom pr\u00edpade. Ale ako bolo povedan\u00e9, do konca som tento pr\u00edpad nedovedol, preto\u017ee som bol presmerovan\u00fd na in\u00fd projekt a takisto t\u00e1to vetva bola p\u00f4vodne bezv\u00fdchodn\u00e1 a nemal som ve\u013emi chu\u0165 ju rozv\u00edja\u0165. Ak sa nem\u00fdlim, probl\u00e9m bol pozorovan\u00fd vo verzi\u00e1ch NSX 6.1.4 a 6.2. <\/p>\n

A tu \u2014 bingo! Fortinet oznamuje nat\u00edvnu podporu VXLAN<\/a><\/noindex>. A nie len point-to-point alebo VXLAN-over-IPSec, nie softv\u00e9rov\u00e9 mostovanie VLAN-VXLAN \u2014 toto v\u0161etko za\u010dali zav\u00e1dza\u0165 u\u017e od verzie 5.4 (a je to predlo\u017een\u00e9 u in\u00fdch dod\u00e1vate\u013eov<\/a><\/noindex>), a skuto\u010dn\u00fa podporu unicast control plane. Pri implement\u00e1cii rie\u0161enia som narazil na \u010fal\u0161\u00ed probl\u00e9m \u2013 monitorovan\u00e9 servery ob\u010das \u201ezmizli\u201c alebo sa objavili, hoci sama virtu\u00e1lka pre\u017eila. Pr\u00ed\u010dinou, ako sa uk\u00e1zalo, bolo to, \u017ee som zabudol povoli\u0165 Ping na VXLAN rozhran\u00ed. Pri procese rebalance klastrov sa virtu\u00e1lky pres\u00favali, a Pingom kon\u010dil vMotion, aby ozna\u010dil nov\u00fd ESXi host, na ktor\u00fd sa stroj presunul. Bola to moja hl\u00fapos\u0165, ale tento probl\u00e9m op\u00e4\u0165 podkopal d\u00f4veru v podporu v\u00fdrobcu \u2013 v tomto pr\u00edpade Fortinet. Nehovor\u00edm u\u017e o tom, \u017ee ka\u017ed\u00fd pr\u00edpad spojen\u00fd s VXLAN za\u010d\u00edna ot\u00e1zkou \u201ekde m\u00e1te vo svojich nastaveniach softswitch VLAN-VXLAN?\u201c Tentokr\u00e1t mi poradili zmeni\u0165 MTU \u2013 to je pre Ping, ktor\u00fd m\u00e1 32 bajtov. Potom sa \u201epohral\u201c s tcp-send-mss a tcp-receive-mss v politike \u2013 pre VXLAN, ktor\u00fd je enkapsulovan\u00fd v UDP. Uf, prep\u00e1\u010dte \u2013 nahromadilo sa to. V ka\u017edom pr\u00edpade tento probl\u00e9m som vyrie\u0161il svojpomocne. <\/p>\n

\u00daspe\u0161ne odsk\u00fa\u0161an\u00edm testovacieho prenosu sa rozhodlo implementova\u0165 toto rie\u0161enie. A v produkcii sa uk\u00e1zalo, \u017ee po jednom alebo dvoch d\u0148och postupne odpad\u00e1va v\u0161etko, \u010do je monitorovan\u00e9 cez VXLAN. Deaktiv\u00e1cia\/aktiv\u00e1cia rozhrania pomohla, ale iba na kr\u00e1tky \u010das. Pam\u00e4taj\u00fac na pomalos\u0165 podpory v\u00fdrobcu, som sa pustil do troubleshooting z mojej strany - ve\u010f napokon moja spolo\u010dnos\u0165, moja sie\u0165 - moja zodpovednos\u0165. <\/p>\n

Pod spoilerom sa nach\u00e1dza priebeh troubleshooting. Kto sa unavil od p\u00edsmen a chvastania - presko\u010dte a prejdite k postanal\u00fdze.<\/p>\n

Priebeh troubleshooting<\/b>\u010eakujem, \u017ee ste pokra\u010dovali v \u010d\u00edtan\u00ed - pokra\u010dujme!<\/p>\n

Tak\u017ee, monitoring funguje nejak\u00fd \u010das, potom sa s\u00e1m odpoj\u00ed. Znamen\u00e1 to, \u017ee v politik\u00e1ch firewallu pravdepodobne nie s\u00fa probl\u00e9my. Av\u0161ak, ke\u010f\u017ee som sa stretol s probl\u00e9mom zamrznut\u00fdch syst\u00e9mov\u00fdch procesov vo Fortigate verzi\u00e1ch 5.6+, najprv sa pozrieme na \u201ediagnose debug flow\u201c - o\u010dak\u00e1vane, traffic je povolen\u00fd a odch\u00e1dza z rozhrania a o\u010dak\u00e1vane ni\u010d neprich\u00e1dza ako odpove\u010f. Znamen\u00e1 to, \u017ee mus\u00edme kopn\u00fa\u0165 hlb\u0161ie do z\u00e1sobn\u00edka. Budem musie\u0165, bohu\u017eia\u013e, skry\u0165 adresy, aj ke\u010f s\u00fa RFC1918, ale d\u00fafam, \u017ee proces bude dostato\u010dne pop\u00edsan\u00fd na pochopenie. Server vn\u00fatri VXLAN m\u00e1 adresu x.x.x.15, rozhranie Fortigate m\u00e1 adresu x.x.x.254, v\u0161etky ostatn\u00e9 adresy patria do siete VTEP.<\/p>\n

Na \u00faspe\u0161n\u00fd prenos VXLAN zakapsulovan\u00fdch paketov je potrebn\u00e9 ma\u0165 spr\u00e1vne inform\u00e1cie v nieko\u013ek\u00fdch tabu\u013ek\u00e1ch. Pre overlay ide o ARP a OVSDB, pre underlay s\u00fa to ARP a CAM. V pr\u00edpade Fortigate je VXLAN FDB a OVSDB rovnak\u00fd. Odtia\u013e aj za\u010dneme:<\/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
\nTu je v\u0161etko dos\u0165 jednoduch\u00e9 \u2014 MAC adresa virtu\u00e1lneho stroja mus\u00ed by\u0165 na VTEP s adresou \u0443.\u0443.\u0443.47. Skontroloval som obsah a nastavenia ESXI klastra a zistil som, \u017ee MAC virtu\u00e1lneho stroja je spr\u00e1vny, adresa VTEP tie\u017e. Kontrolujem CAM\/ARP tabu\u013eku na Fortigate \u2014 op\u00e4\u0165 v\u0161etko s\u00fahlas\u00ed s nastaveniami ESXI hostite\u013ea:<\/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
\nTabu\u013eky s\u00fa spr\u00e1vne a traffic odch\u00e1dza \u2013 mo\u017eno probl\u00e9m nie je na Fortigate? \u00damyselne som vynechal anal\u00fdzu prep\u00ednania trafficu na Juniper'i \u2013 logicky to na \u0148om treba vykona\u0165 \u010fal\u0161\u00ed krok troubleshooting-u, ale sie\u0165 m\u00e1m jednoduch\u00fa \u2013 len jeden VLAN pre VTEP a v\u0161etky komponenty s\u00fa pripojen\u00e9 priamo. Plus si spom\u00ednam na pr\u00edpad s DLR bridge, VDR a mizn\u00facim trafficom \u2013 idem sniffova\u0165 na ESXi hoste, popri tom vytv\u00e1ram pr\u00edpad u\u017e aj na VMWare. Ni\u017e\u0161ie MAC \u201e97:6e\u201c patr\u00ed Forti, vmnic1 \u2013 to je rozhranie, ktor\u00e9 m\u00e1 VTEP s adresou u.u.u.47, sniffujeme v oboch smeroch \"\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
\nPokrok \u2014 v sn\u00edman\u00ed vid\u00edm ARP po\u017eiadavku a prich\u00e1dzaj\u00facu odpove\u010f. Uv\u00e1dzam len ARP odpove\u010f a tam je v\u0161etko spr\u00e1vne. Nespomenul som, ale po cel\u00e9 toto obdobie server monitorovania pingoval adresu \u0445.\u0445.\u0445.15 \u2014 kde je ICMP prenos? Spom\u00ednam si, \u017ee m\u00e1m dva uplinky. Tu by sa dalo polemizova\u0165 a poveda\u0165, \u017ee virtu\u00e1lny port zdroja je rovnak\u00fd (moj\u00edm teaming policy), teda pre rovnak\u00fa vNIC by sa mal vybra\u0165 rovnak\u00fd uplink, ale ke\u010f\u017ee som na hoste, skontrolova\u0165 in\u00fd uplink nie je probl\u00e9m:<\/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
\nPrich\u00e1dzaj\u00fa po\u017eiadavky od fortigatu, ale odpovede niet. To znamen\u00e1, \u017ee probl\u00e9m nie je vo fortigate. No, v\u0161etko \u2014 mysl\u00edm si \u2014 zase ten ist\u00fd probl\u00e9m so zmiznut\u00edm prev\u00e1dzky na VDR, zase p\u00e1r mesiacov smerova\u0165 pr\u00edpad na spr\u00e1vnu cestu. Po p\u00e1r d\u0148och, ochladn\u00fac a nechc\u00fac sa zmieri\u0165 s visiacim stavom, som sa rozhodol nazhroma\u017edi\u0165 e\u0161te sniffy pre podporu, aby som ur\u00fdchlil proces. A tu sa \u201en\u00e1hodou\u201c m\u00f4j poh\u013ead zastav\u00ed na Ethernet inkapsul\u00e1cii underlay. C\u00e1r nie je prav\u00fd a MAC adresa VTEP nes\u00fahlas\u00ed s jeho IP. Resetujem na nulu, sniffujem, hrabem \u2014 spr\u00e1vne, \u017ee nie je. Prilo\u017e\u00edm ARP tabu\u013eku ved\u013ea, aby bolo pohodlnej\u0161ie porovn\u00e1va\u0165. V\u0161imnite si prv\u00fa Ethernet inkapsul\u00e1ciu na obr\u00e1zku hore:<\/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
\nA tak, \u010do m\u00e1me v kone\u010dnom d\u00f4sledku \u2014 po migr\u00e1cii virtu\u00e1lneho stroja sa fortigate sna\u017e\u00ed posla\u0165 prev\u00e1dzku na VTEP z (spr\u00e1vneho) VXLAN FDB, ale pou\u017e\u00edva nespr\u00e1vny DST MAC a prev\u00e1dzka logicky odmieta prij\u00edmaj\u00faci rozhran\u00ed hyperv\u00edzora. A\u017e v jednom pr\u00edpade z \u0161tyroch tento MAC patril p\u00f4vodn\u00e9mu hyperv\u00edzoru, z ktor\u00e9ho za\u010d\u00ednali migr\u00e1ciu stroja.<\/p>\n
V\u010dera som dostal e-mail od technickej podpory Fortinet \u2014 otvorili chybu 615586 na mojom pr\u00edpade. \u00daplne neviem, \u010di sa m\u00e1m te\u0161i\u0165 alebo sm\u00fati\u0165: z jednej strany \u2014 probl\u00e9m nie je v nastaveniach, z druhej \u2014 oprava pr\u00edde len s aktualiz\u00e1ciou firmv\u00e9ru, v tom lep\u0161om pr\u00edpade s nasleduj\u00facim. Ego mi tie\u017e povzbudzuje \u010fal\u0161ia chyba, ktor\u00fa som odhalil minul\u00fd mesiac, pravda, vtedy v HTML5 GUI vSphere. Tak presne lok\u00e1lny QA t\u00edm dod\u00e1vate\u013eov\u2026<\/p>\n
Rizkujem predpoklad, \u017ee nasleduj\u00face:<\/p>\n
1 \u2014 multicast ovl\u00e1dac\u00ed pl\u00e1n pravdepodobne nebude podlieha\u0165 op\u00edsan\u00e9mu probl\u00e9mu \u2014 ve\u010f MAC adresy VTEP sa z\u00edskavaj\u00fa z IP adresy skupiny, na ktor\u00fa je pripojen\u00e9 rozhranie. <\/p>\n
2 \u2014 pravdepodobne probl\u00e9m fortigatu v offloadovan\u00ed rel\u00e1ci\u00ed na Network Processor (pribli\u017ene anal\u00f3g CEF) \u2014 ak sa prech\u00e1dza ka\u017ed\u00fdm paketom cez CPU, bud\u00fa sa pou\u017e\u00edva\u0165 tabu\u013eky obsahuj\u00face spr\u00e1vne \u2014 aspo\u0148 vizu\u00e1lne \u2014 inform\u00e1cie. V prospech tohto predpokladu hovor\u00ed, \u017ee pom\u00e1ha zatv\u00e1ra\u0165\/otv\u00e1ra\u0165 rozhranie alebo \u010daka\u0165 nejak\u00fd \u010das \u2014 viac ako 5 min\u00fat. <\/p>\n
3 \u2014 zmena politiky t\u00edmovania, napr\u00edklad na explicit failover, alebo implement\u00e1cia LAG probl\u00e9m nevyrie\u0161i, preto\u017ee sa pozorovalo \u201ezaseknutie\u201c MAC p\u00f4vodn\u00e9ho hyperv\u00edzora v inkapsulovan\u00fdch paktoch.<\/p>\n
V svetle tohto m\u00f4\u017eem zdie\u013ea\u0165, \u017ee som ned\u00e1vno objavil blog<\/a><\/noindex>, kde v jednom z \u010dl\u00e1nkov sa tvrdilo, \u017ee stateful firewall a cacheovate\u013en\u00e9 met\u00f3dy prenosu d\u00e1t s\u00fa len barlami. Nu\u017e, nie som dostato\u010dne sk\u00fasen\u00fd v IT, aby som mohol tak\u00e9to nie\u010do tvrdi\u0165, navy\u0161e nie so v\u0161etk\u00fdmi tvrdeniami blogov\u00fdch \u010dl\u00e1nkov s\u00fahlas\u00edm hne\u010f. Av\u0161ak nie\u010do mi hovor\u00ed, \u017ee v slov\u00e1ch Ivana je ur\u010dit\u00e1 pravda.<\/p>\n
\u010eakujem za pozornos\u0165! Budem r\u00e1d odpoveda\u0165 na ot\u00e1zky a vypo\u010du\u0165 si kon\u0161trukt\u00edvnu kritiku.
\n
Zdroj: 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 v NSX-V \u2014 rie\u0161ime probl\u00e9my underlay | ProHoster","description":"V\u00edtam v\u00e1s a najsk\u00f4r trochu lyriky.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}