We’re going to be talking about 802.1D, this is the classic spanning-tree protocol and NOT as my good colleague suggested the model number for the Enterprise in Star Trek 'Next Generation' which we all know was the NCC 1701D.


We all like failover, fallback and redundancy in our networks. Resilience to failure of any one (or more) components in the network is always a good thing. In the switching world we use spanning tree to offer us the ability to create a dynamic loop free layer 2 bridge topology. How does it do this? Well by using specific frames on the network called BPDU's (Bridge Protocol Data Units) the spanning-tree protocol dynamically 'blocks' one of the links in the redundant loop.

Here is the basic topology


Here we have a physical loop for traffic moving from Switch A to Switch B to Switch C or Switch A to Switch C to Switch B...you get the idea. The point is that traffic flow like that can easily and very quickly get out of hand and cause what is common miss-quoted as a spanning-tree loop but which is in fact a bridging or switching loop.

In a bridging loop example, Switch C receives a request from a node connected to one of it's ports (Client PC). The destination for the request is to an unknown host (Web Server) connected to Switch A. Now Switch A (who doesn't know Web Server is connected to Switch A) broadcasts the frame out of all ports (remember, this is the default behaviour of a switch for an unknown destination mac address). The layer 2 mac request is picked up by the host connected to Switch A who politely passes that information back to Switch C ("Hey I'm Web Server and here is my MAC address so populate your mac table!"). Now crucially Switch_B forwards the initial lookup sent from Client PC out of all of it's ports (remember it also doesn't have a layer 2 mapping for the frame). The MAC request gets to Switch_A from Switch_B and Switch A forwards the frame to Client PC and that's all fine. Now also recall that Switch A is going to flood the frame out of all ports except the one it received from. This means that the frame from Switch B is sent out toward Switch C! So you can see how a switch could get confused about which way to send traffic and this is for a unicast lookup. Now if we think about broadcast traffic where the frame is always sent to all ports this loop design is going to cause some headaches. Indeed I've seen this sort of thing bring down pretty big switches very very easily and they are difficult to find  except for asking who just did something ;-)

So spanning-tree is pretty essential for workable layer 2 resilience. In the diagram you can see an etherchannel there though...and thats a loop isn't it? Two links between switches...feels a bit 'loopy' to me. Well you know etherchannel in IOS and LAG in JunOS are a great way of adding resilience between switches as well as capacity and the good news is that to spanning tree they look like one link.

Thanks for reading and the colleague who suggested 802.1D was the model number for the Enterprise wishes you all a good night.


View Comments
Here is the basic topology.

R1 and R3 are connected using port FastEthernet0/0
R1 and R2 are connected using port FastEthernet0/6
R2 and R3 are connected using port FastEthernet0/12

Screen shot 2011-04-20 at 22.14.15

Lets create a new VLAN 100 on each ‘switch’

Screen shot 2011-04-20 at 22.19.53

So now lets run through all the switches setting up each connected port as a trunk. We don’t need to set the encapsulation since these only support 802.1q but we’ll do it anyway...

Screen shot 2011-04-20 at 22.22.33

When all the ports are up lets wait for spanning-tree to converge.

Screen shot 2011-04-20 at 22.25.37

On R3 the port FastEthernet0/12 is ‘blocking’.

Screen shot 2011-04-20 at 22.26.03

So let’s move the blocked port to R2’s FastEthernet0/12 interface. To do that we need to make the cost of ‘getting’ to R3 easier than getting to R2. So lets lower the port cost on the interface closest to the root switch.

Screen shot 2011-04-20 at 22.59.02

The default port cost for FastEthernet is 19 so a cost of 1 is preferred. Now looking at R2 we’ve got the result we wanted.

Screen shot 2011-04-20 at 22.59.30
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.