📫 📳 🏑 VXLAN no NSX-V - Underlay problemático 👩‍💼 🏭 🙎🏿

Saudações e primeiro uma pequena letra. Às vezes, invejo colegas que trabalham remotamente - é ótimo poder trabalhar em qualquer lugar do mundo conectado à Internet, férias a qualquer momento, responsabilidade por projetos e prazos, e não estar no escritório das 8 às 17. Minha posição e responsabilidades de trabalho praticamente excluem a possibilidade de uma longa ausência no data center. No entanto, casos interessantes como o descrito abaixo acontecem ocasionalmente, e eu entendo que existem poucas posições em que existe esse espaço para a expressão criativa de um solucionador de problemas interno.

Um pequeno aviso - no momento em que este artigo foi escrito, o caso não foi completamente resolvido, mas, dada a velocidade da resposta dos fornecedores, uma solução completa pode demorar mais meses e quero compartilhar minhas descobertas agora. Espero, queridos leitores, que você me perdoe essa pressa. Mas água suficiente - e o caso?

Primeiro introdutório: existe uma empresa (onde trabalho como engenheiro de rede) que hospeda soluções de clientes na nuvem privada do VMWare. A maioria das novas soluções se conecta aos segmentos VXLAN controlados pelo NSX-V - não vou avaliar quanto tempo essa solução me deu, enfim - muito. Consegui até treinar meus colegas para configurar o NSX ESG e as soluções para pequenos clientes são implantadas sem a minha participação. Uma observação importante é o plano de controle com replicação unicast. Os hypervisores são redundantemente conectados por duas interfaces a comutadores Juniper QFX5100 físicos diferentes (montados no chassi virtual) e a rota da política de temporização baseada na porta virtual de origem é completa.

As soluções de clientes são muito diversas: do Windows IIS, onde todos os componentes do servidor da Web são instalados em uma máquina, até os bastante grandes - por exemplo, frentes da Web Apache com balanceamento de carga + LB MariaDB no Galera + balões de servidor sincronizados usando o GlusterFS. Quase todos os servidores precisam ser monitorados separadamente, e nem todos os componentes têm endereços públicos - se você encontrou esse problema e tem uma solução mais elegante, terei o maior prazer em aconselhá-lo.
Minha solução de monitoramento consiste em "conectar" o firewall (Fortigate) a cada rede interna do cliente (+ SNAT e, é claro, restrições estritas ao tipo de tráfego permitido) e monitorar os endereços internos - dessa forma, é alcançada uma certa unificação e simplificação do monitoramento. O próprio monitoramento vem de um cluster de servidores PRTG. O esquema de monitoramento é algo como isto:

imagem

Enquanto operávamos apenas com VLAN, tudo era bastante usual e previsivelmente funcionava como um relógio. Após a implementação, o NSX-V e o VXLAN enfrentaram a questão - é possível continuar monitorando da maneira antiga? No momento desta pergunta, a solução mais rápida era implantar o NSX ESG e conectar a interface de tronco VXLAN à rede VTEP. Cotações rápidas - como o uso da GUI para configurar redes de clientes, as regras do SNAT e do firewall podem e unificam o gerenciamento em uma única interface do vSphere, mas, na minha opinião, é bastante complicado e, entre outras coisas, limita o conjunto de ferramentas para solução de problemas. Aqueles que usaram o NSX ESG como substituto de um firewall "real", eu acho, concordariam. Embora, provavelmente, essa solução seja mais estável - afinal, tudo acontece dentro da estrutura de um fornecedor.

Outra solução é usar o NSX DLR no modo de ponte entre VLAN e VXLAN. Aqui, acho que tudo está claro - o benefício do uso da VXLAN é brega - porque, nesse caso, você ainda precisa puxar a VLAN para a instalação de monitoramento. A propósito, no processo de solução dessa solução, tive um problema quando a ponte DLR não enviou pacotes para a máquina virtual com a qual estava no mesmo host. Eu sei, eu sei - nos livros e guias do NSX-V, é explicitamente declarado que um cluster separado deve ser alocado para o NSX Edge, mas isso está nos livros ... Enfim, depois de alguns meses com suporte, não resolvemos o problema. Em princípio, entendi a lógica da ação - o módulo principal do hipervisor responsável pelo encapsulamento de VXLAN não era ativado se o DLR e o servidor monitorado estivessem no mesmo host, pois o tráfego não sai do host e, logicamente, ele deve ser conectado ao segmento VXLAN - o encapsulamento não é necessário.Com o suporte, decidimos pela interface virtual vdrPort, que combina logicamente uplinks e também realiza ponte / encapsulamento - foi notada uma incompatibilidade no tráfego de entrada, que levei para resolver no caso atual. Mas, como foi dito, não terminei esse caso até o final, pois ele foi transferido para outro projeto e o ramo era inicialmente um beco sem saída e não havia nenhum desejo específico de desenvolvê-lo. Se não me engano, o problema foi observado nas versões NSX e 6.1.4 e 6.2.desde que foi transferido para outro projeto e a filial estava inicialmente sem saída e não havia nenhum desejo específico de desenvolvê-lo. Se não me engano, o problema foi observado nas versões NSX e 6.1.4 e 6.2.desde que foi transferido para outro projeto e a filial estava inicialmente sem saída e não havia nenhum desejo particular de desenvolvê-lo. Se não me engano, o problema foi observado nas versões NSX e 6.1.4 e 6.2.

