Perda de conectividade com máquinas VLan e VSphere

Perda de conectividade com máquinas VLan e VSphere

Estou enfrentando uma situação muito estranha com algumas máquinas virtuais na configuração do meu vSphere e não consigo entender o que está acontecendo.

Originalmente estou trabalhando com uma 192.168.9.0/24rede onde 192.168.9.254está o servidor DHCP, 192.168.9.43é o gateway, 192.168.9.82é a minha estação de trabalho (recebeu seu IP do servidor DHCP) e 192.168.9.15é a do meu colega.
Isso funciona muito bem e todas as máquinas dessa rede podem trabalhar com as outras, todas elas são capazes de fazer ping entre si e com o resto do mundo através do gateway.

Um cluster VSphere 6.5 foi instalado, com três hosts que possuem endereços estáticos e 192.168.9.1, respectivamente. Essas máquinas estão executando o ESXi versão 6.0.0, 3380124 e cada uma tem quatro NICs conectadas a um par de switches Dell N1524 empilhados, sendo os switches conectados à rede. Nesse cluster, há uma rede vinculada às NICs de cada host e, portanto, as VMs obtêm seus IPs do DHCP. Isso também funciona bem, mas como houve um aumento no uso de VMs, o intervalo de IP servido pelo servidor DHCP agora está bastante lotado, a ponto de alguns usuários regulares não conseguirem obter um endereço IP se chegarem ao servidor DHCP. tarde.192.168.9.2192.168.9.3192.168.9.0/24Production192.168.9.254

Para evitar isso, adicionei um novo grupo de portas no vSwitch para cada host e dei a esses grupos de portas o mesmo nome ( VLAN) e o mesmo valor de VLAN, sendo 42.
Os switches físicos da Dell foram reconfigurados para permitir essa VLAN junto com o padrão um nas portas onde as NICs dos hosts estão conectadas (modo tronco). Decidi que essa VLAN seria uma 10.10.10.0/24rede para que fosse facilmente reconhecível na rede normal e, assim, dei ao switch o 10.10.10.252IP estático dessa VLAN.

Em seguida, criei uma máquina virtual Windows 2012 que possui duas interfaces, uma em Production(192.168.9.110), uma em VLAN( 10.10.10.254) e ativei a função RRAS para que esta máquina agora atue como gateway entre 10.10.10.0/24e o resto do mundo.
Criei uma segunda máquina virtual Windows 2012 que possui apenas uma interface, VLANcom o 10.10.10.253endereço estático e nomeei-a MDC. Ativei as funções de Controlador de Domínio, DHCP e DNS. O DHCP atende concessões no 10.10.10.50 - 10.10.10.200intervalo enquanto o DNS simplesmente encaminha para o DNS da 192.168.9.0/24rede

Em seguida, criei duas máquinas virtuais, uma no primeiro host, junto com o MDC e o Gateway, e uma no terceiro host, ambas conectadas à VLANrede. Como a conectividade parecia funcionar corretamente, decidi mover as VMs existentes da Temporarypasta para a VLANrede, usando este comando PowerCLI:

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -NetworkName VLAN

Aproveitei também para ter certeza de que todos os adaptadores de rede estão vmxnet3com esse comando

Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -Type vmxnet3

Como a conectividade ainda estava boa, criei outro conjunto de máquinas virtuais, também conectadas à VLANrede, colocadas nos três hosts, o que dá a seguinte topologia:

Anfitrião 1
MDC ( 10.10.10.253)
Gateway ( 10.10.10.254192.168.9.110)
Máquina1_H1 ( 10.10.10.64)
Máquina2_H1 ( 10.10.10.57)

Anfitrião 2
Máquina3_H2 ( 10.10.10.65)

Anfitrião 3
Máquina4_H3 ( 10.10.10.50)
Máquina5_H3 ( 10.10.10.51)

E é aqui que estou obtendo resultados muito estranhos quando se trata de conectividade de rede, tanto interna VLANquanto ao conectar-me ao mundo externo:

  • O MDC pode executar ping em todos, menos no switch ( 10.10.10.252)
  • O gateway pode executar ping em todos, exceto Machine5_H3
  • Machine1_H1 pode executar ping em todos, menos Machine3_H2
  • Machine2_H1 pode executar ping em todos, menos no switch ( 10.10.10.252)
  • Machine3_H2 pode executar ping em todos, exceto Host 1 e Machine1_H1
  • Machine4_H3 pode executar ping em todos 192.168.9.43, exceto 192.168.9.15e google.fr(a resolução de nomes está OK)
  • Machine5_H3 pode executar ping em todos 192.168.9.254, exceto 192.168.9.82(minha própria estação de trabalho) e10.10.10.254
  • Meu próprio computador ( 192.168.9.82) pode executar ping em todos, exceto Machine5_H3 ( 10.10.10.51)

