Estamos teniendo un problema con nuestro conmutador Catalyst 6500 donde sospechamos que el caché ARP está dañado. Esto se presenta con los siguientes síntomas:
Cuando intenta hacer ping a un sistema que no se ha resuelto antes, la primera respuesta de ping caduca y cada una de las siguientes tiene éxito: Haciendo ping a foo.network.com [xxx.xx.xx.xx] con 32 bytes de datos: Solicitud cronometrada afuera. Respuesta de xxx.xx.xx.xx: bytes=32 tiempo=5ms TTL=55 Respuesta de xxx.xx.xx.xx: bytes=32 tiempo=3ms TTL=55 Respuesta de xxx.xx.xx.xx: bytes= 32 tiempo=3ms TTL=55
Cuando se producen problemas de corrupción, cada dos pings caduca: Haciendo ping a foo.network.com [xxx.xx.xx.xx] con 32 bytes de datos: Respuesta de xxx.xx.xx.xx: bytes=32 tiempo=5ms TTL =55 Se agotó el tiempo de espera de la solicitud. Respuesta de xxx.xx.xx.xx: bytes=32 tiempo=5ms TTL=55 Se agotó el tiempo de espera de la solicitud.
Borrar la caché ARP resuelve temporalmente el problema. Para borrar el caché ARP usamos los comandos: clear arp cache clear ip cache Esto lo soluciona, pero seguramente volverá a suceder.
Detalles sobre el interruptor:
Software IOS (tm) s72033_rp (s72033_rp-PK9SV-M), versión 12.2(17d)SXB8, SOFTWARE DE VERSIÓN (fc2)
Procesador cisco WS-C6509-E (R7000) (revisión 1.1)
Cualquier ayuda apreciada, gracias.
ACLARACIÓN: Tenemos la red que administramos y luego estamos conectados a la red corporativa. Todas las solicitudes a las máquinas dentro de la red que administramos funcionan bien. Sólo estamos teniendo problemas con las máquinas de la otra red.
Respuesta1
Le sugeriría que abra un caso a Cisco.
Podrán verificar si hay errores conocidos en su versión de IOS y le pedirán detalles de configuración que quizás no desee publicar aquí. (pero si lo desea, puede poner el resultado de una tecnología sh en algún lugar donde pueda ayudarnos). ¿
También se agrega después de un reinicio o comenzó a corromperse después de un largo tiempo de actividad?
Respuesta2
¿Está viendo este problema con los PING desde la CLI del conmutador o desde una PC conectada al conmutador?
¿Este conmutador proporciona funciones de capa 3 (enrutamiento)?
¿Estos PING muestran que tienes problemas entre dos dispositivos en la misma subred o entre subredes?
¿El registro en el conmutador ("mostrar historial de registro", creo) muestra algo incorrecto?
¿El problema afecta la entrega de paquetes solo a un par de dispositivos o ve que afecta a varios dispositivos?
Tuve un problema similar a este en el sitio de un Cliente hace unos años. Capturé el resultado de un "show mac-" antes de que ocurriera el problema, y luego durante el problema, y comparé la búsqueda de dispositivos que parecían estar en diferentes puertos antes y después del inicio de la interrupción.
Descubrí que había un dispositivo integrado en la LAN (un reloj, en este caso) que periódicamente transmitía un lote de tramas con una dirección de origen "falsificada", confundiendo la tabla de puentes del conmutador y provocando que el conmutador enviara tramas en direcciones incorrectas. puerto por un tiempo. Pude verlo en la salida "show mac-" al notar que los dispositivos que no deberían haber estado cambiando de puerto parecían estar haciéndolo.
¡Suena divertido solucionar problemas! Ojalá estuviera allí... >sonríe<
Editar:
Gracias por los comentarios.
"show log hist" muestra un registro persistente. Mientras no borre el registro, cualquier mensaje reportado seguirá ahí después de borrar el caché arp en el conmutador.
¿Existe algún otro enrutador entre su 6509 y el centro de datos corporativo donde viven los dispositivos problemáticos?
¿Está utilizando algún protocolo de enrutamiento dinámico?
Esto es lo que dice mi instinto:
Le recomiendo encarecidamente que guarde una copia de "show mac-" y "show arp" antes de que ocurra una falla y nuevamente cuando ocurra una falla (solo debería tomar un momento capturarlos con algo como PuTTY, por lo que puede continuar limpiando el caché arp rápidamente).
Me doy cuenta de que no puedes publicar fácilmente estas capturas aquí, pero te recomiendo que las incluyas en una hoja de cálculo o base de datos y compares la dirección MAC con los puertos en un informe y las direcciones MAC con la dirección IP en otro. Si comparas "antes" y "durante", predigo que verás algunas diferencias.
Suponiendo que hay un enrutador entre su 6509 y el centro de datos corporativo, predigo que encontrará que la dirección MAC de ese enrutador se "mueve" entre puertos, o que su dirección IP se mueve entre direcciones MAC.
Si no hay un enrutador y las máquinas del centro de datos corporativo están hablando con este 6509 en la capa 2, predeciré que los propios dispositivos podrían mostrar algún "movimiento" entre puertos o direcciones IP entre direcciones MAC.
Respuesta3
Si ejecuta un rastreador en el cliente al que se le hace ping, ¿ve todos los pings o solo la mitad de ellos?
¿Qué sucede si obtiene los pings de diferentes interfaces en el 6500? ¿Le sucede a los hosts para los cuales el 6500 es la puerta de enlace predeterminada?
¿Cómo se ve la tabla de direcciones mac? ¿Qué tal un traceroute? ¿Y un 'ping -r9'?
No descartes un error de IOS, pero también podría ser muchas otras cosas...
Respuesta4
Tengo que estar de acuerdo con Peter y Evan. Esto suena más a una ruta/puerto de rebote que a un ataque de caché. Especialmente en un 65xx. Para ampliar el comentario de Evan, asegúrese de obtener la tabla arp (en funcionamiento), pero la única entrada que realmente necesitará es el enrutador del siguiente salto. ¿Ha descartado problemas de rutas múltiples? Vi a alguien preguntarle si estaba ejecutando un protocolo de enrutamiento dinámico (o múltiples puertas de enlace con rutas estáticas flotantes) pero no he visto su respuesta. ¡Buena suerte!