Efeitos de ter um flush ARP rápido

Question

Então, o cenário é que temos um servidor web no nosso colocation. Na frente desse servidor da web estão dois SonicWalls e dois switches gerenciados sem empilhamento L2. Estamos tentando encontrar uma maneira eficiente de configurar redundância em todos os níveis aqui (roteador, switch, máquina) com o equipamento que já possuímos (por favor, não há respostas "Go buy X"). Os SonicWalls têm um link de HA ativo / passivo, os switches não têm nada e a máquina tem dois NICs agrupados com o mesmo endereço IP (diferentes MACs).

Assim, cada roteador tem um link para cada switch. Os switches têm um link de tronco entre si e cada switch tem uma conexão com a NIC dual no PC. Neste momento, a redundância funciona de tal forma que eu posso matar o link entre o roteador / switch ou o switch / pc e ainda tenho acesso à rede. Para conseguir isso, eu configurei o flush ARP para 2 minutos no Sonicwalls (o mínimo que seria) e 60 segundos nos comutadores). Eu posso configurar um PING constante na máquina e depois remover um dos links. Eu normalmente tenho 20-30 segundos de tempo de inatividade e, em seguida, o ping é iniciado novamente.

A minha pergunta é: quais são os efeitos negativos de ter esse tempo de descarga baixo? O servidor executa uma plataforma de teste on-line que as pessoas usam e, em alguns casos, baixam arquivos de áudio. Foi-me dito por um colega que se eles estão baixando um arquivo e o cache do arp é liberado no roteador, eles perderão o download. Meu entendimento com o TCP era que, se ele não obtivesse um ACK em resposta, ele continuaria a reenviar esse mesmo pacote até que o fizesse? Dada essa informação, você vê algum problema que eu possa encontrar?

    

Answer 1

Nas redes nas quais trabalhei, nos servidores anteriores, os links redundantes tinham o mesmo endereço MAC para os dois links; esse endereço MAC era usado para o tráfego principal para & do servidor e os endereços MAC nativos foram usados para keep-alives entre os links. Esse método elimina a necessidade de limpar o cache ARP constante.

De qualquer forma, em resposta à sua pergunta, o TCP tentará novamente se necessário, mas provavelmente não seria necessário porque o dispositivo que tinha acabado de esvaziar o seu cache ARP iria simplesmente enviar uma requisição ARP como faria em seu primeiro tente entrar em contato com o dispositivo com o endereço sem cache. Nos switches, como você deve saber, o cache de endereços será repovoado quase que instantaneamente porque aprenderá os endereços assim que o tráfego com um MAC desconhecido passar por ele.