Switch flooding ao ligar interfaces no Linux

Question

                                 +--------+
                                 | Host A |
                                 +----+---+
                                     | eth0 (AA:AA:AA:AA:AA:AA)
                                     |
                                     |
                                +----+-----+
                                | Switch 1 | (layer2/3)
                                +----+-----+
                                     |
                                +----+-----+
                                | Switch 2 |
                                +----+-----+
                                     |
                          +----------+----------+
+-------------------------+       Switch 3      +-------------------------+
|                         +----+-----------+----+                         |
|                              |           |                              |
|                              |           |                              |
|     eth0 (B0:B0:B0:B0:B0:B0) |           | eth4 (B4:B4:B4:B4:B4:B4)     |
|                         +----+-----------+----+                         |
|                         |        Host B       |                         |
|                         +----+-----------+----+                         |
|     eth1 (B1:B1:B1:B1:B1:B1) |           | eth5 (B5:B5:B5:B5:B5:B5)     |
|                              |           |                              |
|                              |           |                              |
+------------------------------+           +------------------------------+

• Visão geral da topologia
  • O host A tem uma única NIC.
  • O host B tem quatro NICs que são vinculadas usando o modo de equilíbrio-balb.
  • Os dois hosts executam o RHEL 6.0 e ambos estão na mesma sub-rede IPv4.
• Análise de tráfego
  • O host A está enviando dados para o Host B usando algum aplicativo de banco de dados SQL.
  • Tráfego do Host A para o Host B: A origem int / MAC é eth0 / AA: AA: AA: AA: AA: AA, o destino int / MAC é eth5 / B5: B5: B5: B5: B5: B5 .
  • Tráfego do Host B para o Host A: A origem int / MAC é eth0 / B0: B0: B0: B0: B0: B0, o destino int / MAC é eth0 / AA: AA: AA: AA: AA: AA .
  • Uma vez que a conexão TCP tenha sido estabelecida, o Host B não envia mais frames para a eth5.
  • O endereço MAC da eth5 expira das tabelas de ponte do Switch 1 & Switch 2.
  • O comutador 1 continua recebendo quadros do host A que são destinados a B5: B5: B5: B5: B5: B5.
  • Como o Comutador 1 e o comutador 2 não têm mais entradas de tabela de ponte para B5: B5: B5: B5: B5: B5, eles inundam os quadros de todas as portas na mesma VLAN (exceto a que ela acessou, claro).
• Reproduzir
  • Se você fizer ping no host B de uma estação de trabalho conectada ao switch 1 ou 2, B5: B5: B5: B5: B5: B5 entrará novamente nas tabelas de ponte e a inundação será interrompida.
  • Após cinco minutos (o tempo limite da tabela de ponte padrão), a inundação é retomada.
• Pergunta
  • É claro que no Host B, os quadros chegam na eth5 e saem da eth0. Isso parece ok, já que é para isso que o algoritmo de ligação do Linux foi projetado - balancear o tráfego de entrada e saída. Mas como o switch para de receber quadros com o MAC de origem da eth5, ele passa da tabela da ponte, resultando em inundação.
  • Isso é normal? Por que não existem mais quadros originados da eth5? É porque simplesmente não há outro tráfego acontecendo (a única conexão é uma única grande transferência de dados do Host A)?

Eu pesquisei isso por um longo tempo e não encontrei uma resposta. A documentação declara que nenhuma mudança de switch é necessária ao usar o modo 6 da ligação da interface do Linux (balance-alb). Esse comportamento ocorre porque o Host B não envia nenhum pacote adicional de eth5, enquanto em circunstâncias normais espera-se que seja? Uma solução é configurar um cron job que faça com que o Host B mantenha as entradas da tabela de bridge fora do tempo limite, mas isso parece um hack sujo.

    

Answer 1

Sim - isso é esperado. Você atingiu um problema bastante comum com ligação de NIC a hosts, inundação de unicast. Como você observou, os temporizadores em seu switch para os endereços de hardware em questão, já que nenhum quadro originado desses endereços está sendo observado.

Aqui estão as opções gerais -

1.) Tempos limite de tabela de endereços mais longos. Num comutador L2 / L3 misto, os temporizadores ARP e CAM devem estar próximos um do outro (com o temporizador CAM a funcionar mais alguns segundos). Esta recomendação é válida independentemente do resto da configuração. Na chave L2, os temporizadores geralmente podem ser definidos por mais tempo sem muitos problemas. Dito isso, a menos que você desabilite os timers, você estará de volta na mesma situação eventualmente, se não houver algum tipo de tráfego proveniente desses outros endereços.

2.) Você poderia codificar os endereços MAC nos switches em questão (todos os switches no diagrama, infelizmente). Isso obviamente não é ideal por várias razões.

3.) Altere o modo de ligação no lado do Linux para um que use um MAC de origem comum (por exemplo, 802.3ad / LACP). Isso tem muitas vantagens operacionais se o seu switch for compatível.

4.) Gere arcos gratuitos através de um cron job de cada interface. Você pode precisar de alguns IP's fictícios nas várias interfaces para evitar uma condição de oscilação (ou seja, o IP do host percorre os vários endereços de hardware).

5.) Se é um problema de tráfego, basta ir ao 10GE! (desculpe - teve que jogar isso lá)

A rota do LACP é provavelmente a mais comum e suportável, e os switches podem ser configurados para equilibrar o tráfego de entrada para o servidor de maneira uniforme pelos vários links. Caso contrário, acho que a opção arp gratuita será a mais fácil de integrar.