¿Cómo puedo diagnosticar un bucle de puente (ethernet)?

Dado que el árbol de expansión ha fallado (o no tiene ningún árbol de expansión) y obtener un bucle de ethernet, ¿cuál es la mejor manera de diagnosticar dónde está el problema?

¿Qué interruptor ?, ¿qué cable? y así.

De acuerdo, supongamos que tiene una topología como:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Por alguna razón, hay un bucle de puente, STP está deshabilitado o alguien aplicó un filtro en el lugar incorrecto o similar.

La PC A quiere comunicarse con la PC B. Primero es ARP para el MAC de la PC B, el destino es una transmisión con MAC ffff.ffff.ffff. Entonces el marco va a SW1 y SW3. El SRC MAC es la PC A. SW1 luego inunda la trama hacia SW3 y SW3 inundará la trama que viene de SW2 a SW1.

SW1 y SW3 aprendieron el MAC de la PC A cuando entró el primer cuadro. Cuando el segundo entra desde la dirección opuesta, tiene que volver a aprenderlo. Debido a que estos eventos ocurren tan rápido y repetidamente, verá mensajes de registro quejándose del aleteo de MAC. Algo así como "MAC FLAP 0000.0000.0001 está aleteando entre Gi0 / 24 y Gi0 / 23". Esta es una buena señal de que tienes un bucle.

Lo que podría hacer entonces es intentar rastrear este MAC. Intente buscar en la caché ARP de un dispositivo en la misma subred y ver qué IP tiene este dispositivo. Entonces, con el MAC, puede intentar rastrearlo con sh mac-address-table o con el IP, tal vez tenga una lista con todas las IP y dónde están conectadas.

Si el host obtiene una dirección IP de un servidor DHCP, también puede intentar encontrar de dónde viene el host. Si tiene la opción 82 habilitada, sería de gran ayuda.

Otros signos son que el CLI será muy lento. La carga de la CPU será muy alta. Los conmutadores hacen casi todo en ASIC, por lo que si un conmutador tiene una carga de CPU superior al 50%, probablemente no sea bueno. Debe implementar la supervisión SNMP y observar una alta carga de CPU. Busque también los mensajes de solapa MAC. Si los interruptores tienen un bucle, los LED probablemente parpadearán como locos.

Cosas que podría hacer para protegerse contra los bucles:

• Habilitar STP! (duh)
• Monitoreo SNMP de carga de CPU
• Habilitar capturas SNMP para ciertos eventos como cambios de topología STP
• Habilite el control de tormentas en los puertos para limitar la transmisión
• No abarque demasiado sus VLAN en su topología L2
• Habilite la seguridad del puerto y limite el número de direcciones MAC por puerto
• Habilite Option82 si ejecuta DHCP

Uno de mis usuarios recientemente tomó prestado un interruptor de escritorio del escritorio de alguien. Al regresar el interruptor, enchufaron todos los extremos de Ethernet sueltos que estaban cerca. Uno de esos cables fue a la red y otro era dos extremos del mismo cable. El conmutador de escritorio se conectó a la red y también se conectó a sí mismo. El conmutador no tenía STP, por lo que las transmisiones provenientes de la red se conectarían en el otro cable en ambas direcciones. Por supuesto, cada vez que se recibe una transmisión en los puertos en bucle, se vuelve a replicar en la red. Enloqueció a HSRP y, debido al mal diseño, también provocó fallas de adyacencia de OSPF en todo el campus.

La primera indicación del problema fue un macflap reenviado a mi correo electrónico. Esto inmediatamente nos llevó al armario de cableado correcto. A partir de ahí, fue un proceso de eliminación basado en LED de puertos, pps de interfaz y registros. No hace falta decir que desde entonces he vuelto a diseñar todo el campus. La mejor medida preventiva es probablemente bpduguard. Desde entonces he implementado la función y fue bastante simple. Obtener ese syslog errdisable en mi correo electrónico es nada menos que felicidad.

Con la mayoría de los equipos, la CPU dispara al 100% y lo único que puede hacer es romper las conexiones físicas redundantes. Una vez que la CPU se calme, puede volver a conectar los enlaces uno por uno y ver cuál causa el bucle.

Para chasis grandes (como un 6500), tuve que extraer todas las cuchillas y volver a enchufarlas de una en una. Una vez que descubrí qué blade, tuve que extraer todos los enlaces individuales (16 GBIC) y volver a colocarlos en uno a la vez. Nunca es divertido

Algunos equipos más modernos tienen una CPU protegida que debería hacer que sea más fácil tratar con ellos; aún puede interactuar con la caja. En ese momento, es posible observar los contadores de tráfico y determinar el enlace que funciona mal.

Recientemente comencé en una compañía donde usan límites de transmisión en cada puerto. Si un puerto pasa> 5% de su capacidad cuando se transmite, el conmutador lo pone en ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Esto ha salvado la vida cuando un grupo tiende a conectar dispositivos que conectan las redes inalámbricas a la LAN.

Aunque para su pregunta real, siempre he encontrado que sea manual.

para iOS:

Probablemente tendrá direcciones MAC aleteando entre puertos ... busque MAC_MOVE_NOTIFICATIONerrores (o similares) en:

sh logg

Ahora para encontrar el puerto:

sh int g0/1 controller

buscar fuera de lo común Multicasty los Broadcastnúmeros. Cualquier colisión es una mala señal.

Por último, pero no menos importante, no puede iniciar sesión, porque la CPU está activada :)

sh proc cpu

¿Cómo va el cambio aquí? Si solo se trata de un interruptor L2, no querrás nada por encima de ~ 10%

En el caso de que no haya administrado, o la equivalencia de no administrado (falta de detalles de inicio de sesión, o conocimiento del sistema operativo del interruptor, etc.), interruptores y un bucle de puente, describo cómo haría para encontrar el bucle manualmente. Esto también aborda el fondo fundamental de la pregunta original, "usted no tiene STP".

El algoritmo básico para localizar este bucle de falla es similar a STP, excepto que no tiene acceso para enviar BPDU con ID de puerto.

• Primero, conecte un dispositivo con capacidad de descarga / rastreo de paquetes a un puerto en uno de los conmutadores. Este dispositivo ahora se ha convertido en el dispositivo raíz de su árbol.
  • Si tiene que localizar fallas en múltiples ubicaciones, por ejemplo, en un "campus" o similar, puede ganar al iniciar sesión de forma remota con un cliente ssh portátil en la máquina de descarga de paquetes.
    • Yo personalmente usaría mi computadora portátil Linux con una conexión a Internet con tcpdump en una pantalla y ssh en ella desde, por ejemplo, ipad o teléfono.
  • Si no puede iniciar sesión de forma remota, use un amigo para monitorear visualmente el tcpdump, que probablemente se está inundando a la velocidad del enlace, lo que hace que sea fácil notar una diferencia cada vez que se desconecta el camino hacia el dispositivo de origen del bucle.
• A continuación, tendrá que recrear esencialmente un árbol, comenzando desde su conmutador raíz.
  1. Y debido a que puede tener el escenario donde tiene múltiples enlaces de bucle que se alimentan en su dispositivo raíz, debe comenzar eliminando todos los puertos conectados simultáneamente a la vez.
  2. Vuelva a conectar los puertos uno por uno y si en algún momento vuelve a aparecer la ráfaga de paquetes, siga este puerto hasta el conmutador conectado en el otro extremo.
  3. Repita el paso 1, hasta que encuentre los puertos en bucle y no pueda iterar más abajo en su árbol manual.
  4. Una vez resuelta la situación del bucle en este conmutador, regrese al conmutador anterior en el árbol y reanude el paso 2. Esta recursión continúa hasta que el cable final se ha vuelto a conectar en su conmutador raíz.

Esta es una búsqueda manual completamente exhaustiva para puertos en bucle.

Por lo general, solo habrá un par de puertos en bucle, lo que significa que la búsqueda exhaustiva y segura con eliminar primero todos los puertos conectados (enlace) y luego volver a conectarlos uno por uno es innecesario. Si solo hay un par de puertos en el 'árbol' en bucle, puede encontrarlo simplemente desconectando un puerto a la vez.

Sin embargo, el método o algoritmo "a prueba de fallas" general se convierte en lo que describí anteriormente.

Ay. Pero bueno, puedo pensar en dos formas en que iría en esto ...

Eyeball it: si los conmutadores tienen indicadores de puerto, debería poder observar qué puertos son los más activos. Esos son los que hay que empezar a mirar al principio. Con suerte, los cables están etiquetados para que pueda buscar el fruto de encontrar dos puertos ocupados, en dos conmutadores con el mismo cable.

Supervisión de SNMP: si tiene estadísticas de uso de SNMP (o similar), busque el conmutador más activo y los puertos más ocupados. Entonces ve a mirar los cables.

... si tiene cables sin etiquetar, comience a rastrear y etiquetar como parte de su verificación de los puertos más ocupados.

Voy a responder a esta pregunta basándome en el entendimiento de que hay una interrupción total para el dominio de capa 2 en cuestión, y que no tiene acceso de administración porque todas las CPU están vinculadas.

La mejor manera de solucionar un bucle de puente es comenzar a desconectar los enlaces ascendentes hasta que desaparezca. Supongamos que tiene una capa de acceso conmutada estándar con todos los conmutadores de acceso conectados a un par de conmutadores de distribución. Vaya al primer interruptor de acceso y desconecte los enlaces ascendentes, si los LED de los puertos de interruptores dejan de funcionar, no es ese interruptor, vuelva a enchufarlo y vaya al siguiente. Repita hasta que llegue a un interruptor donde haya desconectado los enlaces ascendentes y los LED continúen parpadeando rápidamente, este es su interruptor con el bucle.

Ahora comience el proceso de desconexión en los puertos del usuario final hasta que los LED se calmen, cuando lo hagan, lo último que desconectó fue el puerto con problemas, rastree el cable y castigue al usuario de manera adecuada.

Para ser honesto, si se conectó remotamente (o mediante un cable de consola) al dispositivo, notará que es muy lento, habrá un retraso desde el momento en que escribe hasta las letras que aparecen en la CLI.

Si se trata de un conmutador de Cisco, dos fáciles son mirar las estadísticas de la interfaz, estará en uso al 100% (o 255/255), constantemente. En mis años de tratar con conmutadores, todavía no he visto un puerto que alcance el 100% de uso. Aparte de eso, verifique el uso de la CPU (generalmente "muestre el historial de la CPU del proceso"), las interfaces en bucle generalmente afectarán su CPU con bastante fuerza a menos que esté ejecutando un interruptor de gama alta.

¡STP realmente debería estar habilitado!

Tuve este problema en una red en el otro extremo de los EE. UU. Y tuve que ayudar de forma remota a algunos analistas de nivel uno a través del teléfono y mi enlace a su sitio. El problema se complicó aún más por el hecho de que tenían varias marcas de conmutadores que habían agregado lentamente a la red a lo largo de los años. Cuando trasladaron la oficina, marcaron a dónde iba cada puerto, luego volvieron a conectar todo exactamente de la misma manera en la nueva oficina y comenzaron todo. No hace falta decir que el puñado de interruptores que tenían un árbol de expansión que funcionaba no convergían de la misma manera y tenían todo tipo de bucles y problemas. Cuando terminé de arreglar, se descubrió que no menos de tres conmutadores no administrados estaban conectados en bucles con el resto de la infraestructura.

La forma en que pude rastrear cada uno de los conmutadores no administrados fue mediante el uso de una herramienta llamada nedi (en los conmutadores que se pudieron administrar, habilité lldp / cdp). Primero generé mapas con nedi. Luego, en las áreas donde el mapa mostraba conexiones de un interruptor a otro y luego nuevamente al mismo interruptor, hice que el técnico de la red local rastreara la línea manualmente. O apagué manualmente las interfaces involucradas con el bucle o hice que la persona en el lugar desconectara los cables. Al final pude hacer que la red funcionara como debería, a pesar de todos los cambios de marca.

Una cosa que se puede hacer aquí es ver qué máquinas están conectadas al conmutador mediante los comandos show cdp neighboro show lldp neighbor.

Si el comando de protección BPDU no se está utilizando y alguien conecta un conmutador falso con menor prioridad (o una dirección MAC anterior), el nuevo dispositivo se negociará como raíz del árbol de expansión, lo que seguramente causará un problema.

En mi experiencia, siempre ha sido el cable que acabo de enchufar, o no cerrar, o agregar al canal de puerto. Más difícil es cuando alguien más lo hizo y no confiesa de inmediato.

Determinar un bucle realmente depende de la marca de interruptor que tenga. Por ejemplo, en un conmutador Extreme, puedo ejecutar elrp-client en una VLAN y el conmutador básicamente enviará una trama de difusión en todos los puertos para esa VLAN y veré si regresa por alguno de ellos, si es así, me dice qué puerto (s) en que se volvió a recibir la trama, revelando así los candidatos de bucle

En un Cisco, puede habilitar el control de tormentas, que es un poco más un instrumento contundente, ya que básicamente bloqueará el puerto por un período de tiempo hasta que se borre el estado (o borre el estado errdisable), en general, sin embargo, este tipo De hecho, solo es relevante cuando está utilizando conmutadores Cisco en una topología mixta de dispositivos que no hacen un árbol de expansión ni reenvían BPDU.

Sin duda, el enfoque más rápido que he encontrado es monitorear las velocidades de paquetes / seg de las interfaces. Una interfaz de presentación rápida con el filtro CLI apropiado enumerará cada interfaz y la velocidad de paquete / segundo. Para encontrar la fuente del bucle, busque la única interfaz con una alta tasa de ENTRADA de paquetes / seg. Dentro de un entorno empresarial típico, con perfiles de utilización típicos, funciona siempre sin fallas. En un 6500 con muchas interfaces, no lleva mucho tiempo detectar la fuente ...

Durante el bucle, para una gran cantidad de tráfico de difusión (por ejemplo, Solicitud ARP) en la estación final también puede aumentar la carga en la CPU (por ejemplo, si está utilizando una tarjeta realtek barata de 100Mbit / s que calcula una suma de verificación en la CPU). Como es físicamente posible encontrar un bucle si el cable está desconectado, el enlace se pierde inmediatamente en 2 puertos.