E aqui - bingo! Suporte nativo Fortinet annonsiruet VXLAN . E não apenas ponto a ponto ou VXLAN sobre IPSec, não ponte de VLAN-VXLAN baseada em software - eles começaram a implementar tudo isso desde a versão 5.4 (e apresentada por outros fornecedores)), mas suporte real para o plano de controle unicast. Ao implementar a solução, encontrei outro problema - os servidores verificados “desapareciam” periodicamente e às vezes apareciam no monitoramento, embora a própria máquina virtual ainda estivesse viva. O motivo foi que eu esqueci de ativar o Ping na interface VXLAN. No processo de reequilibrar os clusters, as máquinas virtuais foram movidas e o vMotion terminou com Ping para indicar o novo host ESXI para o qual a máquina foi movida. Minha estupidez, mas esse problema mais uma vez minou a credibilidade do apoio foi produzido - neste caso, o Fortinet. Não estou dizendo que cada caso relacionado ao VXLAN começa com a pergunta "onde está o softswitch VLAN-VXLAN nas suas configurações?" Desta vez, fui aconselhado a alterar o MTU - isto é para Ping, que é de 32 bytes. Em seguida, "brinque" com tcp-send-mss e tcp-receive-mss na política - para VXLAN,que é encapsulado em UDP. Desculpe, está fervendo. Em geral, resolvi esse problema sozinho.

Tendo revertido com êxito o tráfego de teste, decidiu-se implementar esta solução. E na produção, descobriu-se que, depois de um dia ou dois, tudo o que é monitorado via VXLAN gradualmente cai completamente. Desativar / ativar a interface ajudou, mas apenas temporariamente. Atento ao suporte lento, fui procurar a solução de problemas da minha parte - no final, minha empresa, minha rede é minha responsabilidade.

Sob o spoiler, está o curso da solução de problemas. Quem está cansado de cartas e se gabar - pule e vá para a pós-análise.

Solução de problemas

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

Então, o que temos no final - após a migração da máquina virtual, o Fortigate tenta enviar tráfego para VTEP do (correto) VXLAN FDB, mas usa o MAC DST errado e o tráfego deve ser descartado pela interface do hipervisor de recebimento. Além disso, em um caso em cada quatro, esse MAC pertencia ao hypervisor original, a partir do qual a migração da máquina começou.

Ontem recebi uma carta do suporte técnico da Fortinet - no meu caso, eles abriram o bug 615586. Não sei me alegrar ou lamentar: por um lado, o problema não está nas configurações, por outro, a correção virá apenas com a atualização do firmware, na melhor das hipóteses a seguir. As perguntas frequentes também esquentam outro bug que descobri no mês passado, embora na época na GUI do HTML5 vSphere. Bem, o departamento local de controle de qualidade dos fornecedores é direto.

Atrevo-me a sugerir o seguinte:

1 - o plano de controle multicast provavelmente não será afetado pelo problema descrito - afinal, os endereços MAC VTEP são obtidos a partir do endereço IP do grupo no qual a interface está assinada.

2 - provavelmente o problema de fortics em sessões de descarregamento no Network Processor (aproximadamente análogo ao CEF) - se cada pacote for passado pela CPU, serão utilizadas tabelas contendo as informações corretas - pelo menos visualmente. A favor dessa suposição, é o que ajuda a fechar / abrir a interface ou esperar um pouco - mais de 5 minutos.

3 - alterar a política de formação de equipes, por exemplo, para failover explícito, ou a introdução do LAG não resolverá o problema, pois foi observado o MAC preso no hipervisor original em pacotes encapsulados.

Diante disso, posso compartilhar o que descobri recentemente em um blogonde, em um dos artigos, foi declarado que firewalls e métodos de transferência de dados em cache são muletas. Bem, eu não sou tão experiente em TI para dizer isso e não concordo com todas as declarações dos artigos do blog. No entanto, algo me diz que há alguma verdade nas palavras de Ivan.

Obrigado pela atenção! Ficarei feliz em responder a perguntas e ouvir críticas construtivas.

VXLAN no NSX-V - Underlay problemático

More articles: