Rastrear una dirección mac de origen no válida


13

Heredé la compatibilidad con un sitio remoto que contiene un Cisco 4500 y está conectado a ~ 2 docenas de conmutadores de acceso Cisco, principalmente 2960 con un par de 3750 y 3560. No todos los interruptores de acceso están conectados directamente al 4500: hay una conexión en cadena de interruptores que aparentemente se realizó como resultado de un cableado inadecuado. Recientemente, noté mensajes de error en el 4500 que indican que se han recibido tramas con una dirección MAC de origen no válida:

*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

El dispositivo conectado a Te5 / 1 es un conmutador de acceso (Cisco 3750). A su vez, está conectado a otros 6 interruptores de acceso. Después de buscar un poco en Google, parece que el 4500 es la única plataforma de Cisco que registra direcciones MAC de origen no válidas. Según mi lectura, otras plataformas (2960, 3750, etc.) parecen reenviar los marcos, pero no los registran como no válidos, ni añaden una entrada a la tabla de direcciones mac. Sospecho que la causa raíz de las direcciones MAC de origen no válidas podría ser una falla, un error de software o quizás un servidor vmware mal configurado. ¿Qué herramientas están disponibles en los conmutadores de acceso para localizar el puerto infractor?


1
Eliminé mi publicación, no me di cuenta de que no eran visibles en absoluto. Si el conmutador no los coloca en CAM, supongo que su mejor opción es ejecutar la sesión SPAN en los conmutadores, pero incluso entonces sería difícil encontrar el puerto de origen. Otra opción sería deshabilitar la unidifusión desconocida y ver si algo se rompe. Sin embargo, me sorprende que la comunicación funcione. Si un host con ese MAC envía algo fuera de las subredes, el GW tendría que ARP para ver el MAC del host y encapsular la trama, ¿tiene el GW algún mapeo ARP extraño?
Daniel Dib

2
De acuerdo con supportforums.cisco.com/docs/DOC-36000, estos marcos deben dejarse caer en HW para que al menos no afecten el rendimiento de los conmutadores.
Daniel Dib

1
Sí, de acuerdo con ese enlace: "Tenga en cuenta que los paquetes con una dirección MAC no válida se descartarán de todos modos, todos los demás switches Cisco Catalyst descartan silenciosamente estos paquetes en HW, la plataforma 4k genera explícitamente un mensaje de registro cuando se observa dicho evento". ... pero sé que este no puede ser el caso, ya que el 4500 se queja de tramas que llegan a Te5 / 1, que es el puerto conectado al 3750. Esto indicaría que el 3750 está reenviando las tramas con el no válido fuente mac a pesar de lo que dice DOC-36000.
Usuario123456

¡Divide y vencerás!
generalnetworkerror

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


4

Puede intentar si los marcos pueden bloquearse usando una ACL MAC en interfaces y / o vlans en los conmutadores de acceso. Al aplicar los bloques de forma selectiva y verificar si los mensajes de error en el 4500 desaparecen o no, puede concentrarse en la fuente del tráfico.

Mover los cables para ver si el puerto mencionado en el mensaje de error en el 4500 sigue también podría ayudar, pero podría resultar complicado en un entorno de producción.


7

En general, cuando he visto esto, proviene de una máquina virtual mal configurada (a menudo alojada en una máquina de usuario). Dependiendo de la situación y el entorno, pueden ser difíciles de rastrear (vimos muchos de estos en una universidad en los edificios del departamento de CS y ECE que se movían y entraban / salían como lo hacían los estudiantes).

Ya tiene un par de excelentes respuestas, pero otra opción que puede seguir es agregar la siguiente configuración a los interruptores posteriores (37xx, 36xx, 29xx):

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

Esto eliminará el tráfico con este MAC en lugar de reenviarlo, y dado que debe hacerse en hardware (salvo las características / problemas que causan las búsquedas de MAC en el software), no debería tener un impacto negativo en el rendimiento.


Gracias por esta sugerencia. Esto evitará que los cuadros se envíen a través de los troncales a otros interruptores, lo cual es una gran victoria. ¿Hay alguna forma a través de los comandos de registro o depuración para observar un puerto que deja caer marcos en función de esta configuración?
Usuario123456

@fcorrao, lamentablemente no con esta configuración. Tendría que intentar hacer lo que sugirió Gerben y utilizar una MAC ACL o la sugerencia de Dave de capturar el tráfico de los puertos. Pero mi opinión es que solo el dispositivo mal configurado se verá afectado negativamente, por lo que lo darán a conocer o ni siquiera se darán cuenta.
YLearn

0

Me parece que este error no afecta el rendimiento de la red, ya que descubrió los mensajes de registro por su cuenta, en lugar de estar inundado de quejas de los usuarios. Esto me lleva a sospechar que el problema radica en algunos servicios o software conectados, pero parcialmente configurados o mal configurados que no están actualmente en uso.

Su mejor curso puede ser dejar que este perro dormido mienta, hasta el momento en que algún usuario informe un problema. Alternativamente, si tiene tiempo de sobra, puede ejecutar sesiones de SPAN como sugirió @Daniel Dib, y realizar un escrutinio minucioso hasta que determine un puerto o dispositivo sospechoso.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.