Rastreando mensagens TCN no STP

12

Temos cerca de 20 vlans em uma rede L2 executando o Rapid PVST +, em que a ponte raiz é uma pilha dos switches 3750 da Cisco. Estou um pouco intrigado com o número de notificações TCN que recebo no switch.

A pilha 3750 é a raiz de todas as VLANs e recebe notificações de TCN diariamente (às vezes mais, às vezes um pouco menos). Ele recebe os TCNs ao mesmo tempo e na mesma porta para todas as VLANs. Quando rastreio a origem desses TCNs show spanning-tree detail | inc ieee|occurr|from|is exec, termino em um switch (switch-b) com apenas 5 troncos configurados e sem portas de acesso.

Não consigo corresponder a um evento como um link neste comutador que sobe ou desce ao mesmo tempo em que os TCNs são recebidos. Quando emito o comando acima nessa opção, os resultados informam que a última alteração de topologia ocorreu há muito mais tempo.

Minhas conclusões:

O TCN enviado deve ser acionado por um evento em um link de tronco ou em um switch inteiro, porque todas as VLANs receberam a notificação de alteração de topologia. Deve ser algo local no switch-b.

Qual pode ser o motivo para originar esses TCNs? Os 5 links de tronco não mudaram de estado. Ele não pode avançar ainda mais porque a última alteração de topologia no switch-b não corresponde à última alteração de topologia no núcleo. A última alteração de topologia no switch-b ocorreu há muito mais tempo.

Alguma ideia?

— user209
fonte

Você chegou mais longe com isso? Eu estou vendo semelhante. Suspeito que os TCNs sejam enviados em troncos, mesmo que não participem da VLAN, tornando mais difícil rastrear. Pior ainda parecem ser encaminhadas através de switches quando a chave em si não está participando de que VLAN

Na verdade ainda não, encontrei alguns switches com portas de acesso sem portfast. Mas essa ainda não é uma explicação real para obter mudanças de topologia em todas as vlans ao mesmo tempo ... Mas, por estranho que pareça, tenho muito menos tcn nesses últimos dias. É por isso que meu foco está em outros assuntos com mais prioridade. Eu acho que a resposta do dockmaster simplesmente fazendo alguma depuração é boa. Traço tão perto da fonte e, em seguida, fazer alguma depuração ...

— user209

12

Você deve poder simplesmente depurar os TCNs. No meu caso, depurei-os recentemente usando debug spann mstp tc(enquanto executo o MSTP), mas também usando debug spanning-tree events você os 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

— Dockmaster
fonte

0

só tive os mesmos problemas ... e se você executar o portfast em todas as suas portas de acesso, ele não enviará mensagens TCN e você não receberá a mensagem TCN e não será enviada a todos os comutadores .... se você não ativar portfast em todas as suas portas de acesso e um dispositivo estiver inativo, ele enviará uma mensagem TCN e liberará arp em todos os seus switches, eles terão que aprender o MACS novamente.

— Tony
fonte