Why does the bridge ID for each vlan on a switch have to be unique?

[Leroy Plock]

Hi all,

I have this feeling I'm going to feel stupid when I hear the answer to this, but I've looked around a lot and asked a lot of people and haven't gotten a satisfactory answer.

There are a number of discussions around about the spanning-tree extended system id and why it is needed to make the bridge ID unique for each vlan on switches that only have 64 base MACs. With extended system ID the switch can use the same base MAC for all VLANs yet have unique Bridge IDs. On switches with 1024 MACs available, you can do PVST+ without using extended system id, the switch assigns a unique MAC for each VLAN, and thus the bridge IDs are unique.

I understand all this, but there seems there's an un-asked question in there: Why does each VLAN on a switch need a unique bridge ID?

Obviously each bridge _within_ a vlan needs a unique ID or the root bridge election couldn't work. But why would it matter if a given switch used the same Bridge ID for all its VLANs?

Can anyone explain? Thanks.

[Jon Marshall]

Leroy

Because usually it is per vlan STP ie. you have an instance of STP per vlan. The root bridge is generally the same for all vlans but it doesn't have to be. If you used the same bridge ID for all vlans then you couldn't distinguish between vlans per switch.

Because each switch calculates STP on a per vlan basis they need a way to distinguish between vlans.

Jon

[leroyplock]

Jon,

Thanks for your reply. I've had this answer proposed before, but it doesn't make sense to me. With PVST(+) the VLAN ID is identified within the BPDU, so this is how you distinguish between VLANs.

If the VLAN ID were not included in the BPDU, you could deduce the Bridge ID IF you're using the extended system ID. But extended system ID isn't required for PVST(+). Without extended system ID and without the VLAN being identified within the BPDU, how would a switch know what VLAN an incoming BPDU is for?

In other words, if I send you a BPDU without extended system ID and no VLAN ID within the BPDU, how would you know which VLAN that BPDU was for? The fact that I keep a unique Bridge ID per VLAN doesn't help you at all.

Thanks for helping me understand this.

[Jon Marshall]

Leroy

I just deleted my last post because the logic of it was all wrong ie.

if as i argued the BID is not used to derive the vlan but merely to be unique per vlan then i cannot, at the moment, see why you cannot have the same BID for all vlans as you yourself say.

There is a requirement in the specifications that each STP instance needs to have a unique BID but that is not a good enough answer to me. There has to be a reason but for the moment it alludes me.

My suspicions are to do with the way the switch process the BPDUs but i am struggling to see how it relates directly to the BID.

I shall try to find out a good answer to your question although, as you have probably already worked out, with my limited intelligence that may be quite a challenge

Jon

[Peter Paluch]

Leroy, Jon,

Please allow me to join.

Leroy, you have a great question - with (R)PVST, is it really necessary to have a unique BID for each per-VLAN STP instance on a single switch?

Technically taken - no, it is not necessary. In fact, that is what plain 802.1D on a (non-Cisco) VLAN-aware switch would do: as it runs just a single STP instance, mapping all VLANs onto it, it would present itself using a single BID.

I believe the (R)PVST would work nicely with a simple per-switch BID in all STP instances. However, 802.1D requires that each switch has a unique BID, and because a single physical switch running (R)PVST acts as multiple virtual switches to the outside world, one for each VLAN, full compliance with 802.1D also requires that each of these virtual switches has a unique BID. I would say this is more to satisfy the 802.1D requirement that was, at the time, oblivious to VLANs, than a technical must.

Best regards,

Peter

[Jon Marshall]

Hi Peter

It really is a good question. 

I even posted into another thread of yours about this very subject.

So it really is just a complicance thing after all. I have spent almost half a day now trying to work out a scenario where a unique BID is actually needed (other than compliance) and couldn't see why it would be.

Leroy, thanks for testing out the brain cells and apologies for my original answer.

You obviously worked this all out a lot quicker than me

Jon

[Peter Paluch]

Jon,

