Solved

# Spanning-tree Implementation changes

Posted on 2011-10-20
808 Views
Hi,

We are collapsing all our smaller switches (2960s and 3750s) into 2 6509s.  One of the 3750s is the root bridge for all our vlans, the other 3750 is the secondary root bridge for all our vlans.  We would like to have the 6509s replace all our other switches first, and then do the root bridges last.

For example, for vlan 1, the Primary root bridge switch has that vlan with a root bridge of 24577 (when you plug in a switch with no configuration, it defaults the vlan to 24576, and then every vlan gets incremented by 1, unless someone manually configures the bridge ID).  Then, when the secondary root bridge was plugged in, it has a bridge ID of 28673, which is greater than 28673, so it becomes a backup root bridge.  The root bridge of the spanning tree is the bridge with the smallest (lowest) bridge ID.  So the smaller the number, the closer you are to being the root bridge.  When we go to plug in these new switches, we must give them all bridge IDs greater than the root bridge IDs.  Once we fold in the 3750 switches that are the root bridges, we must redo this, giving them smaller numbers than the current primary root bridges before yanking them.

Now, according to my research: Interestingly, with spanning tree, the cmd is spanning-tree vlan X priority X.  But with the priority keyword, the range is 0 to 61440 in increments of 4096, assigning the first number of the interval to a vlan on the switch, and then that switch can only use IDs in that range (ie, the primary root bridge switch can only use 24576 to 28671).  The default spanning tree value with a switch is 32768.  Only the following number can be used as a priority value.

0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152 ,53248, 57344, 61440.

Is this correct ?

We cannot use 24576, because it is being used by the spanning tree root bridge, so we can only use numbers bigger than that.  Cannot use 28672 because it is being used by secondary root bridge switch.  Cannot use 32768 because that is on a 3rd switch.

Questions :
1. Is the thought process correct ? We give these vlans the worst possible spanning tree priority (61440 and beyond) on the new 6509s, and then we fold in all other switches.  When we do the primary root bridge and secondary root bridge, we redo the vlan priority again, but give the vlans priorities lower that the current root bridge and secondary root bridge?
2. I checked another switch  (4th 3750) and it has a number of vlans with numbers 32960, 32856, and 32772, which would conflict with the interval for the 3rd switch mentioned above.  How is this working?  Or is the Cisco document about the intervals no longer valid ?
3. The cmd string per vlan is :
config t
spanning-tree vlan x priority x
does this sound correct ?
4. Anything else I am missing ?

0
Question by:Elemental12

LVL 26

Expert Comment

I think you are overthinking it. I say clean your slate and start from scratch. The simple fact that you are changing the layer 2 topology would lead me to want to redo the vlan priorities anyway.

On another note, have you considered doing layer 3 to the access layer and rely on dynamic routing for convergence instead of spanning tree?
0

Author Comment

We cannot go total clean slate ... We get very short maintenance windows here, so we can only move one or two switches at a time.  Well, we have to redo the vlan priorities because the root bridges are going away.

We thought about going layer 3 for a bit, but we are collapsing 10 small switches into two 6509s so we figured Layer 2 switching is fast enough for us.
0

LVL 26

Expert Comment

Okay, so when you install the 6509's why can't you just enter spanning tree root primary and secondary for all of the vlan?
0

LVL 50

Assisted Solution

>Only the following number can be used as a priority value.
>0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152 ,53248, 57344, 61440.
>Is this correct ?

Yes.

1. Pretty much.

2. Cisco uses a methodology known as "Extended System ID". Basically they take the defined priority and add the vlan number to it. So if you assigned the priority of 16384 to a switch, for VLAN 12, the priority would be 16396 (16384+12=16396).

3. That is the correct command syntax.

Your approach is workable. Add the new switches with default priorities. Your existing switches will remain their root status as defined. Once you're ready, lower the priority on the new switches to be lower than the existing switches.
0

Author Comment

Because those two switches are serving apps that cannot go down/be interrupted until 2nd quarter next year, so we need to continue forward movement by replacing the switches that have apps that can be interrupted sooner rather than later.
0

Author Comment

I appreciate your comments.  I will leave this open for the next day or so in case anyone has other suggestions.  As you can see this is a heavy lift for me, so I really want to make sure I do not miss anything and that it goes as seamless as possible.  I have a ticket open with Cisco TAC as well, but I like to get the "real world" take on upgrades like this as well.
0

Author Comment

My other question is about these intervals.  Do I need to check all my switches and find out what intervals they use?  I guess I can do 57344 on one 6509 and 61440 for the other.
0

LVL 26

Accepted Solution

I still say just use the spanning-tree vlan <vlan range> root primary and secondary commands on the 6500's It will take care of the priority numbering.
0

Author Comment

but I cannot make these two 6509s primary and secondary until the very end
0

LVL 26

Expert Comment

I understand that, do as Don stated and add them with their default priorities, then make them primary and secondary roots when you reach that point.
0

LVL 50

Expert Comment

The intervals are irrelevant.  The only thing that matters is that the desired root has a LOWER priority than the others switches.
0

Author Comment

Soulja, thanks ... rather than me manually putting in priorities, I will use the primary and secondary cmds as you suggest ...

DonJohnston, thanks for the clarification, and yes, the lower priority is the only thing that matters ... thanks
0

LVL 6

Assisted Solution

I think everything has already been covered here but wanted to add the following.

The reason for the priority part of the BID requiring values in increments of 4096 upto 61440 is because the priority is a 16 bit value, made up as follows:

| priority | system-id |
4 bits        12 bits       = 16 bits

As noted by @donjohnston cisco use an extended system-id.  This refers to the VLAN number which is a 12 bit value.  So that the remaining 12 bits can refer to the vlan id, the 4 bit priority goes up in increments of 4096 making the remaining 12 bits zero until the vlan id is added.

This priority value + the base MAC of the switch makes up the BID and the lowest BID becomes the root switch on a per vlan basis.  So as you've already noted as long as you leave the priority of the 6509's you're adding at their default of 32768 they will have higher BID's on a per vlan basis than the current root and secondary 3750's.

The "spanning-tree vlan X root primary" and "spanning-tree vlan X root secondary" are actually commands that execute a macro which sets the priority based on that of the current root switch.  The "root primary" command will set the priority to 24576 if the current root is higher than this or automatically sets it lower in increments of 4096 if the current root has a priority of 24576 or less.  The "root secondary" sets the priority to 28672 as it assumes this will be higher after the root primary command has been executed on another switch.  After using these commands you'll see in the config that the actual priorities are explicitly set.  So if in the future a switch is added with a lower priority then this could in thoery then take over as a root switch.  Entering these commands doesn't necessarily mean your making a switch the root forever.

I obviously don't know your topology but you could make one switch root for one set of vlans and the other root for the remaining thus load-balancing L2 traffic over what would be the redundant links.

--IJ

0

## Featured Post

### Suggested Solutions

In the world of WAN, QoS is a pretty important topic for most, if not all, networks. Some WAN technologies have QoS mechanisms built in, but others, such as some L2 WAN's, don't have QoS control in the provider cloud.
Outsource Your Fax Infrastructure to the Cloud (And come out looking like an IT Hero!) Relative to the many demands on today’s IT teams, spending capital, time and resources to maintain physical fax servers and infrastructure is not a high priority.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…