Rastreando um endereço MAC de origem inválido

Eu herdei o suporte de um site remoto que contém um Cisco 4500 e está conectado a ~ duas dúzias de switches de acesso Cisco - principalmente os 2960s com um par de 3750s e 3560s. Nem todos os comutadores de acesso estão conectados diretamente ao 4500 - há um encadeamento em série de comutadores que aparentemente foi feito como resultado de cabeamento inadequado. Recentemente, notei mensagens de erro no 4500, que indicam que os quadros foram recebidos com um endereço MAC de origem inválido:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

O dispositivo conectado ao Te5 / 1 é um comutador de acesso (Cisco 3750). Por sua vez, está conectado a outros 6 switches de acesso. Depois de pesquisar um pouco, parece que o 4500 é a única plataforma Cisco que registra endereços MAC de origem inválidos. Pela minha leitura, outras plataformas (2960, 3750, etc) parecem encaminhar os quadros, mas não os registram como inválidos, nem adicionam uma entrada à tabela de endereços do Mac. Suspeito que a causa raiz dos endereços MAC de origem inválidos possa ser um defeito, um bug de software ou talvez um servidor vmware configurado incorretamente. Quais ferramentas estão disponíveis nos comutadores de acesso para rastrear a porta incorreta?

cisco switch layer2

— Usuário123456
fonte

Excluiu minha postagem, não sabia que eles não eram visíveis. Se o switch não os colocar no CAM, acho que sua melhor aposta é executar a sessão SPAN nos switches, mas mesmo assim seria difícil encontrar a porta de origem. Outra opção seria desativar o unicast desconhecido e ver se algo quebra. Estou surpreso que a comunicação funcione. Se um host com esse MAC enviar algo para fora de suas sub-redes, o GW precisará ARP para ver o MAC do host e encapsular o quadro, o GW possui algum mapeamento ARP estranho?

— Daniel Dib

De acordo com supportforums.cisco.com/docs/DOC-36000, esses quadros devem ser descartados em HW, portanto, pelo menos, não deve afetar o desempenho dos comutadores.

— Daniel Dib

Sim, de acordo com o link: "Observe que os pacotes com endereço MAC inválido serão descartados de qualquer maneira, todos os outros switches Cisco Catalyst estão silenciosamente descartando esses pacotes no HW, a plataforma 4k está gerando explicitamente a mensagem de log quando esse evento é observado". ... mas eu sei que isso realmente não pode ser o caso, já que o 4500 está reclamando de quadros que estão chegando no Te5 / 1, que é a porta conectada ao 3750. Isso indica que o 3750 está encaminhando os quadros com o inválido Mac de origem, apesar do que o DOC-36000 diz.

— usar o seguinte comando

Divida e conquiste!

— generalnetworkerror

Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.

— Ron Maupin

Respostas:

Você pode tentar se os quadros podem ser bloqueados usando uma MAC ACL em interfaces e / ou em vlans nos switches de acesso. Aplicando os blocos seletivamente e verificando se as mensagens de erro no 4500 desaparecem ou não, você pode localizar a origem do tráfego.

Mover cabos para ver se a porta mencionada na mensagem de erro no 4500 a seguir também pode ajudar, mas pode ser complicada em um ambiente de produção.

— Gerben
fonte

Geralmente, quando vejo isso, é proveniente de uma VM mal configurada (geralmente hospedada em uma máquina de usuário). Dependendo da situação e do ambiente, eles podem ser difíceis de rastrear (vi muitos deles em uma universidade nos prédios dos departamentos de CS e ECE que se moviam e iam / vinham como os estudantes).

Você já tem algumas ótimas respostas, mas outra opção que você pode seguir é adicionar a seguinte configuração aos comutadores downstream (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

Isso eliminará qualquer tráfego com este MAC, em vez de encaminhá-lo e, como deve ser feito em hardware (exceto os recursos / problemas que fazem com que as pesquisas de MAC sejam feitas em software), não deve ter um impacto negativo no desempenho.

— YLearn
fonte

Obrigado por esta sugestão. Isso impedirá que os quadros sejam encaminhados através dos troncos para outros comutadores, o que é uma grande vitória. Existe uma maneira através dos comandos de registro ou depuração para observar uma porta que descarta os quadros com base nessa configuração?

— precisa saber é o seguinte

@fcorrao, infelizmente não com esta configuração. Você teria que tentar fazer o que Gerben sugeriu e usar uma ACL do MAC ou a sugestão de Dave de capturar o tráfego fora das portas. Mas, na minha opinião, é que apenas o dispositivo configurado incorretamente será afetado adversamente; portanto, eles o tornarão conhecido ou nem perceberão a si mesmos.

— YLearn

Parece-me que esse erro não está afetando o desempenho da rede, pois você descobriu as mensagens de log por conta própria, em vez de estar sendo inundado por reclamações de usuários. Isso me leva a suspeitar que o problema está em alguns softwares ou serviços conectados, mas parcialmente configurados ou mal configurados, que não estão em uso no momento.

Seu melhor caminho pode ser deixar esse cão adormecido até que algum usuário relate um problema. Como alternativa, se você tiver tempo de sobra, poderá executar sessões de SPAN como o @Daniel Dib sugeriu, e examinar minuciosamente a saída até determinar uma porta ou dispositivo suspeito.

— Dave em Ohio
fonte