Two Types of BPDUs
To this point, the chapter has referred to all BPDUs as a single type. Actually, there are two types of BPDUs:
• Configuration BPDUs
• Topology Change Notification (TCN) BPDUs
Configuration BPDUs are originated by the Root Bridge and flow outward along the active paths that radiate away from the Root Bridge. Topology Change Notification BPDUs flow upstream (toward the Root Bridge) to alert the Root Bridge that the active topology has changed. The following sections discuss both of these BPDUs in detail.
Configuration BPDUs
All of the BPDUs discussed so far (and the vast majority of BPDUs on a healthy network) are Configuration BPDUs. Figure 6-15 illustrates a BPDU's protocol format.
Figure 6-15 Configuration BPDU Decode
Note
For simplicity, the chapter has so far ignored the fact that there are two types of BPDUs and simply has used the term BPDU. However, recognize that all of these cases were referring to Configuration BPDUs. The second type of BPDU, the Topology Change BPDU, is discussed in the next section.
The decode in Figure 6-15 was captured and displayed by the NetXRay software from Network Associates (formerly Network General). Although considerably newer versions are available for sale, the version shown in Figure 6-15 is useful because it provides a very easy-to-read representation and decode of the Spanning-Tree Protocol. At the top of the screen you can observe the Ethernet 802.3 header. The source address is the MAC address of the individual port sending the BPDU. Every port on a Catalyst uses a unique Source MAC Address value for BPDUs sent out that port. Note the difference between this MAC address and the MAC address used to create the BID. The source MAC address is different on every Catalyst port. The BID is a global, box-wide value (within a single VLAN) that is formed from a MAC address located on the supervisor card or backplane. The source MAC is used to build the frame that carries the BPDU, whereas the BID's MAC is contained within the actual Configuration BPDU.
The Destination MAC Address uses the well-known STP multicast address of
01-80-C2-00-00-00. The Length field contains the length of the 802.2 LLC (Logical Link Control) header, BPDU, and pad that follows. Note that the CRC shown at the bottom of the screen is also part of the 802.3 encapsulation (specifically, the 802.3 trailer).
Below the 802.3 header lies the 802.2 LLC header. This 3-byte header consists of three fields that essentially identify the payload (in this case, a BPDU). The IEEE has reserved the DSAP (destination service access point) and SSAP (source service access point) value 0x42 hex to signify STP. This value has the unique advantage of being the same regardless of bit ordering (0×42 equals 0100 0010 in binary), avoiding confusion in environments that use translational bridging. Don't worry about the next byte, the control byte. It turns out that every non-SNA protocol you can name (including STP) always uses the value 0x03 to represent an Unnumbered Information (UI) frame.
The lower two-thirds of the output contains the actual BPDU. Configuration BPDUs consist of the following 12 fields (although many displays break the two BIDs out into separate subfields as shown in Figure 6-15):
• Protocol ID—
Always 0. Future enhancements to the protocol might cause the Protocol ID values to increase.
• Version—
Always 0. Future enhancements to the protocol might cause the Version value to increase.
• Type—
Determines which of the two BPDU formats this frame contains (Configuration BPDU or TCN BPDU). See the next section, "Topology Change Notification BPDUs," for more detail.
• Flags—
Used to handle changes in the active topology and is covered in the next section on Topology Change Notifications.
• Root BID (Root ID in Figure 6-15)—
Contains the Bridge ID of the Root Bridge. After convergence, all Configuration BPDUs in the bridged network should contain the same value for this field (for a single VLAN). NetXRay breaks out the two BID subfields: Bridge Priority and bridge MAC address. See the "Step One: Elect One Root Bridge" section for more detail.
• Root Path Cost—
The cumulative cost of all links leading to the Root Bridge. See the earlier "Path Cost"
section for more detail.
• Sender BID (Bridge ID in Figure 6-15)—
The BID of the bridge that created the current BPDU. This field is the same for all BPDUs sent by a single switch (for a single VLAN), but it differs between switches.
See the "Step Three: Elect Designated Ports" section for more detail.
• Port ID—
Contains a unique value for every port. Port 1/1 contains the value 0×8001, whereas Port 1/2 contains 0×8002 (although the numbers are grouped into blocks based on slot numbers and are not consecutive). See the "Load Balancing" section of Chapter 7 for more detail.
• Message Age—
Records the time since the Root Bridge originally generated the information that the current BPDU is derived from. If a bridge looses connectivity to the Root Bridge (and hence, stops receiving BPDU refreshes), it needs to increment this counter in any BPDUs it sends to signify that the data is old. Encoded in 256ths of a second.
• Max Age—
Maximum time that a BPDU is saved. Also influences the bridge table aging timer during the Topology Change Notification process (discussed later). See the "Three STP Timers" section for more detail. Encoded in 256ths of a second.
• Hello Time—
Time between periodic Configuration BPDUs. The Root Bridge sends a Configuration BPDU on every active port every Hello Time seconds. This causes the other bridges to propagate BPDUs throughout the bridged network. See the "Three STP Timers"
section for more detail. Encoded in 256ths of a second.
• Forward Delay—
The time spent in the Listening and Learning states. Also influences timers during the Topology Change Notification process (discussed later). See the "Three STP Timers"
section for more detail. Encoded in 256ths of a second.
Table 6-6 summarizes the Configuration BPDU fields.
Table 6-6. Configuration BPDU Fields
Field Octets Use
Protocol ID 2 Always 0
Version 1 Always 0
Type 1 Type of current BPDU
0 = Configuration BPDU
Flags 1 LSB = Topology Change (TC) flag
MSB = Topology Change Acknowledgment (TCA) flag Root BID 8 Bridge ID of current Root Bridge
Root Path Cost 4 Cumulative cost to Root Bridge Sender BID 8 Bridge ID of current bridge
Port ID 2 Unique ID for port that sent this BPDU
Message Age 2 Time since Root Bridge-created BPDU used to derive current BPDU Max Age 2 Period to save BPDU information
Hello Time 2 Period between BPDUs
Forward Delay 2 Time spent in Listening and Learning states
Topology Change Notification BPDUs
Although the majority of BPDUs on a healthy network should be Configuration BPDUs, all bridged networks see at least a few of the second type of BPDU, the Topology Change Notification (TCN) BPDU. TCN BPDUs, as their name suggests, play a key role in handling changes in the active topology. Figure 6-16 illustrates a decode of a TCN BPDU.
Figure 6-16 Topology Change Notification BPDU Decode
The TCN BPDU is much simpler than the Configuration BPDU illustrated in Figure 6-15 and consists of only three fields. TCN BPDUs are identical to the first three fields of a Configuration BPDU with the exception of a single bit in the Type field. After all, at least one bit is needed to say "this is a TCN BPDU, not a Configuration BPDU." Therefore, the Type field can contain one of two values:
• 0x00 (Binary: 0000 0000) Configuration BPDU
• 0x80 (Binary: 1000 0000) Topology Change Notification (TCN) BPDU
That's it. TCN BPDUs don't carry any additional information.
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
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:
o It transitions a port into the Forwarding state and it has at least one Designated Port.
o 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
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
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.
