Topology Change Process


If TCN BPDUs are so simple, how then do they play such an important role? Before answering that question directly, consider a subtle side effect of topology changes. The discussion that follows refers to the scenario illustrated in Figure 6-17.

Figure 6-17. TCN BPDUs are Required to Update Bridge Tables More Quickly

graphics/06fig17.gif

Suppose that Host-D is playing Doom with Host-E. As discussed earlier in Figure 6-12, the traffic from Host-D flows directly through Cat-B to reach Host-E (Step 1). Assume that the Ethernet transceiver on Cat-B:Port-1/2 falls out (Step 2). As discussed earlier, Cat-C: Port 1/2 takes over as the Designated Port in 50 seconds. However, without TCN BPDUs, the game continues to be interrupted for another 250 seconds (4 minutes, 10 seconds). Why is this the case? Prior to the failure, the bridging table entries for MAC address EE-EE-EE-EE-EE-EE on all three switches appeared as documented in Table 6-7.

Table 6-7. Bridge Table Values Before Topology Change

Bridge Table

Port Associated with EE-EE-EE-EE-EE-EE

Cat-A

Port 1/1

Cat-B

Port 1/2

Cat-C

Port 1/1

In other words, all frames destined for Host-E before the failure had to travel counterclockwise around the network because Cat-C:Port-1/2 was Blocking. When Cat-B:Port-1/2 fails, Cat-C:Port-1/2 takes over as the Designated Port. This allows traffic to start flowing in a clockwise direction and reach Host-E. However, the bridging tables in all three switches still point in the wrong direction. In other words, it appears to the network as if Host-E has moved and the bridging tables still require updating. One option is to wait for the natural timeout of entries in the bridging table. However, because the default address timeout is 300 seconds, this unfortunately results in the 5-minute outage calculated previously.

TCN BPDUs are a fairly simple way to improve this convergence time (and allow us to continue playing Doom sooner). TCN BPDUs work closely with Configuration BPDUs as follows:

  1. A bridge originates a TCN BPDU in two conditions:

    • It transitions a port into the Forwarding state and it has at least one Designated Port.

    • It transitions a port from either the Forwarding or Learning states to the Blocking state.

      These situations construe a change in the active topology and require notification be sent to the Root Bridge. Assuming that the current bridge is not the Root Bridge, the current bridge begins this notification process by sending TCN BPDU out its Root Port. It continues sending the TCN BPDU every Hello Time interval seconds until the TCN message is acknowledged (note: this is the locally configured Hello Time, not the Hello Time distributed by the Root Bridge in Configuration BPDUs).

  2. The upstream bridge receives the TCN BPDU. Although several bridges might hear the TCN BPDU (because they are directly connected to the Root Port's segment), only the Designated Port accepts and processes the TCN BPDU.

  3. The upstream bridge sets the Topology Change Acknowledgment flag in the next Configuration BPDU that it sends downstream (out the Designated Port). This acknowledges the TCN BPDU received in the previous step and causes the originating bridge to cease generating TCN BPDUs.

  4. The upstream bridge propagates the TCN BPDU out its Root Port (the TCN BPDU is now one hop closer to the Root Bridge).

  5. Steps 2 through 4 continue until the Root Bridge receives the TCN BPDU.

  6. The Root Bridge then sets the Topology Change Acknowledgment flag (to acknowledge the TCN BPDU sent by the previous bridge) and the Topology change flag in the next Configuration BPDU that it sends out.

  7. The Root Bridge continues to set the Topology Change flag in all Configuration BPDUs that it sends out for a total of Forward Delay + Max Age seconds (default = 35 seconds). This flag instructs all bridges to shorten their bridge table aging process from the default value of 300 seconds to the current Forward Delay value (default=15 seconds).

Figure 6-18 summarizes the use of these bits during the seven-step TCN procedure (the steps numbers are circled):

Figure 6-18. Sequence of Flows in Topology Change Processes

graphics/06fig18.gif

Applying these steps to the topology in Figure 6-17 (for simplicity, the steps are not shown in Figure 6-17), Cat-B and Cat-C send TCN BPDUs out their Port 1/1 (Step 1). Because the upstream bridge is also the Root Bridge, Steps 2 and 5 occur simultaneously (and allow Steps 3 and 4 to be skipped). In the next Configuration BPDU that it sends, the Root Bridge sets the TCN ACK flag to acknowledge receipt of the TCN from both downstream Catalysts. Cat-A also sets the Topology Change flag for 35 seconds (assume the default Forwarding Delay and Max Age) to cause the bridging tables to update more quickly (Step 6 and 7). All three switches receive the Topology Change flag and age out their bridging tables in 15 seconds.

Notice that shortening the aging time to 15 seconds does not flush the entire table, it just accelerates the aging process. Devices that continue to "speak" during the 15-second age-out period never leave the bridging table. However, if Host-D tries to send a frame to Host-E in 20 seconds (assume that Host-E has been silent), it is flooded to all segments by the switches because the EE-EE-EE-EE-EE-EE MAC address is no longer in any of the bridging tables. As soon as this frame reaches Host-E and Host-E responds, the switches learn the new bridge table values that are appropriate for the new topology.

Table 6-8 shows the bridge table entries for MAC address EE-EE-EE-EE-EE-EE on all three bridges after the new topology has converged and traffic has resumed.

Table 6-8. Bridge Table Value after Topology Change

Bridge Table

Port Associated with EE-EE-EE-EE-EE-EE

Cat-A

Port 1/2

Cat-B

Port 1/1

Cat-C

Port 1/2

At this point, connectivity between Host-D and Host-E is reestablished and our Doom Deathmatch can resume. Notice that the TCN BPDU reduced the failover time from 5 minutes to 50 seconds.

As previously mentioned in the "Configuration BPDUs" section, both Flag fields are stored in the same octet of a Configuration BPDU. This octet is laid out as illustrated in Figure 6-19.

Figure 6-19. Layout of Configuration BPDU Flag Fields

graphics/06fig19.gif

As discussed in the previous section, the TCA flag is set by the upstream bridge to tell the downstream bridge to stop sending TCN BPDUs. The TC flag is set by the Root Bridge to shorten the bridge table age-out period from 300 seconds to Forward Delay seconds.



Cisco(r) LAN Switching
Cisco Catalyst LAN Switching
ISBN: B00007FYCI
EAN: N/A
Year: 2005
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net