Switch Floods Pacotes que devem ser Unicast

Question

Eu trabalho como administrador de rede em uma grande empresa. Ultimamente, notamos um problema com nossa infra-estrutura de rede. Basicamente, nosso backend de rede está em um Catalyst como principal switch de backend L3, e poucos switches Cisco Nexus como switches de borda L2, conectados a esse Catalyst.

O problema aparece quando tentamos detectar o tráfego em um de nossos hosts. Em seguida, ( sempre ) visualizamos o tráfego de unicast entre outros hosts.

Vou tentar ser mais elaborado: Assumindo que estou no host 10.0.0.1, com o mac MAC , eu corro o comando -

tcpdump -i eth0 ether host not MAC and host not 10.0.0.1 and not broadcast and not multicast

Eu sempre vejo o tráfego entre outros hosts.

Eu li um artigo da Cisco sobre Inundação de Unicast , no entanto - o "fenômeno" ocorre não apenas ao passar entre VLANs em nossa rede, mas também na mesma VLAN. É possível que isso aconteça ao passar entre switches na mesma VLAN (nossas VLANs abrangem muitos switches)? Todos os switches estão conectados por um tronco ao Catalyst ...

Alguma idéia?

Obrigado.

Editar:

Parece que encontramos a fonte dos nossos problemas.

Basicamente, cada vez que um dos switches obtém um quadro com um endereço MAC, ele não reconhece - ele o inunda em todas as portas. Isso é normal - e a maneira como as coisas devem ir. No entanto, em nossas configurações atuais, uma entrada MAC no switch deve "viver" por 30 minutos. Se um MAC não for visto por 30 minutos, ele será excluído do switch até ser visto novamente. Se um pacote é enviado para esse MAC e não está na tabela - todas as portas serão inundadas para encontrar a porta MAC de destino (esperamos obter uma resposta de uma das portas).

Encontramos um dos MACs de destino e procuramos na tabela MAC do switch. A tabela não continha o MAC enquanto a rede estava inundada. Tentamos ARP o endereço relacionado a esse MAC - e o flood parou (como o MAC reapareceu na tabela MAC).
No entanto, após alguns segundos, o MAC desapareceu da tabela MAC novamente e a inundação começou novamente.

Parece que o problema de inundação deriva de um problema com as tabelas MAC em nossos switches. Parece que eles "esquecem" os endereços MAC rapidamente do que deveriam (os MACs devem permanecer por 30 minutos) e inunda todos os pacotes com esse MAC.

    

Answer 1

Um rápido prequel -

Tabela ARP - Um dispositivo L3 (roteador, host, etc) mantém um mapeamento entre um determinado endereço IP e um endereço MAC correspondente.

Tabela CAM - Isso pode ser conhecido por outros nomes em determinadas plataformas de comutação, mas o resultado é que um dado dispositivo de comutação L2 mantém um mapeamento entre um endereço de hardware e uma ou mais portas físicas de comutador.

O que está acontecendo no caso acima é chamado de inundação unicast. Essa é uma condição em que o roteador ainda tem uma entrada ARP ativa, mesmo que a tabela CAM do comutador tenha liberado a entrada correspondente. Como resultado, quando o roteador recebe um pacote para um determinado host, ele é simplesmente encaminhado para o switch sem primeiro enviar uma solicitação ARP (o IP: o mapeamento MAC ainda é armazenado em cache). O switch, no entanto, não conhece mais a porta para a qual esse endereço MAC é mapeado (essa entrada foi expirada anteriormente). Se o switch não tiver uma entrada CAM para um determinado MAC unicast, ele inundará os pacotes desse MAC para todas as portas até que ele veja uma resposta (ou seja, a resposta a uma solicitação ARP).

Por razões obscuras, os timers ARP e CAM são geralmente bem diferentes nos switches da Cisco. Os valores variam um pouco, mas a incompatibilidade continua nos dispositivos Nexus mais modernos. A melhor prática é definir os temporizadores ARP e CAM para valores semelhantes - idealmente com a tabela CAM definida para 5 segundos ou mais que o ARP. É melhor para o roteador re-ARP do que para o switch ter que inundar. Configurar os dois valores para ~ 600 segundos (10 minutos) geralmente não é tão ruim, mas alguns ambientes podem querer ir um pouco mais se o tráfego ARP excessivo for visto no roteador.

    

Answer 2

Sim, transmissões de ARP (atire o wireshark e você verá "Quem tem blá blá blá. Diga blá.").

O cliente deve responder "É comigo!" Então, eu investigaria o cliente que não está respondendo.