Seguimiento de mensajes TCN en STP


12

Tenemos alrededor de 20 vlans en una red L2 que ejecuta Rapid PVST +, donde el puente raíz es una pila de conmutadores 3750 de Cisco. Estoy un poco desconcertado por la cantidad de notificaciones TCN que recibo en el switch.

La pila 3750 es la raíz de todas las VLAN y recibe notificaciones TCN a diario (a veces más, a veces un poco menos). Recibe los TCN al mismo tiempo y en el mismo puerto para todas las VLAN. Cuando remonto de dónde provienen estos TCN show spanning-tree detail | inc ieee|occurr|from|is exec, termino en un switch (switch-b) con solo 5 troncales configurados y sin puertos de acceso.

No puedo hacer coincidir un evento como un enlace en este interruptor que sube o baja al mismo tiempo que se reciben los TCN. Cuando publico el comando anterior en este interruptor, los resultados me dicen que el último cambio de topología fue mucho más atrás.

Mis conclusiones:

El TCN enviado debe ser activado por un evento en un enlace troncal o un conmutador completo porque todas las VLAN recibieron la notificación de cambio de topología. Debe ser algo local en el switch-b.

¿Cuál puede ser la razón para originar estos TCN? Los 5 enlaces troncales no cambiaron su estado. No puede ir más abajo porque el último cambio de topología en el interruptor-b no coincide con el último cambio de topología en el núcleo. El último cambio de topología en el interruptor-b es mucho más largo.

¿Alguna idea?


¿Llegaste más lejos con esto? Estoy viendo algo similar Sospecho que los TCN se envían en troncales incluso si no participan en la VLAN, lo que dificulta el rastreo. Peor aún, parecen reenviarse a través de los conmutadores cuando el conmutador en sí no participa en esa VLAN

En realidad todavía no, encontré algunos conmutadores con puertos de acceso sin portfast. Pero eso todavía no es una explicación real para revelar cambios de topología en todos los planos al mismo tiempo ... Pero lo suficientemente extraño es que tengo mucho menos tcn en estos últimos días. Es por eso que mi enfoque está en otros asuntos con más prioridad. Creo que la respuesta de dockmaster simplemente haciendo un poco de depuración es buena. Rastree lo más cerca posible de la fuente y luego realice alguna depuración ...
user209

Respuestas:


12

Debería poder simplemente depurar los TCN. En mi caso, los depuré recientemente usando debug spann mstp tc(mientras ejecuto MSTP), pero también usando debug spanning-tree events los verá:

Jul 10 07:42:18 UTC: STP: VLAN0228 Topology Change rcvd on Gi1/0/9       <<< received
Jul 10 07:42:18 UTC: STP: VLAN0228 sent Topology Change Notice on Po10   <<< forwarded

0

simplemente tuve los mismos problemas ... y si ejecuta portfast en todos sus puertos de acceso, no enviará mensajes TCN y no recibirá el mensaje TCN y no se enviará a todos los conmutadores ... si no habilita portfast en todos sus puertos de acceso y un dispositivo está abajo / arriba enviará un mensaje TCN y vaciará arp en todos sus conmutadores, tendrán que aprender el MACS nuevamente ...

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.