Bien, aquí está mi situación.
Esto está en Internet. El 6224 es el enrutador en esta imagen y reside físicamente en Kanata.
Tanto la VLAN 1697 como la 3994 las proporciona un proveedor de servicios de Internet. Estas VLAN se proporcionan a través de un único cable Ethernet de 1 Gb.
Los hosts Kanata están conectados directamente al 6224; los otros dos sitios son remotos.
VLAN 3994 es un espacio de dirección IP único, por lo que, en teoría, no debería importar físicamente dónde están los hosts en esa subred.
Aquí está el problema.
Tengo un sistema de monitoreo que está conectado a Internet, por lo que las sondas del monitor entrarían en este diagrama en la VLAN 1697.
Cuando hago ping a los anfitriones de Albert o Bells Corners desde Internet, no hay pérdida. La conexión parece perfecta.
Cuando hago ping a los hosts en Kanata, pierdo entre el 10 y el 40% de los pings. La pérdida no es predecible, pero cuando los pierdo, siempre pierdo al menos 3, generalmente 4, rara vez más, pings en un grupo.
He conectado un monitor directamente al 6224 en Kanata en 3994.
Cuando el monitor hace ping a la interfaz de enrutamiento 6224, veo exactamente el mismo patrón de pérdida, pero NO al mismo tiempo que la pérdida del sistema remoto. El tiempo de ping es de aproximadamente 1 ms.
Cuando el monitor hace ping a otro sistema conectado directamente al 6224, no hay pérdida. El tiempo de ping es de aproximadamente 0,1 ms, una décima parte del tiempo necesario para hacer ping al enrutador.
Alguien sabe lo que está pasando aquí?
Actualización para hacer las cosas menos claras tal vez
Lo que parece estar sucediendo es que el tráfico que entra y sale de la conexión del ISP está bien. El tráfico que va desde el cerebro del enrutador al cerebro del conmutador (o de regreso, tal vez) es lo que está causando el problema.
No puedo culpar al ISP porque el acceso a Internet hacia/desde los dos sitios remotos es sólido. Sólo los hosts que están conectados directamente al 6224 tienen problemas.
Actualización 2
Bien, después de mucho tiempo mirando los rastros, tengo un síntoma más específico.
Hice un tcpdump en la vlan 3994 del enlace ascendente del ISP buscando mi propia dirección con la teoría de que todo lo que debería ver es tráfico de transmisión dirigido a los sitios remotos. En cambio, vi los paquetes que esperaba ver en la interfaz de mi sistema bajando el TLS en esta VLAN.
Entonces:
Por alguna razón, el 6224 piensa con frecuencia que mi sistema está en el otro extremo del TLS.
Cuando inspecciono la mesa de conmutación cuando todo está funcionando, mi entrada se ve así:
3994 0007.E924.F714 2/g16 Dynamic
…lo cual tiene sentido ya que está conectado al puerto 16. Sin embargo, cuando está roto, se ve así:
3994 0007.E924.F714 2/g22 Dynamic
Los flujos de paquetes mal dirigidos parecen estar dirigidos por una transmisión desde mi sistema. Sin embargo, veo una transmisión salir de mi sistema y dos en la VLAN 3994 al TLS. Por lo general, es un Informe de membresía de IGMP V2/Unirse al grupo 224.0.0.251, pero a veces es el chip de administración de mi sistema el que se queja por sí solo (lo hace aproximadamente cada 2 segundos por razones que son estúpidas).
Esto implica que hay un sistema en Bells Corners o Albert que está escuchando mi transmisión y repitiéndola por alguna razón. Entonces el 6224 dice ah, esta Mac realmente debe estar inactiva en el enlace TLS y ajusta su tabla de conmutación en consecuencia.
¿Le suena de algo esta descripción del problema?
Respuesta1
Bien, descubrí esto y lo escribiré aquí. Es poco probable que esta solución particular ayude a nadie porque es un caso límite.
En la historia antigua del enlace con este proveedor, agregamos una segunda VLAN a la principal. En ese momento, el proveedor conectó esta VLAN como ambas etiquetadasysin etiquetar en su lado de la conexión. Su conmutador trata las conexiones etiquetadas y no etiquetadas como conexiones separadas.
Entonces, lo que sucede es que mi sistema conectado a Dell emite una transmisión arp (la interfaz de administración de esta computadora emite paquetes arp cada medio segundo por razones estúpidas), que el conmutador reenvía por el enlace al sitio remoto. El conmutador del proveedor escucha la transmisión en la interfaz sin etiquetar.y me lo envía de vuelta en la interfaz etiquetada. El conmutador escucha esto y luego concluye que realmente se puede acceder a la dirección mac que origina la transmisión a través del enlace del proveedor. Por lo tanto, los paquetes de seguimiento se desvían.
La solución fue que el proveedor cambiara su configuración para que coincidiera con la de Dell. Todos los problemas generales de conexión han cesado.