Cisco 2960 Portfast ports generate Spanning Tree TCN

ciscocisco-2960spanning tree

We are operating several Cisco 2960S stacks here and, for some time, are experiencing regular Spanning Tree TCNs (Topology Change Notifications).

When using show spanning-tree detail to get to the source of the TCN, they originate from different 2960S stack members.

As the config has been transferred from older switches, the ports are configured as trunks, with the data VLAN being the native VLAN and the VoIP VLANs being included as tagged in the trunk. I know, today the correct configuration would be switchport mode access combined with switchport voice vlan – but at the moment it is at it is.

Part of the problem was based on the fact that some ports were only configured as portfast, not portfast trunk, so this has to be fixed, as the portfast only command is not applied to ports in trunk mode.
However, some ports are configured as portfast trunk, which as of my understanding of Cisco documentation, should avoid generating TCNs on link changes.

Sadly, they do.

Executing show spanning-tree interface Gi1/0/x portfast shows portfast enabled for all VLANs on that interface, but show spanning-tree detail together with show logging shows that these interfaces are indeed the source for the Spanning Tree changes.

It is made sure that there are no "special" devices connected to those ports, just VoIP phones and desktop workstations.

The version run is 12.2(55)SE3, the devices are 2960S-48LPS-L and 2960S-48FPS-L.

Looking for known bugs, there was a bug in a 12.1 release for 3550 switches that caused such behaviour, but this is the wrong device and a much older version, and I guess somebody should have experienced that bug before.

Any idea where to look, what to try?

Best Answer

This post is older in age so I'm not sure if you are still experiencing this problem. I would like to see the documentation you are referring too regarding the portfast trunk command. The portfast trunk configuration should be applied to hosts that you are trunking with, for example an ESX host or a Load Balancer. For switch to switch, this configuration should not be there.

There is a lot of information I would need to see to better understand the topology and what spanning-tree mode you are running in (PVST+, RPVST+ or MST). I suspect from what I've read you are running PVST+. I would like to first start with the output of show spanning-tree vlan x detail and a snippet of this TCN you are seeing. I would also like to see show run | i spanning.

I suspect you may have a port(s) that is flapping and the TCN message should lead us directly to the culprit.

So you have a VoIP phone plugged into a switchport that is configured switchport access vlan and computers/hosts plugged into other switchports with switchport access vlan ? Yeah you know you can set it up for switchport voice vlan. However being setup without the switchport voice vlan, I do not see this being an issue with TCN's.

TCN's are generated when a port transitions from one state to another assuming you are not changing the priority values.

Related Solutions

Cisco – Tracing TCN Messages in STP

You should be able to simply debug the TCNs. In my case I recently debugged them using debug spann mstp tc (as I run MSTP), but also using debug spanning-tree events you will see them:

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

Cisco – Mixing Cisco STP Features: BPDU Guard, BPDU Filter, PortFast and PortFast Trunk

First, like the others have mentioned you have no bridging loop here due to running a Portchannel. That said, running STP is still fine. Let me clear some confusions on how these commands work on Cisco switches.

spanning-tree portfast trunk

This command is supposed to be run on trunk ports towards non bridging devices, such as a server with multiple VLANs or a router. This command should not be run on trunks towards switches because the port will bypass the listening and learning phase which could potentially create a bridging loop.

If you have an interface configured like this:

interface x/x
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable

BPDU guard will never kick in because BPDU filter is filtering both the outgoing and incoming BPDUs. This also means that the port can never lose its Portfast status which it would normally do if BPDUs were received inbound. If you remove the filter then BPDU guard will kick in and shutdown the port if a BPDU is received. This is done before the port can lose its Portfast operatational state so basically the port will always operate in Porfast operational mode.

If you apply the commands globally instead:

spanning-tree portfast default
spanning-tree portfast bpdufilter default
spanning-tree portfast bpduguard default

The first command enables Portfast on all access ports.

When BPDU filter is applied globally, the difference is that it sends out 11 BPDUs before going silent. Because normally one BPDU is sent out every 2 seconds and the default MaxAge is 20 seconds that means that if there is a device at the other end that can process BPDUs, at least one BPDU would be received when the old BPDU (if there was one) has expired.

If a BPDU is received inbound when BPDU filter is applied globally then the port stops filtering and it will lose its Portfast status.

The BPDU guard default command will only apply to ports that are in a Portfast operational state.

If you combine these three commands together then what will happen is that when a BPDU is received the port loses its BPDU filter, BPDU guard can then kick in. The port will never lose its Portfast operational state because the port is shutdown before.

So you see when applied to the interface BPDU guard can never kick in but if you apply it globally it can.

If you run just Portfast globally and BPDU filter globally then if a BPDU comes in, the port loses the filter and loses the Portfast operational state and will operate as a normal port.

Best Answer

Related Solutions

Cisco – Tracing TCN Messages in STP

Cisco – Mixing Cisco STP Features: BPDU Guard, BPDU Filter, PortFast and PortFast Trunk

Related Topic