To be honest, I am myself not 100% sure if I haven't omitted any obscure fact in which a duplication of BIDs in PVST instances would lead to either a loss of connectivity or a permanent switching loop. I have to see that yet. But I have tried to construct a few counterexamples and came up with nothing.

By the way, you may be interested in knowing that in PVST Simulation process used on MST boundary ports towards a PVST world, the MST boundary switch takes the IST instance data and plainly replicates them into PVST BPDUs without doing any change to the advertised root or sending BID. This is what a PVST switch connected to a MST switch (with the MST region being the root) would see:

ASW1#show span root
                                        Root Hello Max Fwd
Vlan                   Root ID          Cost  Time Age Dly  Root Port
---------------- -------------------- ------ ----- --- ---  ----------------
VLAN0001          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0002          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0003          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0004          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0005          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0006          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0007          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0008          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0009          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0010          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0011          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0012          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0013          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0014          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0015          4096 aabb.cc00.2500       100    2   20  15  Et0/0           
VLAN0016          4096 aabb.cc00.2500       100    2   20  15  Et0/0           

Notice how in all VLANs, the reported root BID is the same. So the Cisco's own PVST Simulation that causes the IST data to be replicated into PVST BPDUs sent out from the MST switch towards this switch does not bother with actually making up the unique BIDs at all! I would say this supports our theory of a unique per-switch BID actually being technically okay, just for perfect 802.1D compliance, unique BIDs are strongly called for. Would you agree?

Best regards,

Peter

[Jon Marshall]

Peter

would say this supports our theory of a unique per-switch BID actually being technically okay, just for perfect 802.1D compliance, unique BIDs are strongly called for. Would you agree?

Yes, i do agree.

I haven't got switches to test with but i drew out a number of topologies etc. and could not find any scenario where there would be a requirement for a unique BID. As far as i can see it all comes down to the fact that unique or not the BID is never used to derive the vlan ID so from a technical perspective in terms of operation it really doesn't matter.

Very interesting test you did and it does lend weight to the theory that switches are more than capable of handling a common BID among vlans. 

So i guess at the moment it looks like it really is just to comply with the standards that a unique BID per vlan is a requirement rather than any specific technical reason as to why it won't work.

Jon

[leroyplock]

Thanks for the input everyone. I'm relieved this doesn't appear to be quite as stupid a question as I had feared. This discussion is really helping me get inside spanning tree for my SWITCH exam.

As far as the 802.1D spec calling for unique BIDs, 802.1D doesn't know VLANs from apples, so I don't think it would have ANYTHING to say about multiple BIDs on the same switch. Saying 802.1D requires unique BIDs per switch, therefore PVST+ creates unique BIDs per VLAN within a switch seems a little fuzzy. But we weren't invited to the meetings when they designed PVST so maybe that is what they were thinking.

Peter, very nice job illustrating the non-unique root bridge ID on a PVST switch connected to a MST switch. Definitely bolsters the argument that unique BIDs per vlan aren't a necessity.

I keep wondering if the the Unique BID per vlan might somehow become important when interoperating with 802.1D or 802.1S, but I can't think of a reason why that would be.

One way to think of this at a high level is this:

1. The Bridge ID only serves to: A) elect a root bridge, and B) be a tie-breaker when determining Root Ports and Designated Ports.

2. A & B are only significant within a VLAN.

3. Thus, the Bridge ID is only significant within a VLAN.

Maybe someone with a deeper understanding will tell us why the unique BID per vlan is needed. I'll be glad when I get past the test so I can quit thinking about this.

[Peter Paluch]

Leroy,

Just a single comment:

Saying 802.1D requires unique BIDs per switch, therefore PVST+ creates unique BIDs per VLAN within a switch seems a little fuzzy.

Keep in mind that with per-VLAN STP, each STP instance behaves from outside as if it was running on a different switch (VLANs themselves virtualize a single switch into multiple switches). Hence, if a separate switch, or better said, a separate bridging entity needs a unique BID, and a VLAN can be considered a separate bridging entity, Cisco's PVST goes with unique BIDs per VLAN per switch.

Best regards,

Peter