Certifiquei-me de que os firewalls estivessem desligados em todas as máquinas antes de fazer esses testes e também executei arp -ano MDC para ver se havia conflito de endereço MAC e se não havia duplicatas. As máquinas na Temporarypasta também foram desligadas por precaução, mas isso não mudou nada nos resultados acima. Só por segurança, usei este trecho para forçar a geração de um novo endereço MAC para essas máquinas:

foreach ($VM in (Get-Folder Temporary | Get-VM))
{
  $NetworkAdapter = $VM | Get-NetworkAdapter
  $NetworkAdapter | Set-NetworkAdapter -MacAddress 00:50:56:1a:ff:ff -Confirm:$false
  $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
  $spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
  $spec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
  $spec.deviceChange[0].operation = "edit"
  $spec.deviceChange[0].device = $NetworkAdapter.ExtensionData
  $spec.deviceChange[0].device.addressType = "generated"
  $spec.deviceChange[0].device.macAddress = $null
  $VM.ExtensionData.ReconfigVM_Task($spec)
}

Isso não mudou nada na situação.

Instalei então o Wireshark no gateway, comecei a monitorar o tráfego 10.10.10.254e pude ver todos os tráfegos em que aquela máquina está envolvida. Por exemplo, se minha estação de trabalho ( 192.168.9.82) recebe ping de Machine5_H3 ( 10.10.10.51), posso ver a solicitação PING, depois a resposta do PING e ainda assim Machine5_H3 reclama que não recebeu nenhuma resposta. Se eu fizer o contrário, poderei ver a solicitação, 192.168.9.82mas nenhuma resposta será vista pelo gateway.

Portanto, acredito que alguns pacotes foram descartados em algum lugar, sendo meu principal suspeito o switch ( 10.10.10.252), mas não tenho certeza do que posso fazer para confirmar essa teoria.

A agregação de links foi originalmente ativada na pilha de switches DELL, mas estava apresentando problemas na conexão de nossas estações de trabalho às VMs que possuem IPs na 192.168.9.0/24rede, por isso a desligamos.
Porém, alterar essa configuração na pilha de switches não alterou nada na situação acima.

Devo ter feito algo errado ou perdido alguns detalhes de configuração, mas não consigo descobrir o que é e gostaria de receber qualquer sugestão para ajudar a resolver o que é um mistério para mim.

Responder1

Após o comentário de Zac67, verificamos a configuração do agrupamento NIC em todos os três hosts e descobrimos que os dois primeiros estavam usando o parâmetro "Rota baseada em hash IP", enquanto o terceiro host usava "Rota baseada na porta virtual de origem".

Em seguida, definimos o terceiro host com o mesmo valor dos outros e lemos o aviso associado à primeira opção que diz "A agregação de link deve ser configurada no switch físico".

Assim, voltamos ao switch e reativamos a agregação de links para as portas apropriadas, mas isso tornou toda a conectividade instável, as máquinas na 192.168.9.0/24rede tornando-se parcialmente inacessíveis, mas isso não mudou nada para aqueles na 10.10.10.0/24rede.

Então decidimos seguir o caminho oposto e desabilitar a agregação de links nos switches e usar a opção "Rota baseada na porta virtual de origem" em todos os três hosts.

Isso permitiu recuperar o comportamento normal da 192.168.9.0/24rede e melhor conectividade da 10.10.10.0/24rede. Digo melhor porque algumas máquinas ainda estavam inacessíveis, nomeadamente aquelas Host3que não conseguiam sequer aceder ao servidor DHCP para recuperar um IP.
Usando o Wireshark para observar o tráfego, descobrimos que as transmissões ARP às vezes eram filtradas, explicando assim por que algumas máquinas não conseguiam se comunicar entre si, mas ainda assim não nos dando nenhuma pista sobre uma possível solução.

Depois de ficarmos presos nisso por algumas semanas, sem qualquer esperança de encontrar uma resposta, trouxemos os consultores que ajudaram a instalar a infraestrutura e eles nos disseram duas coisas:

  1. LACP não é compatível com VLANs
  2. VLAN 42 foi proibida em uma das portas do switch

Assim, garantir que a configuração não utilizava LACP e remover a restrição na porta permitiu chegar a uma situação de pleno funcionamento.

Agora, ficamos nos perguntando como conseguimos proibir a VLAN 42 em apenas uma porta do switch.

Quanto à incompatibilidade entre LACP e VLAN, nunca nos ocorreu que essa poderia ser a origem dos nossos problemas, mas agora que nos contaram sobre isso, parece que é um problema bem conhecido ao empilhar switches DELL, mas não consegui encontrar nenhuma resposta definitiva. sobre o assunto. Mas como funciona sem ele, está tudo bem para mim.

informação relacionada