Solved: 802.1t

siddharth4u12 · ‎01-20-2012

i have a doubt while reading the switch book by david hucaby. i am posting a output from his book so that i could get help on why exactly vlan 100 cannot be root bridge and what are the binary bit conversion taking place for the bridge id for vlan 100. specially the line where he says the resulting priority would be 104 ?? i dont understand this

below is an output where the root bridge priority is 4200.

Switch# show spanning-tree vlan 100
VLAN0100
Spanning tree enabled protocol ieee
Root ID Priority 4200
Address 000b.5f65.1f80
Cost 4
Port 1 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32868 (priority 32768 sys-id-ext 100)
Address 000c.8554.9a80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
[output omitted]
Now, the automatic method is used to attempt to make the switch become root for VLAN
100, using the command demonstrated in Example 8-2.
Example 8-2 Using a Macro Command to Configure a Root Bridge
Switch(config)# spanning-tree vlan 100 root primary
% Failed to make the bridge root for vlan 100
% It may be possible to make the bridge root by setting the priority
% for some (or all) of these instances to zero.
Switch(config)#

Why did this method fail? The current root bridge has a bridge priority of 4200. Because
that priority is less than 24,576, the local switch will try to set its priority to 4096 less
than the current root. Although the resulting priority would be 104, the local switch is using
an extended system ID, which requires bridge priority values that are multiples of
4096. The only value that would work is 0, but the automatic method will not use it. Instead,
the only other option is to manually configure the bridge priority to 0 with the following
command:

Peter Paluch · ‎01-20-2012

Hi,

The priority of the current root bridge is 4200. All recent Cisco switches consider the priority to be already split into the configurable priority and the extended system ID, even if the sender does not use 802.1t extensions (there is no way of knowing that!). From this viewpoint, the Catalyst considers the root bridge to have a priority of 4096 and extended system ID of 104.

Now, the automatic method using spanning-tree root primary command will never lower your own priority specifically to 0. That is most probably an in-built protection. Simply, if the only way to make your switch a root switch is to assign it a priority of 0, the automatic method will always refuse to do that. You will have to configure it manually.

So what you see is quite expected - and correct.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎01-20-2012

Hello,

should it not set its priority to 4096 + 100 = 4196 so that it still is lower than 4200

It is true that in this case, just by setting our own priority to 4096, the Catalyst switch should win the root role.

Current root: 4096/104/000b.5f65.1f80

Catalyst: 4096/100/000c.8554.9a80

The Catalyst BID would be lower than the current root switch, indeed!

However, the spanning-tree root primary macro seems to like to make sure that the root bridge priority is one step lower than the current root switch priority, and that would force the priority to be set to 0 - something which this macro is actually not permitted to do.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎01-20-2012

Hi,

The priority of the current root bridge is 4200. All recent Cisco switches consider the priority to be already split into the configurable priority and the extended system ID, even if the sender does not use 802.1t extensions (there is no way of knowing that!). From this viewpoint, the Catalyst considers the root bridge to have a priority of 4096 and extended system ID of 104.

Now, the automatic method using spanning-tree root primary command will never lower your own priority specifically to 0. That is most probably an in-built protection. Simply, if the only way to make your switch a root switch is to assign it a priority of 0, the automatic method will always refuse to do that. You will have to configure it manually.

So what you see is quite expected - and correct.

Best regards,

Peter

siddharth4u12 · ‎01-20-2012

so what you are saying is that when the catalyst switch considers the root bridge to have a priority of 4096 and extended system ID of 104 it will not set its priority to 4096 . should it not set its priority to 4096 + 100 = 4196 so that it still is lower than 4200

Peter Paluch · ‎01-20-2012

Hello,

should it not set its priority to 4096 + 100 = 4196 so that it still is lower than 4200

It is true that in this case, just by setting our own priority to 4096, the Catalyst switch should win the root role.

Current root: 4096/104/000b.5f65.1f80

Catalyst: 4096/100/000c.8554.9a80

The Catalyst BID would be lower than the current root switch, indeed!

However, the spanning-tree root primary macro seems to like to make sure that the root bridge priority is one step lower than the current root switch priority, and that would force the priority to be set to 0 - something which this macro is actually not permitted to do.

Best regards,

Peter

siddharth4u12 · ‎01-21-2012

thank you ... well explained !!!

aismagilov · ‎02-06-2016

Hi Peter,

... force the priority to be set to 0 - something which this macro is actually not permitted to do.

Could you please explain why?

Peter Paluch · ‎02-06-2016

Hello,

I can only speculate. I believe that Cisco decided to have this macro have a safety belt and refuse to set a priority that basically cannot be beaten (you cannot go lower than 0). If you as an administrator want to assign an STP bridge priority of 0, you have to explicitly say it and thus show that you really mean it. Also, if you use the spanning-tree vlan ... root primary command consistently to set up your root switches, you have a guarantee than anytime you need to do some "emergency" root bridge switchover, you have the priority value of 0 at your disposal, even though you need to use it manually.

That's how I see it.

Best regards,
Peter

Jon Marshall · ‎02-06-2016

Must admit I have never been a fan of using the macro command ever since I read that it is a one time calculation ie. if you run it and then introduce a new switch with a lower priority that switch becomes root and the macro is not run again.

And you don't actually know without checking what number the macro has actually chosen because it simply needs to be lower than any other switch currently in your network.

Don't know whether the one time calculation is still true but I always set the priorities explicitly ie. 4096 for root and 8192 for secondary.

Jon

Peter Paluch · ‎02-06-2016

Jon,

The macro is still a one-shot. And it's probably good that way because otherwise, if these commands were continuously active and you happened to configure two switches with the root primary command, they would fight each other until both of them went down to the priority of 0 and the base MAC address would then break the tie. In fact, the root primary command would be unusable if it was continuously active - if you had used it on one switch, and then wanted to make another switch the root, you would need to deconfigure that command from the first switch and move it over to the second.

Best regards,
Peter