Spanning Tree – 802.1d (Normal)

      No Comments on Spanning Tree – 802.1d (Normal)

Let’s start with the basics.  When I started learning about spanning-tree, I found it INCREDIBLY hard to get a good footing on the different protocols.  You’d read about 802.1d, 802.1w, 802.1s, PVST, PVST+, etc.  The problem I had was that I couldn’t correlate the different pieces together.  To be frank, I’m still not sure if I have it right, but this is my understanding. 

-802.1d is the standard spanning-tree definition.  This is what I consider ‘normal’ spanning-tree.

-Cisco implemented 802.1d on a per VLAN basis a long time ago.  This was referred to as PVST (per vlan spanning-tree).  This ran ONLY over ISL trunks between Cisco switches

-Cisco fixed this with PVST+ which allowed PVST to run over dot1q trunks.  Despite this being called PVST+ it is now (these days) referred to just as PVST since they assume that no one is still using ISL trunks.

-The default option on a Cisco switch is PVST(+).  I consider this to be 802.1d ran on a per VLAN basis.

-The other two options are MST(802.1s) and rapid-pvst (802.1w).  Again, Cisco took RPVST (802.1w) and made it run on a per-VLAN basis.

So basically, you have some standards for spanning-tree, two of which Cisco has tweaked to run on a per-VLAN basis.  That’s my full understanding, I’d love to have someone further clarify or correct me if they know better.

At any rate, let’s start by looking at the default PVST configuration…


This is the typical example we get from the Cisco books (though I’m not sure who would ever plug switches in like this…).  If we plug the switches in this way and look at the spanning-tree we’d see something that looked like this…


Ok, so to keep things simple, let’s say we are dealing with just one VLAN (VLAN 1) at this time.  As you can see, Switch3 has been elected as the root switch.  The green arrows indicate that a port is in the forwarding state and the red X implies that the port is in the blocking state.  Let’s work out the process that we took to get to this state…

The first step of the process is to elect a root bridge.  This is done by having all of the switches forward BPDU (bridge protocol data units) out of all of their active ports.  This BPDU contains a bridge ID.  The switch with the lowest bridge ID becomes the root switch.  The bridge ID consists of a 4 bit priority number (multiples of 4096), a 12 bit System ID field typically used for the VLAN ID, and a 6 byte MAC Address field.  The VLAN ID and the priority get stuck together so a switch with the default priority of 32768 would really have a priority of 32769 when running on VLAN 1. 

So in the above example, all of the switches would flood their BPDU’s out of all active interfaces.  Here is the relevant BPDU information from each switch in the above example…

Switch1 – Priority 32768 – Mac Address 0021.d7c5.f200

Switch2 – Priority 32768 – Mac Address 0012.0100.4d00

Switch3 – Priority 32768 – Mac Address 000d.2818.af00

Switch4 – Priority 32768 – Mac Address 000f.9065.4680

In this case, since the priorities are all the same, we need to find the lowest MAC address.  Start on the left hand side and work your way in when attacking the MAC addresses, if you do that, you can see that the first chunk of the MACs (2 bytes) comes out to…

Switch1 – 33

Switch2 – 18

Switch3 – 13

Switch4 – 15

That makes Switch3 our winner.  Upon receipt of a superior BPDU, a switch will stop sending it’s own BPDU and start forwarding the superior BPDU.  Eventually, all that’s left is the superior BPDU.  Now we need to determine how to determine which ports become root ports and which ports become designated ports.

Root ports are the ports that are closest to the root bridge.  The root bridge will send out a BPDU every hello time (default of 2 seconds).  A non-root bridge will receive the BPDU and update the BPDU’s, cost, the forwarding switches bridge ID, the port priority, and the port number.  The switch will then forward the BPDU out all non-blocking ports.  The port that receives the hello with the lowest cost BPDU will become the root bridge. 

Cost is determined by the speed of the interface.  Here are the common default costs…

10 Meg – 100
100 meg – 19
1 Gig – 4
10 Gig – 2

So let’s look at how that happened in the above example…

Switch3 became the root bridge and started sending BPDU hellos out of all of it’s forwarding interfaces.  This includes the interfaces connected to switch2 and switch4.  These would initially have a cost of 0 since they are starting from the root bridge.  The cost is recalculated on receipt of the BPDU. 

Switch2 will receive the BPDU and update the cost to 19 since it was received on a fast Ethernet (10/100) interface.  Switch4 will do the same since it also has a fast Ethernet Interface.  Switch1 will receive the BPDU’s with a cost of 19 from both switch2 and switch4.  So the process up to this point would look like…


Switch2 and switch4 have a pretty easy jobs picking the root port with the lowest received cost.  Switch1 on the the other hand has received multiple hello BPDUs with the same cost.  When this occurs, it will pick the BPDU with the lowest value of the forwarding bridge ID.  In this case, the lowest value comes from switch4.

Once we’ve picked the root ports, we need to pick the designated ports.  The designated ports are the ports that are allowed to send traffic onto a particular segment.  The designated port for each segment is picked by which switch sends the lowest cost BPDU onto a given segment.  So it’s pretty easy to now see how the designated ports are picked as well. 

If we look at the entire hello BPDU path, it would look something like this…


Now we have a fully converged layer 2 topology.  This piece is pretty straight forward, the more interesting pieces are reconvergence, 802.1w, and 802.1s which we’ll be covering in the next couple of posts.

Leave a Reply

Your email address will not be published. Required fields are marked *