{"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\/pt\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN no NSX-V \u2014 solucionando problemas de underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sauda\u00e7\u00f5es, e primeiro um pouco de lirismo. \u00c0s vezes, eu tenho inveja dos colegas que trabalham remotamente \u2014 pois \u00e9 maravilhoso ter a possibilidade de trabalhar de qualquer lugar do mundo conectado \u00e0 Internet, f\u00e9rias a qualquer momento, responsabilidade por projetos e prazos, em vez de estar no escrit\u00f3rio das 8 \u00e0s 17. Minha posi\u00e7\u00e3o e responsabilidades de trabalho praticamente excluem a possibilidade de uma longa aus\u00eancia no data center. No entanto, ocasionalmente surgem casos interessantes, como o descrito abaixo \u2014 e eu entendo que existem poucas posi\u00e7\u00f5es onde h\u00e1 tanto espa\u00e7o para a express\u00e3o criativa do troubleshooter interno.
\n<\/a><\/noindex>
\nUma pequena observa\u00e7\u00e3o \u2014 no momento em que escrevo este artigo, o caso n\u00e3o est\u00e1 totalmente resolvido, mas considerando a velocidade de resposta dos fornecedores, a solu\u00e7\u00e3o completa pode levar meses, e eu gostaria de compartilhar minhas descobertas j\u00e1. Espero que, respeit\u00e1veis leitores, voc\u00eas me perdoem pela pressa. Mas chega de conversa \u2014 o que est\u00e1 acontecendo com o caso? <\/p>\n

Primeiro, uma introdu\u00e7\u00e3o: h\u00e1 uma empresa (onde trabalho como engenheiro de redes) que hospeda solu\u00e7\u00f5es de clientes na nuvem privada VMWare. A maioria das novas solu\u00e7\u00f5es \u00e9 conectada a segmentos VXLAN, que s\u00e3o gerenciados pelo NSX-V \u2014 n\u00e3o vou avaliar quanto tempo isso me poupou, em resumo \u2014 muito. Consegui at\u00e9 treinar colegas na configura\u00e7\u00e3o do NSX ESG, e pequenas solu\u00e7\u00f5es de clientes est\u00e3o sendo implantadas sem a minha participa\u00e7\u00e3o. Uma observa\u00e7\u00e3o importante \u2014 nosso plano de controle \u00e9 com replica\u00e7\u00e3o unicast. Os hipervisores est\u00e3o conectados de forma redundante por duas interfaces a diferentes switches f\u00edsicos Juniper QFX5100 (montados em Virtual Chassis) e com a pol\u00edtica de roteamento baseada na porta virtual de origem \u2014 isso para completar o quadro.<\/p>\n

As solu\u00e7\u00f5es de clientes s\u00e3o muito diversas: desde Windows IIS, onde todos os componentes do servidor web est\u00e3o instalados em uma \u00fanica m\u00e1quina, at\u00e9 solu\u00e7\u00f5es bastante grandes \u2014 como front-ends Apache balanceados por carga + LB MariaDB em Galera + servidores de compartilhamento, sincronizados atrav\u00e9s do GlusterFS. Praticamente cada servidor precisa ser monitorado separadamente, e nem todos os componentes t\u00eam endere\u00e7os p\u00fablicos \u2014 se voc\u00ea j\u00e1 enfrentou essa tarefa e tem uma solu\u00e7\u00e3o mais elegante, ficarei feliz com suas sugest\u00f5es.
\nA minha solu\u00e7\u00e3o de monitoramento consiste em \u00abconectar\u00bb o firewall (Fortigate) a cada rede interna do cliente (+SNAT e, claro, restri\u00e7\u00f5es r\u00edgidas quanto ao tipo de tr\u00e1fego permitido) e monitorar os endere\u00e7os internos \u2014 dessa forma, conseguimos uma certa unifica\u00e7\u00e3o e simplifica\u00e7\u00e3o do monitoramento. O monitoramento ocorre a partir de um cluster de servidores PRTG. O esquema de monitoramento \u00e9 aproximadamente assim:<\/p>\n

\"VXLAN
\n
\nEnquanto oper\u00e1vamos apenas com VLAN, tudo funcionava de forma bastante normal e previs\u00edvel, como um rel\u00f3gio. Ap\u00f3s a implementa\u00e7\u00e3o do NSX-V e VXLAN, nos deparamos com a quest\u00e3o \u2014 podemos continuar monitorando da maneira antiga? No momento em que esta pergunta surgiu, a solu\u00e7\u00e3o mais \u00abr\u00e1pida\u00bb era implantar o NSX ESG e conectar a interface trunk VXLAN na rede VTEP. R\u00e1pida entre aspas \u2014 pois usar a interface gr\u00e1fica para configurar redes de clientes, SNAT e regras de firewall pode unificar a gest\u00e3o em uma \u00fanica interface vSphere, mas, na minha opini\u00e3o, \u00e9 bastante pesada e, al\u00e9m disso, limita o conjunto de ferramentas para solu\u00e7\u00e3o de problemas. Aqueles que usaram o NSX ESG como substituto de um firewall \u00abreal\u00bb, creio que concordar\u00e3o. Embora, provavelmente, essa solu\u00e7\u00e3o seria mais est\u00e1vel \u2014 afinal, tudo acontece dentro de um \u00fanico fornecedor.<\/p>\n

Uma outra solu\u00e7\u00e3o \u00e9 usar o NSX DLR no modo bridge entre VLAN e VXLAN. Aqui acredito que tudo esteja claro \u2014 a vantagem da aplica\u00e7\u00e3o de VXLAN se perde, uma vez que ainda \u00e9 necess\u00e1rio puxar a VLAN para a instala\u00e7\u00e3o de monitoramento. A prop\u00f3sito, durante o desenvolvimento dessa solu\u00e7\u00e3o, enfrentei o problema em que o DLR-bridge n\u00e3o enviava pacotes para a VM com a qual estava no mesmo host. Eu sei, eu sei \u2014 nos livros e guias sobre NSX-V, est\u00e1 claramente mencionado que um cluster separado deve ser alocado para o NSX Edge, mas isso est\u00e1 nos livros... De qualquer forma, ap\u00f3s alguns meses com o suporte, n\u00e3o conseguimos resolver o problema. Em princ\u00edpio, entendi a l\u00f3gica do funcionamento \u2014 o m\u00f3dulo do kernel do hypervisor respons\u00e1vel pela encapsula\u00e7\u00e3o de VXLAN n\u00e3o era ativado quando o DLR e o servidor monitorado estavam no mesmo host, pois o tr\u00e1fego n\u00e3o sa\u00eda do host e, logicamente, deveria estar conectado ao segmento VXLAN \u2014 a encapsula\u00e7\u00e3o n\u00e3o \u00e9 necess\u00e1ria. Com o suporte, nos concentramos na interface virtual vdrPort, que logicamente une os uplinks e tamb\u00e9m realiza o bridging\/encapsula\u00e7\u00e3o \u2014 foi l\u00e1 que notamos a discrep\u00e2ncia no tr\u00e1fego de entrada, que tomei como foco para resolver nesse caso atual. Mas, como foi dito, n\u00e3o finalizei esse caso, pois fui transferido para outro projeto e essa ramifica\u00e7\u00e3o era originalmente sem sa\u00edda e n\u00e3o havia muita vontade de desenvolv\u00ea-la. Se n\u00e3o me engano, o problema foi observado nas vers\u00f5es NSX 6.1.4 e 6.2. <\/p>\n

E aqui \u2014 bingo! A Fortinet anuncia suporte nativo para VXLAN<\/a><\/noindex>. E n\u00e3o apenas point-to-point ou VXLAN-over-IPSec, e sim o bridging de VLAN-VXLAN \u2014 tudo isso come\u00e7ou a ser implementado desde a vers\u00e3o 5.4 (e apresentado por outros fornecedores<\/a><\/noindex>), e o verdadeiro suporte ao controle de plano unicast. Ao implementar a solu\u00e7\u00e3o, encontrei mais um problema \u2014 os servidores monitorados periodicamente \u201cdesapareciam\u201d e apareciam no monitoramento, embora a pr\u00f3pria VM estivesse viva. A causa, como se revelou, era que eu havia esquecido de permitir Ping na interface VXLAN. Durante o processo de reequil\u00edbrio dos clusters, as VMs eram movidas, e o Ping finalizava o vMotion, para indicar o novo host ESXI ao qual a m\u00e1quina havia sido movida. Foi uma tolice minha, mas esse problema mais uma vez abalou a confian\u00e7a no suporte do fabricante \u2014 neste caso, Fortinet. N\u00e3o quero nem mencionar que cada caso relacionado a VXLAN come\u00e7a com a pergunta \u201conde est\u00e3o suas configura\u00e7\u00f5es de softswitch VLAN-VXLAN?\u201d Desta vez, me recomendaram alterar o MTU \u2014 isso para o Ping, que \u00e9 de 32 bytes. Depois \u201cbrinque\u201d com tcp-send-mss e tcp-receive-mss na pol\u00edtica \u2014 para VXLAN, que \u00e9 encapsulado em UDP. Ufa, desculpe \u2014 precisava desabafar. Enfim, resolvi esse problema por conta pr\u00f3pria. <\/p>\n

Ap\u00f3s passar pelo tr\u00e1fego de teste, decidimos implementar essa solu\u00e7\u00e3o. E em produ\u00e7\u00e3o, descobrimos que, ap\u00f3s um ou dois dias, tudo que era monitorado via VXLAN gradualmente parava de funcionar. A desativa\u00e7\u00e3o\/reativa\u00e7\u00e3o da interface ajudava, mas apenas por um tempo. Lembrando da lentid\u00e3o do suporte do fabricante, fui eu mesmo que comecei a resolver o problema \u2014 afinal, minha empresa, minha rede \u2014 minha responsabilidade. <\/p>\n

Abaixo, o progresso da solu\u00e7\u00e3o de problemas. Quem est\u00e1 cansado de letras e fanfarronices \u2014 pode pular e ir direto para a an\u00e1lise p\u00f3s-implementa\u00e7\u00e3o.<\/p>\n

Progresso da solu\u00e7\u00e3o de problemas<\/b>Obrigado por continuar a leitura \u2014 vamos em frente!<\/p>\n

Ent\u00e3o, o monitoramento funciona por algum tempo, depois para por conta pr\u00f3pria. Isso significa que provavelmente n\u00e3o h\u00e1 problemas nas pol\u00edticas do firewall. No entanto, como j\u00e1 enfrentei problemas com processos de sistema travados no Fortigate vers\u00f5es 5.6+, primeiro conferimos o \"diagnose debug flow\" \u2014 como esperado, o tr\u00e1fego \u00e9 permitido e sai pela interface, e nada volta em resposta. Portanto, temos que investigar mais a fundo. Infelizmente, terei que ocultar endere\u00e7os, mesmo que sejam RFC1918, mas espero fornecer informa\u00e7\u00f5es suficientes para entendimento. O servidor dentro do VXLAN tem o endere\u00e7o x.x.x.15, a interface do Fortigate x.x.x.254, todos os outros endere\u00e7os pertencem \u00e0 rede VTEP.<\/p>\n

Para a transmiss\u00e3o bem-sucedida de pacotes encapsulados em VXLAN, \u00e9 necess\u00e1rio ter informa\u00e7\u00f5es corretas em v\u00e1rias tabelas. Para o overlay, isso \u00e9 ARP e OVSDB, e para o underlay, \u00e9 ARP e CAM. No caso do Fortigate, VXLAN FDB \u00e9 OVSDB. Vamos come\u00e7ar por a\u00ed:<\/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
\nAqui tudo \u00e9 bastante simples \u2014 o endere\u00e7o MAC da VM deve estar no VTEP com o endere\u00e7o \u0443.\u0443.\u0443.47. Ao olhar o conte\u00fado e as configura\u00e7\u00f5es do cluster ESXI, encontro que o MAC da VM est\u00e1 correto, e o endere\u00e7o do VTEP tamb\u00e9m. Verifico a tabela CAM\/ARP no FortiGate \u2014 tudo confere com as configura\u00e7\u00f5es do host ESXI:<\/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
\nAs tabelas est\u00e3o corretas e o tr\u00e1fego est\u00e1 fluindo \u2014 talvez o problema n\u00e3o esteja no Fortigate? Eu intencionalmente deixei de lado a an\u00e1lise da comuta\u00e7\u00e3o de tr\u00e1fego no Juniper \u2014 logicamente, esse deve ser o pr\u00f3ximo passo de troubleshooting, mas minha rede \u00e9 simples \u2014 apenas um VLAN para VTEP e todos os componentes est\u00e3o conectados diretamente. Al\u00e9m disso, lembro de um caso com o ponte DLR, VDR e tr\u00e1fego desaparecendo \u2014 vou capturar pacotes no host ESXI, ao mesmo tempo que crio um caso j\u00e1 com a VMWare. Abaixo, o MAC \u201c97:6e\u201d pertence ao Forti, vmnic1 \u2014 \u00e9 a interface que possui VTEP com o endere\u00e7o X.X.X.47, capturando em ambas as dire\u00e7\u00f5es \"\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
\nProgresso \u2014 no monitoramento vejo a solicita\u00e7\u00e3o ARP e a resposta recebida. Apresento apenas a resposta ARP e est\u00e1 tudo correto. N\u00e3o mencionei, mas durante todo esse tempo, o servidor de monitoramento est\u00e1 pingando o endere\u00e7o \u0445.\u0445.\u0445.15 \u2014 onde est\u00e1 o tr\u00e1fego ICMP? Lembro que tenho dois uplinks. Aqui pode-se argumentar que a porta virtual do fonte \u00e9 a mesma (minha pol\u00edtica de team), ou seja, para o mesmo vNIC deve ser escolhido o mesmo uplink, mas j\u00e1 que estou no host, verificar outro uplink n\u00e3o \u00e9 problema:<\/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
\nEst\u00e3o chegando solicita\u00e7\u00f5es do Fortigate, mas n\u00e3o h\u00e1 resposta. Ou seja, o problema n\u00e3o est\u00e1 no Fortigate. Bom, acho que novamente estou enfrentando o mesmo problema de tr\u00e1fego desaparecendo no VDR, e novamente terei que direcionar o caso na dire\u00e7\u00e3o certa por alguns meses. Ap\u00f3s alguns dias de reflex\u00e3o e n\u00e3o querendo aceitar a situa\u00e7\u00e3o pendente, decidi coletar mais pacotes de sniffer para o suporte, a fim de acelerar o processo. E aqui, por 'acaso', meu olhar cai na encapsula\u00e7\u00e3o Ethernet underlay. O rei n\u00e3o \u00e9 verdadeiro e o endere\u00e7o MAC do VTEP n\u00e3o corresponde ao seu IP. Zerei, fiz sniffer, investiguei \u2014 era verdade, mas n\u00e3o era. Apresentarei a tabela ARP ao lado para facilitar a compara\u00e7\u00e3o. Observe a primeira encapsula\u00e7\u00e3o Ethernet na imagem acima:<\/p>\n
fortigate (root) #get sys arp | grep 0.0.0.47\n0.0.0.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep 0.0.0.42\n0.0.0.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nEnt\u00e3o, o que temos no final \u2014 ap\u00f3s a migra\u00e7\u00e3o da m\u00e1quina virtual, o Fortigate tenta enviar tr\u00e1fego para o VTEP a partir do (correto) VXLAN FDB, mas usa o MAC DST incorreto, e o tr\u00e1fego \u00e9, como esperado, descartado pela interface receptora do hipervisor. Em um dos quatro casos, esse MAC pertencia ao hipervisor original, de onde a migra\u00e7\u00e3o da m\u00e1quina come\u00e7ou.<\/p>\n
Recebi ontem um e-mail do suporte t\u00e9cnico da Fortinet \u2014 abriram um bug 615586 sobre o meu caso. N\u00e3o sei se fico feliz ou triste: por um lado, o problema n\u00e3o est\u00e1 nas configura\u00e7\u00f5es; por outro lado, a corre\u00e7\u00e3o vir\u00e1 apenas com a atualiza\u00e7\u00e3o do firmware, provavelmente na pr\u00f3xima vers\u00e3o. Meu ego \u00e9 aquecido por mais um bug que identifiquei no m\u00eas passado, embora desta vez na GUI HTML5 do vSphere. \u00c9 quase como um departamento de QA local dos fornecedores...<\/p>\n
Arrisco-me a supor o seguinte:<\/p>\n
1 \u2014 o plano de controle multicast provavelmente n\u00e3o ser\u00e1 suscet\u00edvel ao problema descrito \u2014 pois os endere\u00e7os MAC do VTEP s\u00e3o obtidos a partir do endere\u00e7o IP do grupo ao qual a interface est\u00e1 assinada. <\/p>\n
2 \u2014 o problema com o Fortigate provavelmente est\u00e1 no descarregamento de sess\u00f5es no Processador de Rede (aproximadamente an\u00e1logo ao CEF) \u2014 se todos os pacotes forem processados pelo CPU, ser\u00e3o utilizadas tabelas contendo informa\u00e7\u00f5es corretas \u2014 pelo menos visualmente. A favor dessa suposi\u00e7\u00e3o est\u00e1 o fato de que ajudar a fechar\/abrir a interface ou esperar um certo tempo \u2014 mais de 5 minutos \u2014 realmente ajuda. <\/p>\n
3 \u2014 a altera\u00e7\u00e3o da pol\u00edtica de agrupamento, por exemplo, para failover expl\u00edcito, ou a implementa\u00e7\u00e3o de LAG n\u00e3o resolver\u00e1 o problema, j\u00e1 que observei o 'emperramento' do MAC do hipervisor original em pacotes encapsulados.<\/p>\n
\u00c0 luz disso, posso compartilhar que recentemente descobri blog<\/a><\/noindex>, onde um dos artigos afirmava que firewalls stateful e m\u00e9todos de transmiss\u00e3o de dados em cache s\u00e3o solu\u00e7\u00f5es improvisadas. Bem, n\u00e3o sou t\u00e3o experiente em TI para fazer tal afirma\u00e7\u00e3o, al\u00e9m disso, n\u00e3o concordo de imediato com todas as afirma\u00e7\u00f5es dos artigos do blog. No entanto, algo me diz que h\u00e1 uma certa verdade nas palavras do Ivan.<\/p>\n
Agrade\u00e7o pela aten\u00e7\u00e3o! Ficarei feliz em responder a perguntas e ouvir cr\u00edticas construtivas.
\n
Fonte: 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 no NSX-V \u2014 solucionando problemas de underlay | ProHoster","description":"Sauda\u00e7\u00f5es, e primeiro um pouco de poesia.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}