Why did we really need this "spanning-tree extend system-id" command?

[nikhil.kulkarni]

Folks,

On the Spanning tree protocol I understood how does this spanning-tree extend system-id command work.

But I have not understood why it is in place? or why do we really need it?

Regards,

Nikhil Kulkarni.

[Peter Paluch]

Hi Nikhil,

The STP and RSTP standard specifications mandate that each switch running STP/RSTP must have a unique Bridge ID (BID). Because Cisco runs STP or RSTP in each VLAN separately (called PVST and RPVST or PVRST), in each VLAN, the switch behaves like a standalone (albeit virtual) switch and thus, each STP/RSTP instance is required to have a unique BID to comply with the standard. Simply, having X VLANs means having X separate STP/RSTP instances and X unique BIDs.

The question now is how to make sure the BIDs of STP/RSTP instances run on the same switch in different VLANs are truly unique. Older switches actually had a large reserve of MAC addresses. As new VLANs were created, these switches allocated a new MAC address for each new STP/RSTP instance in a new VLAN (recall that the BID originally consisted of the priority and the MAC address), making the BIDs unique.

However, the consumption of MAC addresses this way was simply too large and ineffective. At the same time, having 65536 different values for priority in the BID was largely useless. So IEEE came with the idea of Extended System ID in which they reused a part of the priority field for a unique instance identifier. In Cisco's implementation, this field is populated with the VLAN number the STP/RSTP instance runs in. This easily and effectively makes the BID unique - even with the same priority for all VLANs on a single switch, and a single switch MAC address, multiple STP/RSTP instances running on this same switch with the same priority have different BIDs thanks to different VLAN numbers embedded into the BID.

Some switch platforms actually allowed you to deactivate the Extended System ID and revert to the older style of assigning unique MAC addresses to individual STP/RSTP instance BIDs. That is why the command spanning-tree extend system-id exists in the first place. However, removing this command is only possible on those switching platforms which are equipped with 1024 MAC addresses for their disposal. Most new switching platforms have only 64 MAC addresses for their internal use, and while the spanning-tree extend system-id command is present in their configuration, you can not remove it. It is simply there to inform you that the Extended System ID is being used but you can not really deactivate it.

Read more here:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/spantree.html#wp1096536

Best regards,

Peter

[Rolf Fischer]

Hi Nikhil,

I think Peter gave a fantastic explanation and there's nothing important to add.

But if you want to memorize a single term: "MAC-Address  reduction feature"

I always liked that CatOS term, it's pretty much self-explaining.

Best regards

Rolf

[Peter Paluch]

Hi Rolf,

I am honored, thank you! - and oh, yes, the MAC Adress Reduction Feature - that's the term I forgot!

Best regards,

Peter

[Jon Marshall]

I am bumping this post up again because a question was asked about why a switch needs to have a unique BID per vlan. I gave a rather bad answer so i then started to look into it and still cannot work exactly why.

I understand the specifications mandate a unique BID per STP instance. So when Cisco introduced PVST to comply with the standards they needed to have a unqiue BID per vlan. This was achieved either by using a unique mac address per vlan or utilising the extended system id.

But is that the only reason ?

I ask because, as pointed out by the OP in a recent thread there is nothing in the BID that identifies the vlan itself. So the switch must keep a record of which BPDUs belong to which vlan. So why can't the switch simply have one BID for all vlans ie.

if the BID is not used to derive the vlan then a shared mac address would still uniquely identifty the sending switch. So if you needed to change the priority for a specific vlan then you could still do that ie. 

1) the receiving switch would receive a BPDU per vlan.

2) the BPDUs would all have the same mac address but it doesn't matter because they are per vlan

3) so for that specific vlan the switch would know the switch that transmitted the BPDU was x prioritry for that vlan

I initally thought that because the BID was not unique that the switch would not be able to work out which vlan each BPDU belonged to.

But it can't do that from the BID even if it is unique.

