cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3418
Views
20
Helpful
7
Replies

Difference between Root Bridge Priority configured and advertised

Pedro Matias
Level 1
Level 1

I have a spanning tree configured. When I change the root bridge's priority from 32768 to 32767, I observe something very weird in Wireshark. As you can see in the packet dump I posted, the root bridge priority didn't change from 32768 to 32767 like I expected,  but it changed to 28672, along with the Root Bridge System ID Extension going from 0 to 4095. You can also see in the packet dump that the root bridge stays the same, as expected.

Why the discrepancy between the value I configured in the switch and the value advertised in the BPDU?

For the switches I'm using a c3725 with NM16-ESW, in GNS3. Is this a bug?

Edit- As you can see, the value of the priority configured is 32767.

Sw1#sh spanning-tree

VLAN1 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 32767, address c201.1671.0000
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree

2 Accepted Solutions

Accepted Solutions

Hello
The bridge id is the cumulative value of the bridge vlan priority and the vlan id .
Example
spanning-tree vlan 4094 priority 28672

sh spanning-tree vlan 4094 | in Pri
Root ID Priority 32766
Bridge ID Priority 32766 (priority 28672 sys-id-ext 4094)   


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

View solution in original post

you dont answer me, but I will clear the idea here, 
if STP SW connect to PVST what will be bridge ID ??
PSVT use SW MAC+ VLAN + priority 
STP use SW MAC + priority 

so what you see is simply the compatibility between PVST and STP. 
that it. 

View solution in original post

7 Replies 7

are one side run PVST and other run STP (IEEE) ?

Hello,

In spanning tree priority you can only modify the Bridge priority in increments of 4096. You just decremented it by 1 which is not allowed. The bridge priority ranges from 0 to 61440 in steps of 4096Maybe the system auto-corrected you since 32,768-4096 = 28,672.

The system ID extension is representative of the '4096' VLANs (1-4095) since most switches run a per-VLAN spanning tree instance. When you configure a priority (in increments of 4096) it tacks on the VLAN number as an ID extension.

 

Hope that helps

-David

In this case I believe, like @paul driver said, that the system ID extension is not representing a system ID extension at all (meaning, it doesn't refer to any Vlan number) and is part of the Bridge Priority. Since there is only one Vlan, the priority can actually be 32767. If there were multiple Vlans configured, the bridge priority could indeed only be changed in steps of 4096.

Edit- The above information is partially wrong, in particular the last sentence is wrong. I just tried to configure two Vlans, Vlan 1 and Vlan 2, and assigned the root bridge of Vlan 2 a priority of 32767 and it worked. The reason it is working is because in this case the switches only communicate between each other with trunk ports. This way, the Vlan number is identified by the 802.1Q tag, and the switches consider the System ID as part of the priority.

In the attachments you can see the network I'm using, with f1/0 to f1/3 being Vlan1, f1/4 to f1/7 vlan 2, and f1/11 and f1/12 being trunk ports. You can also see a packet dump showing a priority of 32767 in Vlan 2 - look at the 802.1Q tag saying it is vlan 2 and the priority being 32767.

Hello
The bridge id is the cumulative value of the bridge vlan priority and the vlan id .
Example
spanning-tree vlan 4094 priority 28672

sh spanning-tree vlan 4094 | in Pri
Root ID Priority 32766
Bridge ID Priority 32766 (priority 28672 sys-id-ext 4094)   


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Can't this cause confusion in deciding which VLAN the frames belong to?

In this situation, there is only one VLAN configured, VLAN 1. When I changed the priority to a value that wasn't a multiple of 4096, to make the Bridge Priority and System ID Extension add up to that value (32767), the BPDU changed the System ID Extension from 0 to 4095.

Now doesn't it look like the new BPDU, the one highlighted in Wireshark in the screenshot, is actually a BPDU with Bridge Priority 28672 that belongs to Vlan 4095 (the System ID Extension value), and not to Vlan 1?

Do the switches ignore this discrepancy in System ID Extension because there is only one Vlan configured in all of them?

Edit- I think I understand now. Since there is only one Vlan configured, the switches are using normal STP, and thus don't look at the System ID Extension as a System ID Extension but consider all the 2 Bytes of Bridge Priority (the first 4 bits of those 2 Bytes) concatenated with System ID Extension as a single value representing only the Bridge Priority (the full 2 Bytes).

If there were multiple Vlans, like @David Ruess said, it would be impossible to change the Bridge Priority to 32767 because that is not a multiple of 4096.

What is happening in the packet dump is that Wireshark is misinterpreting the frame as corresponding to a network configured with multiple Vlans, and thus it presents the 2 Bytes of Bridge Priority as being divided into Bridge Priority and System ID Extension, when in reality in this case they are not separated.

Am I correct?

you dont answer me, but I will clear the idea here, 
if STP SW connect to PVST what will be bridge ID ??
PSVT use SW MAC+ VLAN + priority 
STP use SW MAC + priority 

so what you see is simply the compatibility between PVST and STP. 
that it. 

Hi @MHM Cisco World , yes that is indeed correct. I had a reply written down to you, but forgot to send it. Even though both times the protocol being used is STP, and never PSVT, it seems like Wireshark assumes it is PSVT.