Unexpected STP Topology Change

[jaime.mendoza11]

I have a 6509 acting as a distribution switch, one of the downliks is an old FO to a small site which every now and then has a small interruption that cause the whole network to recalculate the spanning tree, so I disabled stp on the access switch (Yeah I know cisco blasphemy) and set the link in the 6509 with bpdu-filter. Despite this, the 6509 keeps recalculating the stp (not very often really) and says the topology change came from the interface with bpdu filter and a switch (huawei 5720) on the other side with no stp.

Why does the 6509 recalculate STP when it is not supposed to process BPDU packets from that interface, which shouldn't be receiving bpdu-tcn packets and the far end switch has no STP protocol active?

Thanks in advance.

Cisco 6509

switch# show spanning-tree detail | in ieee|from|occur|is exec
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 2126 last change occurred 02:59:48 ago from GigabitEthernet7/5
VLAN0505 is executing the ieee compatible Spanning Tree protocol
Number of topology changes 274 last change occurred 02:59:48 ago from GigabitEthernet7/5

......

interface GigabitEthernet7/5
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
spanning-tree bpdufilter enable

Switch Huawei:

<Switch >display stp topology-change
Info: The protocol is disabled.

[balaji.bandi]

which switch is the root bridge for that VLAN keep changing, ? make sure cisco act as root bridge by setting priority so other can not elect as root bridge.

do you see any physical issue ?

[jaime.mendoza11]

Thank You for Your reply:

Cisco is running pvst, so for some vlans the 6500 is the root for other is not, for that particular vlan the root comes "upstream" from a core switch (with the lowest priority in the network).

There is, apparently, a small physical issue with the link, but the point is that in the event of those occasional LOS the Cisco should not recalculate the stp because ith has "bpdu filter" on that interface, I believe. Should I configure "portfast edge" on that trunk?

[JELA · Accepted solution]

A topology change (TC) is generated by a switch when one of the following condition occurs:
- An interface that was previously in the spanning-tree FWD state goes DOWN

- When a port transition to the FWD state

The STP BPDU Filter feature ask your switch to stop sending/receiving BPDU.

It does not exclude your interface from the STP election.

In your case, it means that when you connect Gi7/5 interface, it will transition through the LRN state after 15s then FWD state after 15s THEN your switch will create a Topology change.

As you previously guess, the only way to modify this behavior is to rely on the "portfast trunk" feature.

This will avoid your interface to create a TC once is transition between states.

[jaime.mendoza11]

Thank You for your fast and accurate response.

[jaime.mendoza11]

The en of the matter:

RIAMA_003_CCCN(config-if)#spanning-tree portfast edge
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on GigabitEthernet7/5 but will only
have effect when the interface is in a non-trunking mode.

Thanks anyway :)

[balaji.bandi]

yes portfast will be good idea, this is based in the informaiton provide.

so next time when the link fails it will not go in to that process.