In both cases it is the vlan ID in the frame tag that tells the switch which vlan this BDPU is for.

I know i am missing something here. But i can't see it.  I am hoping someone a lot more intelligent than me eg. Peter, comes along to explain it all.

I have to admit i am seriously considering relinquishing my HoF status (and probably VIP as well) as if i cannot work this out i'm not really sure i deserve them

Jon

[Ahmet Mustafa Mungan]

Hi to all,

I know that there has been 3 years after this thread. However I have the same question with Jon. Does anybody has the answer?

Kind Regards,

Ahmet Mustafa Mungan

[JaakkoRau]

I think I know answer why is that. By doing configuration mistake it is possible to merge two VLANs between two switches. If you change native VLAN just one end of the link between switches, two VLANs are merged. This leads to PVSTP instances to merge as well. This could potentially lead to a situation where Switch A (on vlan 1) can "see" itself on VLAN 100 via Switch B. If switch B has configured bigger priority number and switch A should become root. Which one of the two equal BID:s of Switch A would become root?!

Or if there were standard STP switch having no per VLAN capability connected to PVSTP switch, it could mix up BPDUs received on different VLANs with same bridge ID.

I cannot explain this exaclty but this is what I'm thinking it relates to.

[JaakkoRau]

I did small lab exploring this:

SWA G0/0 (VLAN1) <---Access link---> (VLAN100) G0/0 SWB

SWA G0/1 <------------Trunk link ------------->G0/1 SWB

Trunk link is allowing just VLAN100. SWA has been configured with:

spanning-tree vlan 1 priority 24576

So it should become root in VLAN 1. However, SWA sees root for VLAN100 itself in VLAN1:

SWA#show spanning-tree bridge

                                                   Hello  Max  Fwd
Vlan                         Bridge ID              Time  Age  Dly  Protocol
---------------- --------------------------------- -----  ---  ---  --------
VLAN0001         24577 (24576,   1) 00f8.16e1.6a00    2    20   15  rstp
VLAN0100         32868 (32768, 100) 00f8.16e1.6a00    2    20   15  rstp
SWA#
SWA#
SWA#show spanning-tree root

                                        Root    Hello Max Fwd
Vlan                   Root ID          Cost    Time  Age Dly  Root Port
---------------- -------------------- --------- ----- --- ---  ------------
VLAN0001         24577 00f8.16e1.6a00         0    2   20  15
VLAN0100         24577 00f8.16e1.6a00         8    2   20  15  Gi0/1

SWB#show spanning-tree root

                                        Root    Hello Max Fwd
Vlan                   Root ID          Cost    Time  Age Dly  Root Port
---------------- -------------------- --------- ----- --- ---  ------------
VLAN0001         32769 00f8.166e.3f00         0    2   20  15
VLAN0100         24577 00f8.16e1.6a00         4    2   20  15  Gi0/0

This is because of VLAN 1 and VLAN 100 are merged in SWB. If SWA had same BID:s for both VLAN1 and VLAN100 it would result to mad situation where STP cannot decide who will become root bridge.

[dustin.dummer]

I still cannot find my answer to this: the System ID Extension has values from 1 to 2048. The default is 1. I'm assuming from default VLAN 1. But how can the System ID Extension even change from 1 to another value? I don't see any documentation where a configuration change can alter the System ID Extension value. I understand, it becomes irrelevant if you manually set the Bridge Priority or Primary/Backup but it bothers me that there are alternate values without understanding how those values are determined.

[dustin.dummer]

Do I understand this correctly: without manually designating a root bridge, the root bridge would be selected from switches that include the highest vlan id, as this would increase the extended id value within the switch(es) in which that vlan exists? Every time I've ever looked at the extended vlan id in Packet Tracer, the extended system id has always been 1. I need to review a multi-vlan configuration again.

[JohnTylerPearce]

Jon,

It's ok, there are enough Johns to go around

I must say this has been an excellent thread, and I"m glad I found it. It makes waking up at 3am worth it, at least for right now....