O VMware NSX-T (agora parte da suite VMware Aria) introduziu uma arquitetura de roteamento distribuído e encapsulamento de rede que, embora robusta, exige diagnósticos precisos. Quando problemas de conectividade surgem em ambientes virtualizados, a camada de overlay é frequentemente o ponto crítico. Tunnels VTEP (Virtual Tunnel End Points) mal estabelecidos ou falhas na comunicação entre os hypervisors podem paralisar a comunicação entre VMs em diferentes subnets físicas.
Este tutorial guia sysadmins e engenheiros de rede através do processo sistemático de troubleshooting de túneis e overlays no NSX-T Data Center. O foco está na verificação da integridade dos transport nodes, análise do estado das conexões encapsuladas e validação da rota até o plano de controle.
1. Verificação do Estado dos Transport Nodes
O primeiro passo para diagnosticar problemas de overlay é garantir que os componentes de transporte nos hypervisors (ESXi, KVM ou Windows Server) estejam operacionais e registrados corretamente no cluster de gerenciamento. Cada host atua como um VTEP, encapsulando o tráfego de camada 2/3 dentro de pacotes UDP para traversar a rede física (Underlay).
Para verificar o status geral dos transport nodes conectados ao cluster, utilize a API REST ou a CLI do NSX Manager. Através da interface de linha de comando no próprio NSX Manager, execute o seguinte comando para listar todos os transport nodes e seus estados:
get transport nodeA saída retornará uma lista detalhada. Observe especialmente as colunas State e Uplink Status. Um transport node com estado CONNECTED indica que a comunicação básica com o NSX Manager foi estabelecida. Se o status for DISCONNECTED, o problema pode estar na conectividade de gerenciamento ou nas credenciais do host.
Além disso, verifique se os transport nodes estão atribuídos corretamente aos segmentos de transporte (Transport Zones). Um erro comum é tentar comunicar VMs através de um overlay que não está habilitado no Transport Zone associado ao transport node de origem ou destino.
get transport zoneCertifique-se de que o Transport Zone ID listado nas configurações do transport node corresponde à zona onde os segmentos de rede virtuais (Logical Switches) residem.
2. Análise das Conexões VTEP e Tunnels
Com os transport nodes confirmados como conectados, o próximo passo é investigar a camada de overlay propriamente dita. O NSX-T utiliza túneis VXLAN para encapsular o tráfego. Cada par de transport nodes que precisa se comunicar estabelece um túnel ponto-a-ponto.
Para visualizar o estado dos túneis ativos em um transport node específico, utilize o comando:
get transport node tunnel-statusA saída mostrará uma tabela com os endereços IP dos VTEPs remotos e o estado da conexão. Os estados possíveis incluem:
- UP: O túnel está estabelecido e operante.
- DYNAMIC: O túnel foi criado dinamicamente via BGP ou OSPF (no caso de roteamento).
- DOWN: A conexão falhou. Isso pode ser devido a bloqueios de firewall, problemas de roteamento no underlay ou divergência de MTU.
Se você identificar túneis em estado DOWN, anote o endereço IP do VTEP remoto. Isso indica que o transport node local não consegue alcançar o peer remoto na rede física ou que o handshake VXLAN falhou.
3. Diagnóstico de Conectividade Underlay (IP Route)
O overlay depende inteiramente da integridade do underlay. Se os roteadores físicos não tiverem rotas para os endereços IP dos VTEPs, os túneis VXLAN nunca serão estabelecidos. O protocolo de encapsulamento VXLAN utiliza a porta UDP 4789.
Primeiro, verifique se o roteamento está correto na rede física. No NSX-T, recomenda-se o uso de ECMP (Equal-Cost Multi-Path) para balanceamento de carga e resiliência. Para validar as rotas aprendidas pelo plano de controle do NSX em relação aos switches de spine/leaf, consulte as configurações de BGP ou OSPF.
No entanto, uma verificação rápida pode ser feita diretamente dos transport nodes. Acesse a console do host ESXi (ESXi Shell) e realize um ping para o endereço IP VTEP do peer remoto:
ping -I vif0 -c 5 <IP_VTEP_REMOTO>O uso da interface vif0 é crucial, pois ela representa a uplink de gerenciamento/transporte do host. Se o ping falhar, o problema é de infraestrutura física (roteamento, firewall ou switch physical). Se o ping for bem-sucedido, o problema provavelmente reside na configuração do NSX ou no encapsulamento.
4. Verificação de MTU e Fragmentação
Um dos erros mais silenciosos em ambientes de overlay é a inconsistência de MTU (Maximum Transmission Unit). O encapsulamento VXLAN adiciona overhead ao pacote original: 14 bytes de cabeçalho Ethernet, 20 de IP, 8 de UDP e 50 de VXLAN, totalizando cerca de 92 bytes de overhead adicional. Portanto, se a rede física tiver MTU padrão de 1500 bytes, pacotes maiores que ~1400 bytes dentro do overlay serão fragmentados ou descartados.
O NSX-T recomenda fortemente o uso de Jumbo Frames (MTU 9000) em toda a cadeia de transporte (VMs, Hypervisors, Switches Físicos e Roteadores). Se o MTU não estiver configurado uniformemente, os túneis podem parecer ativos, mas o tráfego de dados será perdido.
Para verificar o MTU configurado nos transport nodes via API:
get transport node <transport_node_id> | grep mtuAlém disso, verifique as configurações dos switches físicos. Certifique-se de que todas as portas conectadas aos hosts ESXi estejam configuradas para MTU 9000 (ou o valor definido no seu padrão corporativo). Uma discrepância mesmo em um único switch na ponta do link pode causar intermitência severa.
5. Validação da Rota de Controle e Plano de Dados
O NSX-T possui dois planos distintos: o Plano de Controle (Control Plane) e o Plano de Dados (Data Plane). O Plano de Controle gerencia a distribuição de informações de roteamento e segurança entre o NSX Manager, os Controllers e os Transport Nodes. O Plano de Dados é onde o tráfego real flui encapsulado.
Se os túneis estão UP, mas as VMs não se comunicam, o problema pode estar na distribuição de rotas ou regras de segurança.
5.1 Verificação do Estado dos Controllers
Os nós de controle (Control Cluster) são responsáveis por distribuir as tabelas de roteamento para os transport nodes. Se eles estiverem desatualizados, o encaminhamento falhará.
get controller cluster statusTodos os nós do cluster de controle devem estar em estado CONNECTED. Verifique também a sincronização:
get controller node <node_id> | grep sync_status5.2 Análise de Regras de Segurança (Security Groups)
Muitas vezes, o que parece ser um problema de túnel é, na verdade, uma regra de Firewall Distributed bloqueando o tráfego. O NSX-T aplica regras de segurança no nível do vNIC da VM.
Para diagnosticar se o pacote está sendo descartado por segurança, ative o logging das regras de firewall e verifique os logs do transport node:
get security policy logSe você não vir entradas de log indicando DROP, mas ainda assim há perda de pacotes, investigue as tabelas de roteamento distribuído (DR).
6. Coleta de Logs e Diagnóstico Avançado com tcpdump
Quando os comandos padrão não revelam a causa raiz, a captura de tráfego é a ferramenta definitiva. No entanto, capturar no ambiente virtualizado requer cuidado para não sobrecarregar o sistema.
6.1 Captura nos Transport Nodes
No host ESXi, você pode usar o tcpdump para analisar o tráfego VXLAN. Identifique a uplink de transporte (geralmente vmk3 ou uma porta física específica configurada como uplink de transporte).
tcpdump -i <uplink_transport> udp port 4789 -w /tmp/vxlan_capture.pcapAnalisando o arquivo .pcap resultante em uma estação de trabalho com Wireshark, você deve observar:
- Pacotes UDP na porta 4789.
- Dentro do encapsulamento VXLAN, o tráfego original (ARP, ICMP, TCP).
- Se houver pacotes sendo retransmitidos ou com erros de checksum, há um problema físico ou de driver.
6.2 Logs do NSX Manager
O NSX Manager centraliza os logs de configuração e eventos críticos. Para filtrar erros relacionados a túneis:
get log messages | grep tunnelProcure por mensagens de erro como Tunnel endpoint unreachable ou BGP session down. Esses logs fornecem o contexto exato do momento em que a falha ocorreu.
7. Restabelecimento e Recuperação
Após identificar a causa raiz, os passos de recuperação podem variar:
- Problema de Roteamento Underlay: Corrija as rotas estáticas ou dinâmicas (BGP/OSPF) nos switches físicos e roteadores.
- Problema de MTU: Ajuste o MTU nas interfaces de uplink dos transport nodes via NSX Manager e sincronize com a rede física.
- Túneis Corrompidos: Em casos raros, reiniciar o serviço de transporte no host pode ajudar. No ESXi, isso pode ser feito via vCenter ou diretamente no shell, mas requer cuidado para não desconectar múltiplas VMs simultaneamente em produção.
Para reiniciar o serviço de transporte do NSX em um transport node específico:
restart service nsx-transportApós a reinicialização, monitore o status dos túneis novamente com get transport node tunnel-status para confirmar que as conexões estão sendo restabelecidas.
8. Boas Práticas de Prevenção
Para minimizar incidentes futuros em tunnels e overlays, adote as seguintes práticas:
- Monitoramento Contínuo: Utilize ferramentas como vRealize Network Insight (VRNI) ou soluções de monitoramento externas para alertar sobre a queda de túneis VTEP antes que impactem os usuários finais.
- Validação de Mudanças: Antes de alterar configurações de roteamento no underlay, simule o impacto nos endereços IP dos VTEPs. Qualquer mudança no IP do host ou na rota padrão pode quebrar o overlay.
- Documentação de Topologia: Mantenha um mapeamento claro de quais Transport Zones estão associados a quais clusters e hosts. A desalocação acidental de um host de um Transport Zone é uma causa comum de isolamento de VMs.
O troubleshooting de NSX-T exige uma mentalidade binária: o problema está no Underlay (físico) ou no Overlay (virtual)? Ao isolar essas camadas através dos comandos apresentados, você reduz significativamente o tempo médio de resolução (MTTR) e garante a estabilidade da sua infraestrutura virtualizada.
Lembre-se sempre de realizar testes de conectividade ping e traceroute entre as VMs após qualquer alteração para validar a integridade do fluxo de dados encapsulado. A visibilidade completa, desde o cabeçalho Ethernet até o payload da aplicação, é essencial para manter a performance prometida pelo VMware Aria.