In this article of simple spanning tree 802.1d, we have
three ether switch on gns3.
Switch AAA has vlan bia(built-in-address) c400.0b14.0000 , switch BBB has vlan 1 bia c402.0b14.0000 and switch CCC has vlan bia c403.0b14.0000. Hence, assuming
the AAA and BBB came up first, they sent their BPDU to each other with fields
like Protocol ID, Protocol version, BPDU type, flag, TCN, Root
Bridge ID, Sender's bridge ID, Root Path cost, Port ID, Hello time, Max age,
Message age, Forward delay.
Some overview about STP:
1. Switches send BPDU at every 2 sec interval by default.
2. Message age and max age is 20 sec by default.
3. Forward delay is 15 sec which is used in interval.
4. Any port takes maximum time of 50 seconds to reach the
forwarding state from blocking. This can be broken into (Blocking to
listening->20 sec, listening to learning MAC-> 15 sec, learning to
Forwarding packets-> 15 sec)
5. BPDU types are: Configuration bpdu, TCN BPDU, TCN
acknowledgement bpdu. A BPDU has 13 fields and it is important to know them each, that will help in understanding RSTP and other protocols further.
6. Switch A if is root and switch B connected to it over
100mb bandwidth than its designated cost is 0 to reach root A and if one more
switch C is connected to B over 100 MB again then its DC cost will 19 as the
cost is pre-specified for all link capacity.
** Designated cost is compared when the cost capacity of
link is equal. If both links are 100mbps then DC can be taken into account. If
bandwidth is different or altered like one is 10 and other is 100 Mbps then DC
might not show the expected result even if it is 0 and the port will not become
root port.
Continuing with our two switches AAA and BBB, both will claim each other as root bridge and
will have their own sender id in bpdu.
AAA: I am the root bridge with my bpdu packet as below. Similarly,
BBB: I am the root bridge with my bpdu as just having my
own MAC address(right).
Both switch now will compare each others and switch BBB
found that it's MAC is of higher ID as sum of bridge priority+ mac ( mac being
higher of BBB). So, now switch BBB will use all bpdu and will put mac add of
AAA as it is lower in Root bridge ID field. On Ethernet switches lower is
always the better. So here Root bridge is AAA.
Now CCC also has come up in similar fashion connected to
AAA F1/1 and BBB F1/3.
CCC: Hello, I am CCC with mac c403.0b14.0000 and I am the
root bridge in my BPDU(sent to AAA and BBB).
AAA sends it BPDU with self as root bridge & sender
bridge ID and BBB also sends its BDPU with root ID that of AAA and self sender
ID. Switch CCC compares its bridge ID with AAA and CCC, founds itself in poor
to both. Similarly, BBB and AAA also compares and found CCC's bridge ID is
higher and poor so no need for new root bridge election. Thus from now onward
CCC and BBB will send all BPDUs with Root bridge ID that of AAA and self
sender's ID. Ex:
![]() |
BBB bpdu |
**Root Bridge facilitates in mitigation of any bridging
loop but remember root bridge AAA itself
doesn't thwarts the loop.
Loop is broken when any non root bridge finds itself in a
position where it received BPDUs with same root bridge ID from two of its ports
and then it compares this with the initial results of comparison with its
neighbors mac addresses, of course after comparing the cost to reach the root.
It also means in technical jargon that a switch has two root ports which is a
reason for loop. A switch can have as many ports to reach all friendly non root
switches and we call those ports as designated forwarding ports but a switch
must not have more than 1 port to reach the root. This is how a switch calculates
Spanning-tree.
AAA spanning tree status;
BBB spanning tree status;
CCC spanning tree status below; please see the F1/3 here is in blocking state for #3 reasons, first the CCC lost the root bridge by all means because of higher mac + bridge priority(32768), secondly the cost to reach AAA root is less via f1/1 which is 0 (designated cost) than via f1/3 which is 19, thirdly F1/3 is greater than F1/1 and as I said lower is always better in three switches.
The situation would look something like below:
![]() |
CCC interface f1/3 is in BLK state |
Now, we will extend couple of ether switches to CCC and
BBB and will try to understand what their behavior will be one by one on the
tongue tip.
Shown to the right, I have connected a DDD name switch by
interface f1/4 to CCC. It is obvious DDD is now like a leaf and doesn't have
anything next to it. So since AAA is the root, DDD will have f1/4 as the only
way to reach the root. The problem occurs when switch DDD sends a BPDU with
better and lower bridge ID. This will cause to CCC then to BBB and AAA to
consider DDD root if it succeeds.
**Root bridge is a hallmark entity in any L2 architecture
through which all other switches try to identify themselves in the positional arrangement
under VLAN.
Similarly, if Switch EEE is connected to BBB as DDD is to
CCC then it will show similar effect with EEE also acting as leaf bridge.
The output for EEE is,
EEE#sh spanning-tree brief
VLAN1
Spanning tree enabled protocol ieee
Root ID
Priority 32768
Address c400.0b14.0000
Cost 38
Port 45 (FastEthernet1/4)
Hello Time 2 sec
Max Age 20 sec Forward Delay 15
sec
Bridge ID
Priority 32768
Address c40a.07e8.0000
Hello Time 2 sec
Max Age 20 sec Forward Delay 15
sec
Aging Time 300
Interface Designated
Name Port ID Prio Cost Sts Cost
Bridge ID Port ID
--------------------
------- ---- ----- --- ----- -------------------- -------
FastEthernet1/4 128.45
128 19 FWD
19 32768 c402.0b14.0000 128.45
Now, I will connect DDD and
EEE on a common FE link f1/5 and a loop is bound to occur between AAA, BBB, EEE,
DDD, CCC in a circle:
A tongue tip calculation involves
calculation spanning tree the time you understood their bridge ID and the
pattern of already blocked ports. Since f1/3 of CCC was already blocked so a
topology was loop free until f1/5 on DDD and EEE was brought in. The moment I
introduced f1/5 on DDD 7 EEE all
switches could hear root bpdu on two of their ports. If to believe that AAA,
BBB and CCC already had their understanding of what to be blocked, it was now
turn of newly connected EEE and DDD over F1/5
to exchange BPDU and negotiate what to be blocked.
DDD and EEE didn't block
f1/4 ports because it has least cost to reach the root AAA with 19(DC). If 1/4
is blocked, the cost could escalate to 19x2=38. That's DDD would reach AAA via
EEE and then via BBB. Same is applicable for EEE should 1/4 was to be blocked.
Thus we can conclude that given the least cost parameters one can reach the root
AAA, the bridges can choose the best path depending on links bandwidth and port priority solely than by
administrative changes(least recommended).
Below is the EEE spanning
tree output:
EEE#sh spanning-tree brief
VLAN1
Spanning tree enabled protocol ieee
Root ID
Priority 32768
Address c400.0b14.0000
Cost 38
Port 45 (FastEthernet1/4)
Hello Time 2 sec
Max Age 20 sec Forward Delay 15
sec
Bridge ID
Priority 32768
Address c40a.07e8.0000
** EEE vlan 1 MAC address
Hello Time 2 sec
Max Age 20 sec Forward Delay 15
sec
Aging Time 300
Interface Designated
Name Port ID Prio Cost Sts Cost Bridge ID Port ID
--------------------
------- ---- ----- --- ----- -------------------- -------
FastEthernet1/4 128.45
128 19 FWD 19 32768
c402.0b14.0000 128.45
FastEthernet1/5 128.46
128 19 BLK 38 32768
c409.0b14.0000 128.46
Now, let's make one more
test just to check where we have reached with
our understanding.
We will connected a FE
between BBB and DDD with bandwidth 100mbps.
The answer will be simple
to at present prevalent topology. A new loop will be introduced with f1/6
between BBB & DDD.
So to thwart that again,
who will block depends upon whose BID is what? DDD has poor bridge ID to CCC
and BBB thought cost equates to 19(DC) for both. But since BBB has lower BID to
CCC so DDD's f1/4 will go down to blocking. But if I reduce the cost of f1/6
link of DDD to 10 mbps, then certainly F1/4 will come and up and take the role
of root port to reach the root bridge.
No comments:
Post a Comment