RSTP Topology change propagation

Unknown

I am having an discussion on RSTP with a peer about TC updates. They said if the port is not configured as an edge port then whatever its connected switch or non switch device(pc) can trigger an TC update. I'm under the impression only STP participating ports will trigger the TC update not any port not configured as an edge port.

I know the way TC updates work on non edge ports if there is a port up or down it sends out a TC update which triggers the rest of the switches to purge all mac-address to update the cam table on all ports except for the on it received the update. I took at look at the docs it does state all ports but I understood it as all ports participating in STP not literally all ports.

For example a switchport that is not configured as an edge port connected to a pc. It doesn't make sense if a pc is restarted and that link is not configured as an edge port but since the state of the port changed it will trigger an update.
I have to run a debug on a switch to prove it because I don't want to believe it as it doesn't make sense lol.

Question: Does RSTP TC updates report changes for only STP participating ports or ALL ports that are not configured as an edge port?

Danielh22185

Basically an edge port will never be source of a TC notification. It's settings will act as a port-fast enabled port for a host. However, it CAN receive BPDUs if a BPDU sending device is plugged in. At that point it will lose its "edge" port status and become a normal STP port.

So if the port should never become an STP port it should be configured with BPDU guard as well.

Danielh22185

For fun an for my own review purposes because I am studying Switch I went ahead and labbed this:

1.) So here I first configured eth1/1 as an access port with portfast enabled with rapid spanning tree to make it an edge port.



IOU3(config-if)#do sh run int eth1/1
Building configuration...


Current configuration : 117 bytes
!
interface Ethernet1/1
switchport access vlan 10
switchport mode access
duplex auto
spanning-tree portfast
end




IOU3(config-if)#do show span vlan 10


VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 32778
Address aabb.cc00.0200
Cost 3100
Port 2 (Ethernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec


Bridge ID Priority 49162 (priority 49152 sys-id-ext 10)
Address aabb.cc00.0400
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
UplinkFast enabled but inactive in rapid-pvst mode


Interface Role Sts Cost Prio.Nbr Type

---

---- ---

---

---

---

Et0/1 Root FWD 3100 128.2 Shr Peer(STP)
Et0/2 Altn BLK 3100 128.3 Shr Peer(STP)
Et1/1 Desg FWD 3100 128.6 Shr Edge


2.) Next I drug in another switch in and simply connected an interface and brought the port up, now you can see the port transitioned to a normal STP port, also interestingly enough the new switch became the Root. As you can see this can be VERY bad if the port isn't protected from BPDUs entering the port.


IOU3(config-if)#do show span vlan 10


VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 32769
Address aabb.cc00.0700
Cost 3100
Port 6 (Ethernet1/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec


Bridge ID Priority 49162 (priority 49152 sys-id-ext 10)
Address aabb.cc00.0400
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
UplinkFast enabled but inactive in rapid-pvst mode


Interface Role Sts Cost Prio.Nbr Type

---

---- ---

---

---

---

Et0/1 Desg FWD 3100 128.2 Shr Peer(STP)
Et0/2 Desg LRN 3100 128.3 Shr Peer(STP)
Et1/1 Root FWD 3100 128.6 Shr Peer(STP)





* The new switch took over the root status for IOU3's perspective of vlan10 however it doesn't actually know vlan10, it just interprets its only connection as the default vlan1. However the main take away is the edge port transitioned to an STP port and really messed up my STP topology. Had this been a live network i'd be polishing my resume.

IOU7(config)#int eth1/1
IOU7(config-if)#no shut
IOU7(config-if)#do show span


VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address aabb.cc00.0700
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec


Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address aabb.cc00.0700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec


Interface Role Sts Cost Prio.Nbr Type

---

---- ---

---

---

---

Et0/0 Desg FWD 100 128.1 Shr
Et0/1 Desg FWD 100 128.2 Shr
Et0/2 Desg FWD 100 128.3 Shr
Et0/3 Desg FWD 100 128.4 Shr
Et1/0 Desg FWD 100 128.5 Shr
Et1/1 Desg FWD 100 128.6 Shr
Et1/2 Desg FWD 100 128.7 Shr
Et1/3 Desg FWD 100 128.8 Shr
Et2/0 Desg FWD 100 128.9 Shr
Et2/1 Desg FWD 100 128.10 Shr
Et2/2 Desg FWD 100 128.11 Shr
Et2/3 Desg FWD 100 128.12 Shr
Et3/0 Desg FWD 100 128.13 Shr
Et3/1 Desg FWD 100 128.14 Shr
Et3/2 Desg FWD 100 128.15 Shr
Et3/3 Desg FWD 100 128.16 Shr

Silverymoon

Just started studying this, edge ports don't send out TCN messages but if they receive a BPDU they lose edge port status. The switch that sees the port go the a forwarding state sends out the BPDU with the TC bit set and not the root bridge. A switch announces a topology change by sending BPDUs with the TC bit set out all nonedge designated ports. This way, all he neighbors are informed about the topology change and so they can correct their bridging tables.

Note Normally with STP the switch sends the TCN to the root that then sends a TCA back. Then the root bridge then sends a BPDU with the TC bit set to inform every switch to flush there mac address tables. All mac address in the CAM table are set to timeout in 15s.

RSTP no longer uses the specific TCN BPDUs unless a legacy bridge needs to be notified.

With RSTP, when a switch receives a BPDU with the TC bit set from a neighbor, it clears the mac addresses on all ports but the port it receives the topology change. The switch also receives BPDUs with the TC bit set on all designated ports and the root port.

In just a few seconds or a small multiple of hello times, most of the entries in the CAM tables of the entire network flush.

Note: With STP, indirect topology changes take 50 seconds and direct topology changes take 30 seconds.

RSTP has another link type called a alternate/backup port which discards. The states are different from STP, ports move from discarding to Learning and then forwarding. All ports types accept and process BPDU frame in all port states. For RSTP a topology change is only when a nonedge port transitions to the forwarding state. This means that a loss of connectivity is not considered as a topology change any more, contrary to STP.

Alternate port: The alternate port is a switch port that offers an alternate pah towards the root bridge. It assumes a discarding state in an active topology. The alternate port makes a transition to a designated port if the current designated path fails.

Legacy User

Hey Daniel,

Thanks for your reply. My query was in regards to an end device (pc perhaps) was placed on a port that was not configured as a edge port. Whether or not that port will generate a TC-bit BPDU update if that pc was shutdown or restarted. I set up a physical lab last night on it with a laptop connected to a port that was not configured as an edge port and ran a packet capture and indeed it did send out an update which cleared the cam table. Did not know that a non switch would trigger that result but I guess thats the con with RSTP.

@Silverymoon thanks for the reply it sounds like you literally just learned it lol. Good job and keep it up!

Danielh22185

dmarcisco wrote: »

Hey Daniel,

Thanks for your reply. My query was in regards to an end device (pc perhaps) was placed on a port that was not configured as a edge port. Whether or not that port will generate a TC-bit BPDU update if that pc was shutdown or restarted. I set up a physical lab last night on it with a laptop connected to a port that was not configured as an edge port and ran a packet capture and indeed it did send out an update which cleared the cam table. Did not know that a non switch would trigger that result but I guess thats the con with RSTP.

@Silverymoon thanks for the reply it sounds like you literally just learned it lol. Good job and keep it up!

Right if it was non-edge its considered a spanning-tree port so any status change in the port can trigger a TC.

Legacy User

Yea I found it crazy how a non switch device can trigger a TC update. It shows how crucial it is to have a proper design with RSTP.

Silverymoon

You just use portfast if you are not using RST. If a end host disconnects and the port goes down a TCN is generated with normal STP but this does nothing other than east up CPU time. It only becomes an issue if there are lots of hosts connecting and disconnecting.

In the RST lab attempt above the links are shared links because IOU sucks. Shared links are half duplex links normally. You should note that designated ports make use of the link type parameter. Rapid transition to the forwarding state for the designated port occurs only if the link type parameter indicates point-to-point. Change it with the spanning-tree link-type command. Or if the link is not full duplex then force full duplex. You can shutdown a link and debug the events to see if everything is working. Use debug spanning-tree events

Danielh22185

Silverymoon wrote: »

You just use portfast if you are not using RST. If a end host disconnects and the port goes down a TCN is generated with normal STP but this does nothing other than east up CPU time. It only becomes an issue if there are lots of hosts connecting and disconnecting.

In the RST lab attempt above the links are shared links because IOU sucks. Shared links are half duplex links normally. You should note that designated ports make use of the link type parameter. Rapid transition to the forwarding state for the designated port occurs only if the link type parameter indicates point-to-point. Change it with the spanning-tree link-type command. Or if the link is not full duplex then force full duplex. You can shutdown a link and debug the events to see if everything is working. Use debug spanning-tree events

The purpose of the lab above really was just to demonstrate how edge ports can lose their edge status if not protected from doing so. Thanks though for the info about IOU link behavior I wasn't quite sure why they were showing as shared either.