cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
32218
Views
1
Helpful
3
Replies

Original vs. Extended VLAN

rravergalileo
Level 4
Level 4

So I've been reading and teaching some basic CCNA stuff.  I was asked why the original VLAN range is what it is and what made the extended VLAN range it is what it is.  Does anybody have any insight or clarification into this?  The max I can find is that the dot1q header has a field in the frame that it tags into the ethernet header for VLAN ID.  This is a 14 bit field meaning 2 to the power of 14 or 4096.  4096 translates to 0-4095 minues the top and bottom which creates 1-4094?  Now the question becomes a little more difficult when you ask this for the original or normal range.  I've read conflicing reports between the CCIE 4th edition R & S and the LAN field manual.  CCIE says that normal is 1-1005 with 1002-1005 being reserved and extended going to 1006 to 4094.  The field manual says that 1001-1024 is reserved and the extended goes from 1025-4096 numbers.  If you take the field manual side of things and I read that the ISL header used to or still does use only use 10 bits for the VLAN ID field.  2 to the power of 10 would be 1024 and line up.  Is it the case that it really is that simple?  VLAN ranges were defined when trunking was defined and the limits have never been stretched that far so the number of bits in the original trunking frames dictated the number of VLAN's we can have?  Also, the documentation I also read states that the VLAN ID field within the ISL encapsuation is 15 bits, so is it the case that it used to be 10 bits or just uses 10 bits out of it?  Or is the 10 bit theory pulled out of the interwebz of lies...  Ideas?  Comments?

Rob

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Rob,

First of all, the normal range VLANs are 1-1005 inclusive. Starting with 1006 and going up to 4094 inclusive, these VLANs are called extended range VLANs by Cisco. VLANs 1002-1005 are reserved on Cisco switches for backward compatibility with old VLAN implementations in now-defunct link layer technologies and can not be used, deleted or modified. Also the VLAN 1 is an immutable and omnipresent VLAN. Apart from these 5 VLANs, however, all other VLAN IDs can safely by created and used. Personally, I do not agree with the field manual stating that the VLANs in the range 1001-1024 are reserved. To my experience, on all recent Catalyst platforms, only the VLANs 1, 1002-1005 are reserved. It is possible, however, that some other older IOS/CatOS implementations indeed considered the VLANs 1001-1024 as reserved - although it is not the way it works now, and I never stumbled across those.

Regarding the maximum limit of 4094 VLANs on 802.1Q tagging: that is caused by the fact that the 802.1Q tag uses 12 bits for VLAN ID, hence 2^12 = 4096 unique IDs. VLAN ID 0 and 4095 are reserved by the standard, and VLANs 1-4094 are available for usage purposes according to the IEEE 802.1Q standard.

With ISL, I do not know for sure. The ISL format has actually 15 bits reserved for VLAN ID, see

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094665.shtml#topic1

That would allow for 2^15 = 32768 unique VLAN IDs, more than the 802.1Q. Why the original ISL implementation chose to support only VLAN 1-1005 - I do not know for sure. In my understanding, it was simply an implementor's choice. At the time, the limit of 1005 unique VLAN IDs was most probably deemed sufficient (note that the maximum number of concurrent VLANs was considerably lower - at most 64 or so). When the 802.1Q standard came, quite a few years later, it defined the range to be up to 4094, and because it was the official standard, Cisco extended the numbering into the so-called extended range, and that was it. Considering the fact that 802.1Q is the standard and ISL is spoken only by Cisco devices, there was obviously little point in extending the ISL to support 2^15 VLANs though technically possible.

So that would be my personal unofficial explanation. But still, I would like very much a Cisco person to share his/her own view of this. Francois Tallet, Matt Blanshard, anyone - where are you guys?

Best regards,

Peter

View solution in original post

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hi Rob,

First of all, the normal range VLANs are 1-1005 inclusive. Starting with 1006 and going up to 4094 inclusive, these VLANs are called extended range VLANs by Cisco. VLANs 1002-1005 are reserved on Cisco switches for backward compatibility with old VLAN implementations in now-defunct link layer technologies and can not be used, deleted or modified. Also the VLAN 1 is an immutable and omnipresent VLAN. Apart from these 5 VLANs, however, all other VLAN IDs can safely by created and used. Personally, I do not agree with the field manual stating that the VLANs in the range 1001-1024 are reserved. To my experience, on all recent Catalyst platforms, only the VLANs 1, 1002-1005 are reserved. It is possible, however, that some other older IOS/CatOS implementations indeed considered the VLANs 1001-1024 as reserved - although it is not the way it works now, and I never stumbled across those.

Regarding the maximum limit of 4094 VLANs on 802.1Q tagging: that is caused by the fact that the 802.1Q tag uses 12 bits for VLAN ID, hence 2^12 = 4096 unique IDs. VLAN ID 0 and 4095 are reserved by the standard, and VLANs 1-4094 are available for usage purposes according to the IEEE 802.1Q standard.

With ISL, I do not know for sure. The ISL format has actually 15 bits reserved for VLAN ID, see

http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080094665.shtml#topic1

That would allow for 2^15 = 32768 unique VLAN IDs, more than the 802.1Q. Why the original ISL implementation chose to support only VLAN 1-1005 - I do not know for sure. In my understanding, it was simply an implementor's choice. At the time, the limit of 1005 unique VLAN IDs was most probably deemed sufficient (note that the maximum number of concurrent VLANs was considerably lower - at most 64 or so). When the 802.1Q standard came, quite a few years later, it defined the range to be up to 4094, and because it was the official standard, Cisco extended the numbering into the so-called extended range, and that was it. Considering the fact that 802.1Q is the standard and ISL is spoken only by Cisco devices, there was obviously little point in extending the ISL to support 2^15 VLANs though technically possible.

So that would be my personal unofficial explanation. But still, I would like very much a Cisco person to share his/her own view of this. Francois Tallet, Matt Blanshard, anyone - where are you guys?

Best regards,

Peter

Hi Peter,

If we want to Spread-out the Extend VLANs in VTP running network, is it required to enable the VTP version 3 in network DB and access switches?

If Switch is in VTP transparent mode , how to configure the extend VLANs in that scenario.

Regards

deb

Hi  

 ,

 

The answer for your question can be found in this topic:

https://supportforums.cisco.com/t5/lan-switching-and-routing/vlan-extended-range/td-p/2010796

 

"VTP version 1 and version 2 support only normal-range VLANs (VLAN IDs 1 to 1005). In these versions, the switch must be in VTP transparent mode when you create VLAN IDs from 1006 to 4094. VTP version 3 supports the entire VLAN range (VLANs 1 to 4094). Extended range VLANs (VLANs 1006 to 4094) are supported only in VTP version 3. You cannot convert from VTP version 3 to VTP version 2 if extended VLANs are configured in the domain"

 

"Extended-range VLAN configurations are not stored in the VLAN database, but because VTP mode is transparent, they are stored in the switch running configuration file, and you can save the configuration in the startup configuration file by using the copy running-config startup-config privileged EXEC command."

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco