Understanding Linux Network Internals 2005 phần 4 docx

The root bridge makes sure each bridge in the network comes to know about a topology change when one occurs (see the
section "Topology Changes").
Note that the selection of the port states and roles (and therefore of the links that should be enabled or disabled) depends on the location
of the root bridge in the topology: this is because first you select the root bridge, and then you build the best tree based on that.
15.3.2. Designated Bridges
While each tree has only one root bridge, there is one designated bridge for each LAN, which becomes the bridge all hosts and bridges on
the LAN use to reach the root. The designated bridge is chosen by determining which bridge on the LAN has the lowest path cost to the
root bridge.
Thus, using Figure 15-2 as an example:
[*]
[*]
The links in the figure are not assigned costs. You can assume their costs to be 1, and therefore the path cost to be
the hop count. This is just an example; 1 is not the default cost assigned to links.
In the A3-D2 LAN, D2 is the designated bridge.
In the D2-C2 LAN, C2 is the designated bridge.
15.3.3. Spanning Tree Ports

We introduced the root and designated bridge's roles in the previous sections. Let's see here what states and roles can be assigned to a
bridge port.
15.3.3.1. Port states
An STP port is a port in a bridge that runs the STP. This port will process ingress BPDUs and transmit BPDUs according to the rules in the
section "When to Transmit Configuration BPDUs."
An STP port can be in any of the following states:
Disabled
The port is shut down (through administrative action); it does not receive or transmit any traffic.
Blocking
The port is up, but the STP has blocked it. It cannot be used to forward any data traffic.
Listening
The port is enabled, but it cannot be used to forward any data traffic.
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -

Learning
The port is enabled, but it cannot be used to forward any data traffic; however, the bridge's address learning process is active.
Forwarding
The port is enabled, learning is active, and data traffic can be forwarded.
The use of the intermediate learning state allows a bridge to reduce the amount of flooding that would otherwise be required with an empty
forwarding database.
With the exception of ports in the disabled state, ingress BPDUs are processed regardless of the port state. Whether a port in a given
state receives ingress BPDUs or transmits BPDUs depends on the port's role, which is introduced in the section "Port roles."
Figure 15-6 shows how the state of a port can change. There is a clear progression from blocking through listening and learning to the
most active state, forwarding. The transitions between blocking and forwarding are decided by the protocol based on various factors (see
the later section "Defining the Active Topology"). Note that:
A port on its way to the forwarding state can be moved back to blocking before the forwarding state is entered. This is possible,
for instance, when a topology is not stable yet and therefore its state may change repeatedly in a short amount of time.
The transitions between the intermediate states from blocking to forwarding are driven by a timer (see the section "Timers") and
are needed to avoid the risk of temporary loops (see the section "Avoiding Temporary Loops").
Figure 15-6. Port state transitions
In addition, an administrator can manually remove a port from any of these states and disable it. When a port is administratively disabled,
it can be re-enabled only by another administrative intervention; the STP does not have this capability. However, bridges can implement
optional features on top of the basic ones defined by the protocol, to enable and disable ports without administrative intervention.
15.3.3.2. Port roles
STP ports can be assigned one of the following two roles:
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
Root
For each bridge, with the exception of the root bridge, the port with the lowest path cost to the root bridge is selected as the root
port.
Designated
On each LAN, the port with the smallest path cost to the root bridge is selected as the designated port. The bridge to which the
designated port belongs is called the designated bridge for the LAN. Note that a bridge with ports on different LANs can have
more than one designated port, as shown in Figure 15-2. The criteria used to select designated ports are described later in the

section "Designated Port Selection."
While root ports lead toward the root of the tree (i.e., the root bridge), designated ports lead toward the leaves. In Figure 15-2, you can see
the relationship between root and designated ports.
From a tree's perspective, the two roles can be seen in this way:
The tree's root has links that go only toward the leaves (i.e., only designated ports
[*]
).
[*]
If you use shared media such as hubs to connect bridges, as in Figure 15-11(c), the root bridge can have
nondesignated ports as well. The newer RSTP protocol would call that port a backup port (see the section
"Rapid Spanning Tree Protocol (RSTP)."
The leaf nodes have links that go only toward the tree's root (i.e., no designated ports and one root port). As a protection against
misconfigurations and wrong cabling (such as connecting a bridge to a port where you are supposed to connect a host), a leaf
node can run the STP on the ports that connect the hosts, too. In this case, the assumption that a leaf node does not have
designated ports would no longer be valid. In other words, if you enable the STP on the ports of the access bridges in Figure
15-2 that connect the hosts, those ports would end up being assigned the designated role.
Any node between root and leaves has at least one link toward the root (one of which will be selected as the root port), and at
least one toward the leaves (a designated port).
There are STP ports that are neither root nor designated ports; this is possible when you have redundant links between bridges. In Figure
15-2, the A1 port that goes to D2 is an example. The newer STP protocols, which I will briefly introduce in the section "Overview of Newer
Spanning Tree Protocols," define new roles so that each STP port is assigned one.
We will see how the root and designated port roles are assigned in the sections "Root Port Selection" and "Designated Port Selection,"
respectively.
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
15.4. Bridge and Port IDs

The selection of the root bridge and the port state and roles depends on a set of parameters. Each parameter is assigned a default value

that can be changed by user configuration. Here are the main parameters:
Bridge ID
Each bridge is assigned an ID, called the bridge ID, that is defined as an 8-byte value split into two components. The lowest
six bytes are assigned the Ethernet MAC address of one of the bridge ports (see Chapter 16), and the highest two bytes are a
configurable priority, called the bridge priority . The bridge ID is the field used by the root bridge selection algorithm (see the
section "Root Bridge Selection").
Port ID
Each port is assigned an ID. A portion of the ID represents a unique identifier called the port number. The way the port
number is assigned is implementation dependent, and its value is meaningful only locally on the bridge. For example, the
number can reflect the sequence in which ports were created: the first port is assigned 1, the second port 2, etc. Another
approach could use the physical location of the port: for example, the first port on the bus is assigned 1, etc. It is desirable to
have the port number assignments be deterministic and consistent across reboots so that the system administrator does not
need to change the bridge configuration to reflect the changes after a reboot.
Another portion of the ID, called the port priority , is used to assign a priority to the port (where a lower value means a higher
priority). See Figure 15-7(b).
See the section "Root Port Selection" for an example of when this parameter is used.
Besides the bridge and port priority, the user can configure the following parameters:
Port cost
Each port is assigned a cost. The lower the value, the more preferred the port is. When not explicitly configured, the port is
assigned a default cost based on the port's speed. For example, a Fast Ethernet port that runs at 100 Mbits/s is assigned a
lower cost than an Ethernet port that runs at 10 Mbits/s. The default cost assignment makes sense in most cases, when the
overall cost of going from one point of the tree to another is measured in terms of latency. However, it is possible that in
specific contexts, the administrator prefers to explicitly assign costs based on external factors.
Timers
The STP uses a set of per-port and per-bridge timers . All of them have a default configuration that can be customized by the
user. See the section "Timers." The timer configuration does not affect the selection of the root bridge and the port state and
roles.
We will see later in this chapter how the configuration of these parameters (with the exception of the timers) can be used to influence the
selection of the topology.
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.

Simpo PDF Merge and Split Unregistered Version -
In 2001, the IEEE released the 802.1t, 802.1D's maintenance document, which changed how bridge and port IDs are defined. The
changes in format are shown in Figure 15-7.
Figure 15-7. Bridge ID and port ID changes introduced by 802.1t
Note that:
The bridge priority is now only 4 bits in size. For backward compatibility, the bridge priority range is still 0-64 K, but since you
have only four bits to play with, you now have priorities in increments of 4,096 (2
12
).
There is a new component in the bridge ID, called the system ID extension. This component, which can assume 4,096
different values, allows a network device, for example, to have up to 4,096 different bridge IDs sharing a single MAC
address. Before, this would have required 4,096 different MAC addresses. Note that MAC addresses are not random
numbers chosen by the administrator; they are worldwide unique numbers (and therefore are a limited resource) that are
managed by the IEEE.
The port number is now a 12-bit value, which allows a bridge to have up to 4,096 ports. Before you could have had only 256
(which was originally considered quite luxurious). The port priority is now a 4-bit value. The priority range is still 1-256 for
backward compatibility, so priorities are now assigned in increments of 16.
To understand the reasons for the 802.1t changes, you need to think in terms of high-end commercial devices, not common PCs
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
equipped with just a few NICs. The latter can survive with a limit of 256 bridge ports, or a single bridge ID per MAC address. However, it
is not uncommon for big bridges to be equipped with hundreds of ports and to run hundreds of instances of bridges.
Note also that 4,096 is not a random value: it represents the maximum number of Virtual LANs (VLANs) allowed in the 802.1Q protocol.
The 802.1t changes do not have any impact on the STP. From the STP's perspective, a bridge ID is an 8-byte value and a port ID is a
2-byte value. The size or purpose of the user-configuration component does not matter. This means that the 802.1t changes affect only
configuration tools, not the protocol's behavior. Tables 15-1 and 15-2 summarize the possible values of the different parameters.
Table 15-1. Bridge IDs and port IDs before 802.1t

Default valueMin. valueMax. valueMin. increment
Bridge priority32,768065,5351

Port costDepends on port speed165,5351
Port priority12802551
Table 15-2. Bridge IDs and port IDs after 802.1t

Default valueMin. valueMax. valueMin. increment
Bridge priority32,768061,4404,096
Port costDepends on port speed1200,000,0001
Port priority128024016
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
15.5. Bridge Protocol Data Units (BPDUs)

Bridges exchange protocol frames, called BPDUs, that include enough information for them to agree on who is the root bridge, and to
decide on the roles and states for their local ports. There are two kinds of BPDUs:
Configuration BPDU
Used to define the loop-free topology. You will see in the section "When to Transmit Configuration BPDUs" what conditions
trigger the transmission of these BPDUs.
Topology Change Notification (TCN) BPDU
Used by a bridge to notify the root bridge about a detected topology change. See the section "Topology Changes."
Figure 15-8 shows the format of both BPDUs. Note that the two types share the same first three fields and can be distinguished by the
BPDU type parameter.
Figure 15-8. a) Configuration BPDU; b) BPDU
Table 15-3 shows the combinations of protocol ID and protocol version used by the three IEEE STPs. In this chapter, we will look only at
the basic 802.1D protocol and briefly introduce the other two in the section "Overview of Newer Spanning Tree Protocols."
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
Table 15-3. BPDU versions
Protocol nameProtocol IDProtocol version

STP (802.1D-1998)00
RSTP (802.1D-2002 or 802.1w)02
MSTP (802.1Q-2002 or 802.1s)03
15.5.1. Configuration BPDU

Here is the meaning of the fields in the configuration BPDU:
Flags
Only two flags are used: TC (Topology Change) and TCA (Topology Change Acknowledgment). The use of both is described
in the section "Topology Changes."
Root Bridge ID
ID of the root bridge. This is what the transmitting bridge thinks the current root bridge is.
Root Path Cost
Cost of the shortest path from the transmitting bridge to the root bridge. The cost is 0 when the transmitting bridge is (or thinks
it is to become) the root bridge.
Bridge ID
ID of the transmitting bridge.
Port ID
Port identifier. See the section "Bridge and Port IDs" for its syntax.
Message Age
How much time has passed since the root bridge generated the information in this BPDU. See the section "BPDU Aging."
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
Max Age
Maximum lifetime for configuration BPDUs.
Hello Time
Timeout used by the Hello timer.
Forward Delay
Timeout used by the Forward Delay timer. See Figure 15-6.
The values of the three timers Max Age, Hello Time, and Forward Delay are not the ones configured locally on the bridge: they are the
ones advertised by the root bridge (see the section "Transmitting Configuration BPDUs"). All of them are expressed in ticks (1/256

th
of
second). See the section "Timers."
15.5.2. Priority Vector
Four components of the configuration BPDURoot Bridge ID, Root Path Cost, Bridge ID, and Port IDmake up the priority vector (see Figure
15-8). Because these four components are in sequence, this vector can be seen as a single 22-byte number. The lower the number is, the
more important the bridge is in the topology; in other words, the priority vector determines who wins the bidding for contested roles such as
root bridge and designated bridge. In the rest of this chapter, I will refer to priority vectors using a [BR-Root, Cost, BR-ID, Port-ID] notation.
In the examples later in this chapter, the figures show only the priority component of the configuration BPDUs transmitted, because that is
the portion of the configuration BPDU used by the bridges to select their port's roles and states.
Given two priority vectors PV1=[BR-Root1, Cost1, BR-ID-1, Port-ID1] and PV2=[BR-Root2, Cost2, BR-ID-2, Port-ID2], PV1 is said to be
superior when it is a lower numeric value than PV2, and inferior when PV1 is a higher numeric value than PV2. In other words, PV1 is
superior to PV2 if BR-Root1< BR-Root2, or, in case they are the same, if Cost1< Cost2, or, if they are the same too, if BR-ID1< BR-ID2, or,
when the two bridge IDs match too, when Port-ID1<Port-ID2.
15.5.3. When to Transmit Configuration BPDUs
A bridge transmits configuration BPDUs out of its designated ports. It does so in the following cases:
The root bridge runs a timer (the Hello timer) that expires regularly and triggers the transmission of configuration BPDUs. One
BPDU is transmitted on each one of its designated ports. Only the root bridge generates new BPDUs, but when a bridge is first
enabled, it thinks it is the root bridge (because it has no other priority vector to compare its own to). So it places all of its ports
into the designated role, starts its Hello timer, and begins to generate BPDUs (see the section "Root Bridge Selection").
Nonroot bridges generate BPDUs only in response to ones they receive on their root ports; in other words, they relay BPDUs.
BPDUs transmitted by nonroot bridges carry the same information as the BPDUs they received, with the exception of the
following fields that they update (see Figure 15-9):
The transmitter's bridge ID and port ID are replaced by the bridge with its own information.
The bridge updates the cost to be the sum of the cost it received and the cost of the port on the local bridge (its root
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
port) that it received the BPDU on.
The message age is updated according to the logic described in the section "BPDU Aging." The latter section
explains how the DT quantity is defined.

Regardless of whether a bridge is the root bridge, it transmits a configuration BPDU in the following cases as well:
When a bridge receives a BPDU with a priority vector that's inferior to the one it would use on the same port, it replies with its
own (superior) information. See the section "Examples of STP in Action."
When a bridge receives a TCN BPDU, it acknowledges its reception right away with the transmission of a configuration BPDU
that has a special flag set. This helps propagate changes in topology quickly (see the section "Letting All Bridges Know About a
Topology Change").
Regardless of why a configuration BPDU is transmitted out of a given port, the STP enforces rate limiting: a bridge cannot transmit more
than one Configuration BPDU per second out of any of its ports (see the section "Transmitting Configuration BPDUs").
15.5.4. BPDU Aging

Because BPDUs are generated only by the root bridge, and are regenerated by the other bridges only upon the reception of a BPDU on
their root port, it should be clear that the time taken by the information generated by the root bridge with its BPDUs to reach the leaf
bridges is variable. On a stable network, the time depends mainly on how loaded the bridges are and how fast they can process BPDUs.
Figure 15-9. BPDU relaying via nonroot bridges
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
BPDUs carrying stale information should not be used to build the loop-free topology. For that reason, configuration BPDUs have a field
called Message Age that is compared by the receiving bridge against the other field, Max Age, to discard those BPDUs that have been
around for too long and whose priority vector cannot be trusted.
The Message Age field is first initialized to 0 by the root bridge, and is updated by each nonroot bridge prior to forwarding it (see DT in
Figure 15-9). The Message Age is supposed to represent the time that has passed since the original root bridge's BPDU was generated.
However, to calculate this time is not easy. It should, for example, account for both the transmission delays and the processing time: in
other words, the time spent by the frame in the media going from one bridge's port to the next one, and the time spent in the bridge's
memory while each bridge processes and regenerates it. But a common approach in commercial bridges is to simply treat the Message
Age field as a hop count, just like the Time To Live (TTL) field of the IP header: the Message Age field of the ingress BPDU is incremented
by 256 ticks (i.e., 1 second) and copied into the outgoing BPDUs. This means that a BPDU would be dropped after a maximum of 20 hops
(20 seconds is the default value for Max Age). Linux does not use the message age as a hop count, but tries to respect the original rule
described in the section "Transmitting Configuration BPDUs."
When the BPDU received by a bridge on one of its port has not expired (i.e., the Message Age is less than the Max Age), the bridge starts
a Message Age timer that will expire after an amount of time given by the difference between the Max Age and the Message Age. Refer to

the section "Timers" for the actions triggered by the expiration of the Message Age timer. This ensures that the information carried by the
BPDU is discarded Max Age seconds after its generation, unless it is confirmed by then.
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
15.6. Defining the Active Topology

Each bridge, with the help of the local configuration and the information received with the ingress configuration BPDUs, is able to
accomplish the following:
Elect the root bridge
Select one of its ports as the root port
For each port, identify the designated bridge and designated port for the LAN to which the port belongs
Those tasks, which I will refer to as a configuration update, are needed every time something changes in the network that may require a
change in the topology. For instance:
A port is either enabled or disabled.
A port's Message Age timer expires. In this case, the port is restarted (i.e., assigned the designated role).
The local configuration of a bridge changes.
A bridge port receives a configuration BPDU with a superior priority vector compared to the one previously received on the same
port.
Note that a configuration update is triggered on the bridge where the configuration is changed or where a port changes administrative
state. The other bridges will follow (if necessary) upon seeing these changes reflected in the information carried by the BPDUs they
receive.
Let's see how the configuration update's tasks are taken care of, one by one.
15.6.1. Root Bridge Selection
We saw in the section "Bridge and Port IDs" how a bridge ID is defined. An algorithm based only on the use of the MAC address for the
selection of the root bridge would be sufficient to ensure a deterministic selection, given that MAC addresses are unique worldwide.
However, the addition of the priority component allows administrators to force the topology they like by assigning higher priorities to those
bridges they would like to be selected as root. They can even assign strategic priorities to different bridges so that they can also force a
given bridge to take over in case the current root bridge fails.
When a bridge is first enabled, it does not know anything about the topology and therefore thinks it's the root bridge. It will therefore assign
the designated role to all its ports, start the Forward Delay timer on the ports so that they eventually will be assigned the forwarding state

(see Figure 15-6), and start transmitting BPDUs using the bridge's ID as the root Bridge ID field, and a root path cost of 0. This is a
convenient way to make it broadcast data about itself and get that data spread around as quickly as possible so that both it and other
bridges can discover the truly best root bridge and rebalance the tree.
When the bridge is the one with the best bridge ID, it will keep sending out BPDUs on its designated ports because no other bridge can
claim a better priority vector (to be more exact, a better bridge ID) and therefore take over the root role.
If the bridge did not have the best bridge ID, it will eventually receive a configuration BPDU with a better root bridge ID (i.e., a superior
BPDU) and:
Accept and record the better information (including the root bridge ID and timers).
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
Update the state and role of its ports accordingly. This is what is called a configuration update.
15.6.2. Root Port Selection

Each bridge must select its own root port , which, as we anticipated in the section "Port roles," is the port with the shortest path (or lowest
cost) to the root bridge. The root bridge is the only one that does not have a root port; nonroot bridges have one and only one root port.
For each of its ports, with the exception of the ones that are administratively disabled, a bridge keeps a copy of the best priority vector
received with ingress BPDUs. This way, the bridge knows, for each port, what is the best (lowest cost) path to reach the root bridge.
The selection of the root port consists simply of going through all the ports and selecting the one with the best priority vector. If more than
one port happens to share the same best priority vector, the local port with the lowest assigned port ID is selected, as shown in Figure
15-10 (note that the receiver port ID is not part of the BPDU).
Figure 15-10. Multiple candidates for the root port selection
15.6.3. Designated Port Selection
While there can be one root port per bridge, there is only one designated port per LAN. The STP ensures that each bridge chooses the
same port. The designated port should be the one that has the lowest path cost to the root bridge. Thus, it's the port with the best priority
vector.
Each bridge is usually on more than one LAN, so it must learn the designated port for each LAN.
On a point-to-point connection between two bridges, there are just two ports. The one that transmits BPDUs with the best priority vector is
selected. By contrast, a shared medium such as an Ethernet hub may have more than two bridges. In that case, each bridge will receive
each other's BPDUs and, by checking the priority vector, elect the right designated port.
Figure 15-11 shows what would happen when you use a shared medium to connect bridges. Initially only BR2 is connected to the hub and

therefore it elects itself as the root bridge. When an administrator later adds BR1, it also thinks it is the root bridge, as you can see from
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
the BPDUs it transmits in Figure 15-11(b). Let's assume that BR2's ID is higher than (i.e., inferior to) BR1's ID, and therefore that the two
bridges end up agreeing on BR1 as the root bridge.
Because all of these bridge ports connect to the same hub, when BR1'sport 1 transmits a BPDU, BR1 receives its own BPDU on port 2,
and vice versa. However, the selection of the designated port based on the best priority vector works in this scenario, too: the fourth field
of the priority vector, which is the port ID, makes port 1's BPDU priority vector the best.
However, the shared-medium setup is unpopular for several reasons, so in the rest of this chapter, I will refer only to the point-to-point
case.
Figure 15-11. Designated port selection
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
15.6.4. Examples of STP in Action
Let's suppose we had the topology in Figure 15-12. Note that since there are no redundant links, there would be no need for the STP.
Let's assume:
Bridge ID BR1 < Bridge ID BR2 < Bridge ID BR4 (so BR1 is the root bridge).
Each bridge can configure the cost of its local interfaces independently from the other bridges. For simplicity and to make the
figure easier to read, let's just assume that all the path costs are symmetric (the same on both sides of each link).
[*]
[*]
Remember that the path cost of any link is a locally configured parameter and it is not carried in the
configuration BPDUs.
Figure 15-12. Updating the root path cost
Note that:
The designated port of BR1 regularly transmits a configuration BPDU every time the Hello timer expires. Because BR2 receives
configuration BPDUs regularly at every Hello time on its port 1, it regenerates (forwards) a configuration BPDU on its port 2
more or less regularly at every Hello time as well.
Bridge 1's configuration BPDU advertises:
BR1 as the root bridge

This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
A root path cost of 0
Its own bridge ID BR1
A port ID of 1
Bridge 2's configuration BPDU advertises:
BR1 as the root bridge
A root path cost of 10 (it adds its own cost to the one sent out by BR1)
Its own bridge ID BR2
A port ID of 2
Now let's add a new bridge named BR3, and assume that Bridge ID BR3 < Bridge ID BR4, as in Figure 15-13.
As we explained in the section "Root Bridge Selection," when BR4 is first enabled it thinks it is the root bridge, and therefore it assigns the
designated role to its two ports. It sends out a configuration BPDU on each port, advertising itself as the root bridge, and therefore using a
root path cost of 0 in the BPDUs.
Figure 15-13. Adding a bridge to a stable topology
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
If we assume BR3 to be connected to BR1 and BR4 with a point-to-point link, as in Figure 15-13, when BR3 is powered up, BR1 and BR4
will enable their ports connected to BR3, assign these ports the designated role, and start transmitting configuration BPDUs.
Let's see how BR1, BR3, and BR4 react upon receiving each other's configuration BPDUs:
The configuration BPDUs from BR1 and BR4 will have the following priority vectors, respectively: [BR1, 0, BR1, 2] and [BR1,
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
110, BR4, 2].
Because the BPDU that BR1 receives from BR3 has an inferior priority vector, BR1 keeps its port 2 in the DESIGNATED role
and maintains its root bridge role. On the other hand, when BR3 receives the BPDU from BR1, it realizes that BR1 has a better
bridge ID (and thus a better priority vector) and therefore updates its port 1's priority vector, selects port 1 as its root port, and
selects BR1 as the root bridge.
The BPDU that BR3 receives from BR4 has a better priority vector than the one BR3 sent to BR4, but not as good as the one
BR3 received from BR1. Because of that, BR4 does not change its current root port and root bridge information: port 1 is still the

root port and BR1 is still the root bridge.
When BR3 transmits a new BPDU to BR4, as in Figure 15-13(b), it uses a new priority vector that reflects the new information
acquired from BR1. Upon receiving that BPDU, BR4 recognizes the superior priority vector and it blocks its port 2. Note that
BR3's priority vector wins over BR4's priority vector because of its lower path cost (i.e., BR3's port 2 is selected as the
LAN-designated port because it is closer to the root bridge than BR4's port 2).
BR4 selects port 1 as its root port because it is the one that receives the better priority vector (remember that we assumed that
BR2's bridge ID is lower than BR3's bridge ID).
If you compare the configuration BPDU that BR4 receives from BR2 to the one it receives from BR3, you can see that they share the same
root bridge ID (BR1) and the same root path cost (10), but that the third component of the priority vector is better than BR2's, because
BR2's bridge ID is less than BR3's. BR4 therefore selects port 1 as its root port. An administrator who had a preference for BR4's link to
BR3 over the one to BR2 would simply have to configure a lower cost on that port (see the section "Bridge and Port IDs").
In this example, the first three components of the priority vector were sufficient for the selection of the root and designated ports. Let's see
now, with the example in Figure 15-14, when the fourth one, the port ID, is needed as a tiebreaker.
Now BR4 receives two BPDUs from BR2 with the same values in the first three fields of the priority vector. However, the fourth parameter
(the port ID) allows BR4 to select its port 1 as its root port. In the section "Root Port Selection," we also saw how a bridge uses the local
port ID (as opposed to the remote port ID that is part of the priority vector) as the tiebreaker when all four components of the priority
vectors of ingress BPDUs are not sufficient to identify a winning BPDU.
Figure 15-14. Port ID as the tiebreaker
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
15.7. Timers

The STP uses both per-bridge and per-port timers . In Tables 15-4 and 15-5, you can see the default timeouts, and what the allowed
values are, for per-bridge and per-port timers, respectively.
[*]
[*]
If you are interested in how the default timers have been defined, read either the IEEE 802.1d specification or
/>Table 15-4. Bridge timers
TimerDefault value (in seconds)Allowed range
Hello21-10

Topology ChangeForward Delay + Max AgeNot configurable
TCNHello timeNot configurable
Addresses Aging
300 or Forward Delay
a
Not configurable
a
See the section "Topology Changes."
Table 15-5. Port timers
TimerDefault value (in seconds)Allowed range
Message Age206-40
Forward Delay154-30
Hold1Not configurable
Note that not all timers are user configurable. Also note that some timers share the same configuration (the TCN and Hello timers, for
example) so that a configuration change for a timer may affect others as well.
These are the bridge timers:
Hello
Used to regularly generate configuration BPDUs. Only the root bridge uses it.
TCN
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
Used by a bridge that has detected a topology change and must notify the root bridge about it. See the section "Topology
Changes."
Topology change
Used by the root bridge to remember to set a specific flag in its configuration BPDUs. This flag is used to notify the other bridges
about a topology change. See the section "Topology Changes."
Aging timer
Used to clean up stale addresses from the forwarding database. This timer is used by the bridge regardless of whether the STP
is used. See the section "Short Aging Timer."
Each bridge keeps two copies of its timer configuration: the one configured locally by the administrator, and the one received from the root

bridge.
The root bridge is the only one that uses its own configured timers; it makes all the other bridges adopt its configuration. Nonroot bridges
use the timer configurations carried by the BPDUs they receive on their root ports. You can see where timer configuration is located in
Figure 15-8.
These are the port timers:
Message Age
We saw in the section "BPDU Aging" that the information carried by a BPDU has a limited lifetime. The Message Age timer is
used to enforce that lifetime. The timer is restarted each time a BPDU is received on the port. Whenever a BPDU is received, its
message age is compared to the network's max age and the frame is dropped if it is too old. The Message Age timer runs on
nondesignated ports (i.e., the ones that receive superior BPDUs).
In a stable network without problems, this timer will never expire. However, when the root bridge fails to generate BPDUs, or the
latter are received expired or get dropped for some reason, the timer will expire. When the timer expires, the port is restarted,
and therefore assigned the designated role.
Forward Delay
Takes care of the state transitions from listening to learning, and from learning to forwarding. Figure 15-15 shows how expiration
of the Forward Delay timer is typically handled and how it follows the model of Figure 15-6.
Figure 15-15. Handling the Forward Delay timer
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
This document was created by an unregistered ChmMagic, please go to to register it. Thanks .
Simpo PDF Merge and Split Unregistered Version -
Hold
The transmission of configuration BPDUs is rate limited on each port to one per second. On a stable networkthat is, one where
STP has convergedeach designated port transmits a BPDU at every Hello time. However, when a change in the topology
occurs, the convergence to the newer topology can take minutes in complex scenarios due to the distributed nature of the STP
algorithm. Because of that, the number of BPDUs sent according to the rules of the section "When to Transmit Configuration
BPDUs" can easily get large, and it is here that rate limiting is more likely to kick in.
The Hold timer , when needed, runs on designated ports (the ones transmitting configuration BPDUs).
Per-port timers share configurations. For instance, you cannot have two different Max Age configurations on two different ports.
15.7.1. Avoiding Temporary Loops

The root and designated ports are the only ones that are assigned the forwarding state. When a port is assigned the root or designated
role, however, it is not assigned the forwarding state right away: it first has to go through two intermediate states, as shown in Figure 15-6.
These intermediate states suppress the risk of temporary loops while the network converges toward a stable loop-free topology. Let's use
the simple scenario of Figure 15-16(a) as an example.
The topology consists of two bridges connected by two links. One of the two links must be disabled; otherwise, there would be a loop.
We saw earlier that when a bridge's ports are first enabled, they are assigned the designated role and blocking state. We also saw in the
section "Root Bridge Selection" that when a bridge is first enabled, it does not have any knowledge about its neighbor bridges and
therefore it thinks it is the root bridge. Figure 15-16(a) shows two bridges that have just been enabled, and therefore:
They both think they are the root bridge.
Both ports of both bridges are assigned the designated role and the blocking state.
For each port, they change the state to listening, start the Forward Delay timer, and transmit a configuration BPDU. The priority
vectors of those BPDUs reflect their assumption that their bridges are the root bridge.
Note that none of the ports is forwarding yet. Data traffic can be neither received nor transmitted on those ports. Only BPDUs can be
transmitted and received.
When BR2 receives BR1's BPDUs on its ports, it realizes that BR1 has a superior priority vector (a better bridge ID, to be exact). At that
point, BR2 starts a configuration update: it selects the root bridge, the root port, and the designated ports, and updates the state of all its
ports. In particular, it selects BR1 as the root bridge and port 1 as the root port (because it is the port where it has received the BPDU with
the best priority vector). Port 2 is neither a root port nor a designated port and is therefore blocked (i.e., it is left out of the tree). When port
1 is assigned the new role, its Forward Delay timer is restarted. When port 2 is blocked, its Forward Delay timer stops.
Figure 15-16. Transition to forwarding state
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -
This document was created by an unregistered ChmMagic, please go to to register it. Thanks.
Simpo PDF Merge and Split Unregistered Version -