Switch Topology Changes

Switch Topology Changes

To announce a change in the active network topology, switches send a TCN BPDU. Table 2.10 shows the format of these messages.

Table 2-10 Topology Change Notification BPDU Message Content

Field Description	Number of Bytes
Protocol ID (always 0)	2
Version (always 0)	1
Message Type (Configuration or TCN BPDU)	1

A topology change occurs when a switch either moves a port into the Forwarding state or moves a port from the Forwarding or Learning states into the Blocking state. In other words, a port on an active switch comes up or goes down. The switch sends a TCN BPDU out its root port so that, ultimately, the root bridge receives news of the topology change. Notice that the TCN BPDU carries no data about the change but informs recipients only that a change has occurred. Also notice that the switch will not send TCN BPDUs if the port has been configured with PortFast enabled.

The switch continues sending TCN BPDUs every hello time interval until it gets an acknowledgment from its upstream neighbor. As the upstream neighbors receive the TCN BPDU, they propagate it on toward the root bridge and send their own acknowledgments. When the root bridge receives the TCN BPDU, it also sends out an acknowledgment. However, the root bridge sets the Topology Change flag in its Configuration BPDU, which is relayed to every other bridge in the network. This is done to signal the topology change and cause all other switches to shorten their switch table aging times from the default (300 seconds) to the forward delay value (default 15 seconds).

This condition causes the learned locations of MAC addresses to be flushed out much sooner than they normally would, easing the bridge table corruption that might occur because of the change in topology. However, any stations that are actively communicating during this time are kept in the bridge table. This condition lasts for the sum of the forward delay and the max age (default 15 + 20 seconds).

The theory behind topology changes is fairly straightforward, but it is often difficult to grasp how a working network behaves during a change. For example, suppose that you have a Layer 2 network (think of a single VLAN or a single instance of STP) that is stable and loop free. If a switch uplink suddenly failed or a new uplink was added, how would the various switches in the network react? Would users all over the network lose connectivity while the STP “recomputes” or reconverges?

Examples of different types of topology changes are presented in the following sections, along with the sequence of STP events. Each type has a different cause and a different effect. To provide continuity as the STP concepts are presented, the same network previously shown in Figures 2.3 through 2.5 is used in each of these examples.

Direct Topology Changes

A direct topology change is one that can be detected on a switch interface. For example, if a trunk link suddenly goes down, the switch on each end of the link can immediately detect a link failure. The absence of that link changes the bridging topology, so other switches should be notified.

Figure 2.11 shows a network that has converged into a stable STP topology. The VLAN is forwarding on all trunk links except port gi1/0/2 on Switch C, where it is in the Blocking state.

This network has just suffered a link failure between Switch A and Switch C. The sequence of events unfolds as follows:

1.Switch C detects a link down on its port gi1/0/1; Switch A detects a link down on its port gi1/0/2.

2.Switch C removes the previous “best” BPDU it had received from the root over port gi1/0/1. Port gi1/0/1 is now down so that BPDU is no longer valid. Normally, Switch C would try to send a TCN message out its root port, to reach the root bridge. Here, the root port is broken, so that is not possible. Without an advanced feature such as STP UplinkFast, Switch C is not yet aware that another path exists to the root. Also, Switch A is aware of the link down condition on its own port gi1/0/2. It normally would try to send a TCN message out its root port to reach the root bridge. Here, Switch A is the root, so that is not really necessary.

3.The root bridge, Switch A, sends a Configuration BPDU with the TCN bit set out its port gi1/0/1. This is received and relayed by each switch along the way, informing each one of the topology change.

4.Switches B and C receive the TCN message. The only reaction these switches take is to shorten their bridging table aging times to the forward delay time. At this point, they do not know how the topology has changed; they only know to force fairly recent bridging table entries to age out.

5.Switch C basically just sits and waits to hear from the root bridge again. The Configuration BPDU TCN message is received on port gi1/0/2, which was previously in the Blocking state. This BPDU becomes the “best” one received from the root, so port gi1/0/2 becomes the new root port. Switch C now can progress port gi1/0/2 from Blocking through the Listening, Learning, and Forwarding states.

Figure 2.11 Effects of a Direct Topology Change

As a result of a direct link failure, the topology has changed and STP has converged again. Notice that only Switch C has undergone any real effects from the failure. Switches A and B heard the news of the topology change but did not have to move any links through the STP states. In other words, the whole network did not go through a massive STP reconvergence.

The total time that users on Switch C lost connectivity was roughly the time that port gi1/0/2 spent in the Listening and Learning states. With the default STP timers, this amounts to about two times the forward delay period (15 seconds), or 30 seconds total.

Indirect Topology Changes

Figure 2.12 shows the same network as Figure 2.11, but this time the link failure indirectly involves Switches A and C. The link status at each switch stays up, but something between them has failed or is filtering traffic. This could be another device, such as a service provider’s switch, a firewall, and so on. As a result, no data (including BPDUs) can pass between those switches.

Figure 2.12 Effects of an Indirect Topology Change

STP can detect and recover from indirect failures, thanks to timer mechanisms. The sequence of events unfolds as follows:

1. Switches A and C both show a link up condition; data begins to be filtered elsewhere on the link.

2. No link failure is detected, so no TCN messages are sent.

3. Switch C already has stored the “best” BPDU it had received from the root over port gi1/0/1. No further BPDUs are received from the root over that port. After the Max Age timer expires, no other BPDU is available to refresh the “best” entry, so it is flushed. Switch C now must wait to hear from the Root again on any of its ports.

4. The next Configuration BPDU from the root is heard on Switch C port gi1/0/2. This BPDU becomes the new “best” entry, and port gi1/0/2 becomes the root port. Now the port is progressed from Blocking through the Listening, Learning, and finally Forwarding states.

As a result of the indirect link failure, the topology does not change immediately. The absence of BPDUs from the root causes Switch C to take some action. Because this type of failure relies on STP timer activity, it generally takes longer to detect and mitigate.

In this example, the total time that users on Switch C lost connectivity was roughly the time until the max age timer expired (20 seconds), plus the time until the next Configuration BPDU was received (2 seconds) on port gi1/0/2, plus the time that port gi1/0/2 spent in the Listening (15 seconds) and Learning (15 seconds) states. In other words, 52 seconds elapse if the default timer values are used.

Insignificant Topology Changes

Figure 2.13 shows the same network topology as Figure 2.11 and Figure 2.12, with the addition of a user PC on access layer switch Switch C. The user’s switch port, gi1/0/33/, is just another link as far as the switch is concerned. If the link status goes up or down, the switch must view that as a topology change and inform the root bridge.

Figure 2.13 Effects of an Insignificant Topology Change

Obviously, user ports are expected to go up and down as the users reboot their machines, turn them on and off as they go to and from work, and so on. Regardless, TCN messages are sent by the switch, just as if a trunk link between switches had changed state. To see what effect this has on the STP topology and the network, consider the following sequence of events:

1. The PC on switch port gi1/0/33 is turned off. The switch detects the link status going down.

2. Switch C begins sending TCN BPDUs toward the root, over its root port (gi1/0/1).

3. The root sends a TCN acknowledgment back to Switch C and then sends a Configuration BPDU with the TCN bit set to all downstream switches. This is done to inform every switch of a topology change somewhere in the network.

4. The TCN flag is received from the root, and both Switches B and C shorten their bridge table aging times. This causes recently idle entries to be flushed, leaving only the actively transmitting stations in the table. The aging time stays short for the duration of the Forward Delay and Max Age timers.

Notice that this type of topology change is mostly cosmetic. No actual topology change occurred because none of the switches had to change port states to reach the root bridge. Instead, powering off the PC caused all the switches to age out entries from their bridge or CAM tables much sooner than normal.

At first, this does not seem like a major problem because the PC link state affects only the “newness” of the CAM table contents. If CAM table entries are flushed as a result, they probably will be learned again. This becomes a problem when every user PC is considered. Now every time any PC in the network powers up or down, every switch in the network must age out CAM table entries.

Given enough PCs, the switches could be in a constant state of flushing bridge tables. Also remember that when a switch does not have a CAM entry for a destination, the packet must be flooded out all its ports. Flushed tables mean more unknown unicasts, which mean more broadcasts or flooded packets throughout the network.

Fortunately, Catalyst switches have a feature that can designate a port as a special case. You can enable the STP PortFast feature on a port with a single attached PC. As a result, TCNs are not sent when the port changes state, and the port is brought right into the Forwarding state when the link comes up.