Tempos limite do cache MAC do Procurve HP em sessões TCP longas

Question

Temos uma rede de switches HP 2510G conectados de volta ao HP2912al para agregação. Percebemos que conexões de longa duração, como um despejo de despejo de banco de dados MySQL, são despejadas em todas as portas de rede quando o tempo limite do cache de Mac expira. Fazer um "arping" contra o IP de destino interrompe a inundação (voltando à porta para a porta) até que o tempo limite do cache expire novamente.

Eu posso entender por que isso aconteceria no tráfego UDP unidirecional, mas não sei por que isso está acontecendo com o TCP. Eu acho que os ACKs da máquina receptora podem fazer com que os Procurves atualizem o endereço MAC em seu cache. Em vez disso, parece que eles só aprendem com os ARPs.

Alguma idéia?

    

Answer 1

O problema fundamental com o qual você está lidando aqui é que a entrada MAC expira e não é renovada no tempo, o que causa inundação Unicast. Há algumas coisas para suspeitar nesta situação:

1. Rotatividade da tabela MAC. Se você tiver muitos hosts no domínio de colisão do Switch, você poderá obter a rotatividade de tabelas do MAC, quando as entradas que estiverem em uso tiverem o tempo limite esgotado. Isso geralmente acontece quando você está entrando em um lote de VLANs através de um switch para conectar duas redes principais.

2. As alterações de STP tendem a causar inundações. A configuração incorreta em STP (switches com IDs idênticos ...) e links instáveis pode causar a limpeza de caches e inundações inesperadas.

3. Se você executar 802.1q e não tiver uma configuração simétrica, poderá obter a opção para saber o destino na VLAN errada. Isso fará com que a opção acabe esquecendo a entrada e comece a inundar. Como as respostas vêm em uma VLAN diferente, o switch continuará inundando.

4. Você tem uma situação de roteamento assimétrica. Se o seu roteamento for assimétrico e o tráfego não for o inverso, você poderá facilmente expirar suas entradas na tabela MAC. Por exemplo, na imagem a seguir, o tráfego do roteador1 para o roteador 2 passa pelo Switch1 e o tráfego do roteador2 para o Roteador1 passa pelo Switch2. Neste caso, você corre o risco de receber o host3 inundado.

      host1
       |
      Router1
     |      |
   Switch1  Switch2 - Host3
     |      |
      Router2
       |
      host2
   

5. Tráfego totalmente unidirecional. Neste caso, você precisa aumentar a tabela mac o suficiente para que os arrays gratiosos do sistema operacional (se configurado para enviar algum) mantenham a tabela atualizada, ou até mesmo configurem o encaminhamento. Observe que o tráfego puramente unidirecional é muito raro. Um despejo MYSQL não deve ser unidirecional. Eu só vi isso em casos de roteamento assimétrico.

Como um substituto, eu recomendo implantar o arpd (ou similar) para fornecer arcos graciosos e parar o alagamento. Deve ter o mesmo efeito que o ARPPing (que você encontrou resolve o problema temporariamente). Mas você realmente deve depurar isso.

Minha primeira parada seria verificar se o roteamento é de fato simétrico até o fim, como um problema de roteamento assimétrico parece mais provável.

Além disso, consulte a documentação da Cisco em Inundação por Unicast nas redes do Campus que é muito bom.