在运行Rapid PVST +的L2网络上，我们大约有20个VLAN，其中的根网桥是Cisco 3750交换机的堆栈。我对在交换机上收到的TCN通知的数量感到有些困惑。

3750堆栈是所有VLAN的根，它每天都接收TCN通知（有时更多，有时少一点）。它同时在所有VLAN的同一端口上接收TCN。当我使用show spanning-tree detail | inc ieee|occurr|from|is exec追溯这些TCN的来源时，我发现只有一台交换机（switch-b），该交换机仅配置了5条中继线，并且没有访问端口。

我无法匹配一个事件，例如在收到TCN的同时此开关上的链接向上或向下的链接。当我在此交换机上发出上述命令时，结果表明最后一次拓扑更改要早得多。

我的结论：

发送的TCN必须由中继链路或整个交换机发生事件，因为所有VLAN都收到了拓扑更改通知。它必须是交换机b上的本地设备。

发起这些TCN的原因可能是什么？ 5个干线链接未更改其状态。它不能再向下游移动，因为switch-b上的最新拓扑更改与核心上的最新拓扑更改不匹配。 switch-b上的最后一个拓扑更改要早得多。

有什么想法吗？

评论

您对此有进一步的了解吗？我看到类似的情况。我怀疑TCN会在中继线上发送出去，即使它们不参与VLAN也是如此，以至于很难追踪。更糟的是，当交换机本身不参与该VLAN时，它们似乎会在交换机之间转发。
其实还没有，我确实找到了一些带有访问端口且没有portfast的交换机。但是，这仍然不是在同时接收所有VLAN上拓扑更改的真正解释。但是，很奇怪的是，最近几天我的确得到了少得多的TCN。这就是为什么我将重点放在其他优先事项上的原因。我认为通过简单地进行一些调试就可以得到Dockmaster的答案。尽可能靠近源进行跟踪，然后进行一些调试...

#1 楼

您应该能够简单地调试TCN。就我而言，我最近使用debug spann mstp tc（在运行MSTP时）调试了它们，但同时也使用debug spanning-tree events
调试了它们，您将看到它们：

#2 楼

只是存在相同的问题...如果在所有访问端口上运行portfast，它将不会发送TCN消息，并且您不会收到TCN消息，也不会发送给所有交换机....如果不启用您所有访问端口上的portfast且设备关闭/启动，它将发送TCN消息并刷新所有交换机上的arp，它们将不得不重新学习MACS...。