Ligação Linux (balance-tlb), convidados KVM e switches L2 = inundação unicast?

2

Eu tenho um problema de inundação de unicast na minha rede, que começou quando movi alguns softwares para convidados virtualizados. Parece muito semelhante ao relatado aqui: Troca de inundação ao ligar interfaces no Linux . Essa pergunta remonta a 2012 ... então talvez agora haja uma solução melhor, talvez no lado do Linux / KVM.

A seguir, tentarei explicar a arquitetura e as etapas de solução de problemas que realizei. Espero que alguém possa me dar algumas dicas e talvez uma solução! Obrigado antecipadamente!

ARQUITETURA

Servidor

Host Linux com o PROXMOX 4.1 e várias máquinas virtuais do Windows.

O host possui 4 interfaces Ethernet Gbit (com endereços MAC A, B, C e D), vinculados ao método balance-tlb.

A ligação é então conectada às máquinas virtuais. Portanto, cada VM tem seu próprio endereço MAC (com endereços MAC X, Y, Z, ...).

O software hospedado nas máquinas virtuais interage com muitos dispositivos no campo.

Rede

O servidor está conectado a um comutador Juniper, que então se conecta a uma ampla rede Cisco. Tudo é nível 2.

PROBLEMA

Na rede da Cisco, vejo, de tempos em tempos, tempestades de unicast. Parece que eles começam a cada 5 minutos ou múltiplos dele. Analisei o tráfego e vejo que de repente o tráfego de alguns dispositivos para uma determinada máquina virtual (e não vice-versa) é replicado em todas as portas físicas dos switches (na mesma VLAN). O problema resolve sozinho depois de alguns segundos.

IDEA

Lendo a documentação da Cisco (sobre inundação unicast e "tempo de envelhecimento" MAC) e também o link mencionado acima, descobri que o problema pode ser devido ao fato de o endereço MAC das máquinas virtuais não aparecer com tanta freqüência na rede, para que, após um certo "tempo de envelhecimento", os switches comecem a encaminhar esse tráfego para todas as portas até descobrirem onde está o host.

RESOLUÇÃO DE PROBLEMAS

Conectei um laptop na rede e comecei a fazer o ping de uma máquina virtual. Eu cheirei os pacotes no laptop.

A partir disso, pude ver:

  • Solicitação ARP da máquina virtual, usando como fonte MAC seu próprio endereço MAC (digamos que X)

  • Resposta ARP do laptop, usando como fonte MAC seu próprio endereço MAC (L) e destino o endereço MAC da VM (X)

  • solicitações de ping da máquina virtual, usando como fonte MAC um dos endereços MAC das portas Ethernet físicas ligadas (A, B, C, D e alternando de tempos em tempos entre três delas) e como Destino MAC L

  • respostas de ping do laptop, usando como origem MAC L e como destino MAC o endereço MAC da máquina virtual (X)

Basicamente, parece que, exceto pela primeira requisição ARP, a máquina virtual nunca aparece para o laptop com seu próprio endereço MAC (X), mas sempre com A, B, C ou D (variando no tempo). No entanto, o laptop sempre responde ao X.

SOLUÇÃO?

Eu li que está tudo bem no modo balance-tlb que o tráfego sai de diferentes interfaces dependendo da carga. No entanto, acho que esse comportamento combinado com o fato de as máquinas virtuais aparecerem na rede com o endereço MAC de origem da interface física em uso pode gerar o problema que relatei.

Se isso estiver correto, alguém sabe se existe uma maneira de sempre forçar o uso do próprio endereço MAC da VM para cada comunicação? (por exemplo, como já acontece para solicitações ARP) Ou talvez a solução esteja em outro lugar?

Eu pensei que eu poderia configurar VMs do Windows para redefinir a tabela ARP a cada 3 minutos ... mas isso parece um pouco de força bruta para mim ...:)

Obrigado novamente por qualquer ajuda!

EDIT: Confirmo que se durante um evento de flooding eu logar rapidamente na VM correspondente e emitir uma redefinição de tabela ARP, vejo novas solicitações ARP da VM (contando seu próprio endereço MAC para o net) e a tempestade pára imediatamente.

    
por z2k 07.07.2016 / 14:11

2 respostas

0

Balance-tlb (modo 5) e balance-alb (modo 6) não funcionam com pontes virtuais. Eles podem causar loops de broadcast, eles reescrevem MAC de origem em pacotes sob algumas condições e o modo 6 intercepta o ARP por design.

Você precisa usar o backup ativo (modo 1) sem configuração de switch ou balance-xor (modo 2) ou 802.3ad (modo 4) com configuração de switch.

Você também pode usar round-robin (modo 0) ou broadcast (modo 3) com configuração de switch, mas isso não é bom para o desempenho do fluxo de TCP.

    
por 09.07.2016 / 21:43
-1

link É possível que seus hosts ::::::: "" "" com temporizadores ARP sejam maiores que o limite de tempo de cache de endereços nos switches ..... "" "" "de acordo com o artigo. Tente configurar os temporizadores ARP do host do hipervisor KVM e dos hosts da VM, que devem ser menores que os do próprio Comutador, ao qual eles se conectam por meio da porta Ethernet física. Por favor, deixe-nos saber o que você encontra. E compartilhe conosco. Obrigado.

    
por 07.07.2016 / 16:25