Native Vlan

Unanswered Question
Dec 10th, 2007
User Badges:

Guys i know the concept of Native Vlan....but my question is what is the need of native Vlan.......what is the point of sending untagged traffic......why we do that or what is the need can someone plewase explain in easy language.....Thanks in advance

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Francois Tallet Mon, 12/10/2007 - 16:19
User Badges:
  • Gold, 750 points or more

That's a compatibility thing that was introduced by the IEEE when they designed 802.1Q. If you are able to send untagged traffic, you can provide connectivity to devices that don't understand the 802.1Q tag. Also, IEEE control protocols sent untagged message and which are not replicated on a per vlan basis. This way, a vlan unaware bridge can still run in a 802.1Q network. Cisco does not have any vlan unaware bridge (and in fact, implements an instance of STP per vlan by default), so the use for untagged vlans is much less obvious;-)

Regards,

Francois

bvsnarayana03 Mon, 12/10/2007 - 22:33
User Badges:
  • Silver, 250 points or more

Native VLANs are used to carry CDP, PAgP & VTP messages. Thus the Frames on native VLAN are untagged. For these messages to propagate between devices, native VLANS must match on both sides of the trunk. In case of native VLAN mismatch on bothsides of the trunk, STP will put the trunk port in err-disabled state.


Refer this link for better understanding:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39009


hope that clarifies.


Pls rate all helpful posts.

Jon Marshall Mon, 12/10/2007 - 23:39
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


I thought that Cisco protocols such as VTP/CDP/PagP were always sent on vlan 1 regardless of whether that was the native vlan or not. So you can change the native vlan to any vlan you want but the above protocols will still be sent over vlan 1 as tagged frames.


Jon

mohammedmahmoud Tue, 12/11/2007 - 00:15
User Badges:
  • Green, 3000 points or more

Hi,


Totally agree with Jon, and more over, even if VLAN 1 was removed from the allowed list on a certain trunk, only the user traffic will be filtered, while all the layer 2 control protocol traffic is still allowed (VTP, CDP, STP BPDUs, and PAgP).


HTH,

Mohammed Mahmoud.

Kevin Dorrell Tue, 12/11/2007 - 00:37
User Badges:
  • Green, 3000 points or more

Mohammed,


I am not so sure about that. Perhaps Francois could clarify this point.


I do remember an incident that seems to suggest that the control protocols are sent untagged, whatever the native VLAN. This was on CatOS. I had a trunk with a non-1 native VLAN, and I trimmed the native VLAN off the trunk. The effect was that the trunk did not pass any VLAN 1 BPDUs any more, and presumably no other control protocols. (Unfortunately, believing the control traffic was passing tagged on VLAN 1, I trimmed the native on both uplinks, resulting in a network meltdown.)


The Cisco bug database acknowledges this as an issue on IOS devices, and the problem has been fixed. You can now trim the native off a trunk without affecting the control protocols. However, the problem was never fixed on CatOS.


Kevin Dorrell

Luxembourg


Jon Marshall Tue, 12/11/2007 - 00:41
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi Kevin


How are the routers and more importantly hope the family are still happy !!


My understanding is that all Cisco proprietary protocols CDP/VTP/PagP will always go over vlan 1. If vlan 1 is the natiev vlan they will be untagged. If vlan 1 is not the native vlan they will be tagged.


STP is not Cisco proprietary so i believe that BPDU's are always sent untagged across the native vlan.


But as you say perhaps Francois can clear this up for us all.


Jon

bvsnarayana03 Tue, 12/11/2007 - 00:44
User Badges:
  • Silver, 250 points or more

Jon, Mahmood


Thanks for correction on native vla.


but theres a doubt regarding the other point i.e. L2 protocols still flowing on the trunk even if removed from allowed list.


I read somewhere in the forum only, that when a specific vlan is removed from the tunk then all traffic including L2 for that vlan will not pass through trunk. Is my understanding correct. If yes, than the traffic you mentioned shouldn't flow on trunk for the vlan not allowed.


Secondly, how does VTP pruning differ from the above case.

Jon Marshall Tue, 12/11/2007 - 00:47
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

If you remove a vlan from the allowed list on the trunk then no traffic for that vlan will flow down the trunk link except the control packets that are sent on vlan 1 ie. CDP/STP/PagP. Vlan 1 will always be allowed on the trunk.


The major difference between pruning and removing a vlan from the trunk is if you prune STP still runs across the link for that vlan whereas removing it stops STP running across the trunk link for that vlan.


Jon

mohammedmahmoud Tue, 12/11/2007 - 01:05
User Badges:
  • Green, 3000 points or more

Hi,


Jon, sorry for including STP, i just wanted to say that it is not sent untagged, the default STP on Cisco switches is PVST+, which is Cisco proprietary, in order to support both ISL and IEEE 802.1Q it can't use untagged frames, please do check this document:


http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic1


BR,

Mohammed Mahmoud.

Jon Marshall Tue, 12/11/2007 - 01:53
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Mohammed


No need to apologize, otherwise i'll be forever saying sorry when you correct me :)


Separate issue. Notice you are a regular poster in MPLS forum (please ignore my massive total of 1 in that group so far !! ).


Wondering if you had looked into SP CCIE at all. I appreciate you are a bit shell shocked after your R&S but any insights would be much appreciated.


What i'm trying to decide on is do i want to do the R&S or try the SP instead and if i did try the SP do i need to know pretty much everything in the R&S anyway.


** Edit - should point out reasoning behind my decision. There is a strong chance i might get a chance to get into some MPLS design and from what i've looked at so far it's a very interesting subject. **


Jon

mohammedmahmoud Tue, 12/11/2007 - 03:32
User Badges:
  • Green, 3000 points or more

Hi Jon,


I really enjoy interaction with you :), you correcting me, or me correcting you is not the issue as long as both of us are clear at the end, i respect and admire you as a peer and as a friend :)


Ok, back to CCIE, SP nearly covers most of the R&S topics and more other topics (the only topic that is not covered in the same depth is switching).


I'll start preparing for SP during the coming period by the way, my philosophy is that i am still in the start of my Career (i am 27 years old, with 5 years work experience), accordingly i though starting with R&S was a good start (before it, i've already had my CCNP and CCIP), after wards i should tackle my main target which was SP CCIE, which is IMHO more difficult and interesting than R&S.


I am working for a provider for more than 3 years now, and yes MPLS is a very very interesting domain, but you must consider all the aspects of your life and career, and separate between your short term and long term plans , as the CCIE is a long wild road, so you should have done all your calculations correct before putting your foot on the start line.


If you would like to contact me, we can talk in details, you know my email:[email protected], and my gtalk is [email protected].


BR,

Mohammed Mahmoud.

Kevin Dorrell Tue, 12/11/2007 - 01:05
User Badges:
  • Green, 3000 points or more

Jon,


That's just the point. I trimmed VLAN 12, which was the native, and which was deliberately unused anywhere else in the network. The VLAN 1 production traffic was still being passed (tagged), but the control traffic stopped, including the BPDUs. That's why the network went into meltdown.


Kevin Dorrell

Luxembourg



Jon Marshall Tue, 12/11/2007 - 01:18
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Kevin


Where is Francois when you need him.


Still not sure i fully understand. If you had a native vlan which you trimmed from the trunk that would definitely stop STP for that vlan running down the trunk. The BPDU's would be sent untagged down the trunk link until you cleared it.


However CDP/VTP/PagP should still have been sent on vlan 1 as tagged frames - are you saying that you stopped sending these packets as well.


Apologies for being a bit slow this morning..


Jon

Kevin Dorrell Tue, 12/11/2007 - 01:41
User Badges:
  • Green, 3000 points or more

That's right.


As far as I reasoned, if I trim VLAN 12 from the trunk, then it should trim both the STP and the production traffic for VLAN 12, so it should be safe. So long as it trims the production traffic in the same way that it trims the STP, then it should be safe.


It should not have affected any other VLAN, nor indeed any control protocol. Instead, it seems that it trimmed the STP for VLAN 1 but not its production traffic. Note that it was VLAN 12, the native, that I trimmed.


As for CDP, VTP, DTP, PagP, I didn't stop to find out, as you can imagine! I am just assuming that they were trimmed along with the VLAN 1 STP.


Kevin Dorrell

Luxembourg


Jon Marshall Tue, 12/11/2007 - 01:46
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Ahh, okay makes more sense now.


And yes, i can imagine you were a little bit rushed to being doing a "sh cdp neigh" :)


Jon

mohammedmahmoud Tue, 12/11/2007 - 02:11
User Badges:
  • Green, 3000 points or more

Jon,


I can see your point here :) Just to consolidate all the facts here, only the Native VLAN STP BPDUs are sent untagged.


BR,

Mohammed Mahmoud.


Francois Tallet Tue, 12/11/2007 - 18:29
User Badges:
  • Gold, 750 points or more

Hi Kevin,


You mean that you are using the European Commission production network as a test bed? Kidding;-)

I've quickly read through this long thread. I would need to search for exact answer because some of the behavior will be platform dependent unfortunately.


In the good old days of the cat5k (and ISL), vlan 1 was supposed to be the administrative vlan, and could not even be disabled on a trunk. That was the perfect choice to run inter-switch protocols and you can expect all the "old" Cisco protocols you mentioned to use this vlan. Note that by "inter-switch" protocols, I mean the protocols that are run between physical devices and that are not instantiated on a per-vlan basis (PVST is clearly not one of them).


At the time of ISL, there was no vlan in the IEEE standards. The IEEE "inter-switch" communication was just sent untagged on the wire. And in fact, when vlans were introduced in 802.1Q, it remained the same. Afaik, the IEEE control protocols are not instantiated per vlans, they are always running between switches, thus use untagged frames (it could change I guess). All this to say that you can expect IEEE protocols to exchange untagged PDUs (LACP, LLDP, STP etc...). Note that this is not a "native vlan", it is just untagged PDUs. There is no concept of vlan at this level (vlan is a higher layer).


Now, as to what happen when vlan 1 or the native vlan is disabled. That's where I'm not 100% sure, because it might have been implemented differently on different platforms.

On the high end platforms at least (like the cat6k), the "native" vlan and vlan 1 are always programmed on a port, in an STP blocked state. It means that the asic is still able to receive and forward control traffic to the CPU but that data traffic will be blocked for the vlan. As a result, no problem.


However, on some platforms, that might not be possible. For example, some cat29XX switches support a limited number of vlans. The hardware is just not provisioned to be able to handle 4K vlans (for cost reasons). It means that their asic is mapping the vlan tag (between 1 and 4094) to an internal value (say between 1-1000). If we needed to be able to receive traffic on the native vlan even if this vlan is disabled, we would need to still allocate asic resources to this vlan. Potentially, the user could define a different native vlan on each of the ports, reducing by that many the number of effective vlans available to user, which is not acceptable. So in that case, I think we are not able to receive control traffic on the disabled vlan. And that could be indeed an issue: if you are running MST, not receiving BPDUs is a big deal;-) I think however (not 100% sure) that vlan 1 is still programmed in the asic, even if it is disabled. There is only one vlan 1 on the whole box, so we can afford the cost of maintaining it, even if it's not present in the trunk config. So probably Cisco protocols are still fine in that case.


About PVST. This is a weird beast. Until MST, IEEE bridges were only running a single instance of STP. Cisco boxes are peering with this STP instance using vlan 1. And because IEEE bridges always send untagged BPDUs, vlan 1 BPDUs are always send untagged. So in fact, if you prevent transmission the native vlan, it's vlan 1 that is affected (on the top of the native vlan's instance). Kevin, were you using PVST or MST for your test? Note that there might have been some associated bugs in the area that I don't remember but that should have been fixed by now.


Regards,

Francois


Kevin Dorrell Wed, 12/12/2007 - 00:32
User Badges:
  • Green, 3000 points or more

Hi Francois,


Not if I can avoid it ;-)


Thanks for the detail posting and all that information.


The great thing about this incident, of course, is that it doesn't go into meltdown immediately. It waits 30 seconds until you back is turned, and then goes into meltdown. The protocol at the time was PVST, but not rapid.


I did open a TAC case about it (case 602215701), and they came up with CSCed00396 and later CSCdv19761. It seems that development had already found the way for the VLAN 1 BPDUs to be processed even if the (non-1) native VLAN had been cleared off the trunk, but only for IOS (on 4500 S2+ in my case). It was never fixed in CatOS 4003 S1, which is where I found it.


Reading your posting carefully, you say that the IEEE protocols (LACP, 802.1D, etc) are sent untagged, even if VLAN 1 is not the native. Does this apply to the Cisco protocols such as CDP, PAgP, DTP? (Is CDP instantiated per VLAN? I don't think it is, is it?) I understand you correctly most of these control protocols are sent untagged, even if the native is not 1.


I take your point about maintaining a VLAN instance for each VLAN that is a native on a trunk. But if you are not allowed to clear the native VLAN from the trunk (to avoid blocking VLAN 1 PBDUs), you will have an STP instance for the native VLAN anyway. The moral seems to be to keep the same native on all the trunks, and not to clear it off any of them.


So, to "best practice" concerning VLAN 1. It seems to be the received wisdom that you should reserve VLAN 1 for management and trunk natives only, and put any unused ports on a gash VLAN (or even one that if not defined). However, human nature being what it is, switches are likely to be introduced with their ports still on VLAN. That could be dangerous - any new patches would accidentally have an express way into the management VLAN. Furthermore, it is still vulnerable to double-tagging from those ports.


For that reason, I prefer to use a seperate non-1 VLAN for management, and yet another unused VLAN for the trunk natives. The only hosts on the management VLAN are the management interfaces of the switches, and the NMS access ports. But I am beginning to think maybe I should use the same non-1 VLAN for the trunk-native as for the management. I would also put switchport access vlan n on the trunk ports, so that it they did fall out of trunking for some reason, the management VLAN would still be accessible.


Thanks once again for the detailed discussion. It is great to have authoritative postings on the forum.


Kevin Dorrell

Luxembourg


Francois Tallet Wed, 12/12/2007 - 11:22
User Badges:
  • Gold, 750 points or more

Thanks Kevin.


In fact, you're intimidating me, I don't want to pretend giving authoritative answers;-)

Yes, I expect (I've not checked) the old Cisco protocols to send their PDUs on vlan 1, which mean that they are tagged if vlan 1 is not native. IEEE protocols send their PDUs untagged, and don't care which vlan is native. By the way, 80.21Q allows several vlans be sent untagged so it would not mean anything sending a PDU on "the native vlan".

Because vlan 1 has lost its particular status, I would expect that new Cisco protocol would also send their PDU untagged. That's the case with REP, that was developed recently for instance.


On (most) port asic, you have a bitmap that represent the list of allowed vlans. The asic parses the frame and identifies the vlan. If the vlan is not there, the frame is immediately discarded, even if it's a control frame. Then you have a second bitmap, that represent the STP state for the port. The asic is able to parse the frame further and identify control frames. If the port is STP blocked, only control frames are forwarded to the CPU. Data frames are discarded.

Usually, when you disable a vlan from a trunk, the first bitmap is updated so that all the frames received on this vlan are discarded (it's safer). On cat6k at least, we don't do this for vlan 1 or the native vlan. Instead, we program the second bitmap to block data traffic, and we are able to receive PDUs sent on them. But that's only a slight difference in the way the hardware is programmed. The software still consider that those vlans are disabled and there will be not STP computed for vlan 1 on a port if vlan 1 is disabled.


The bugs you have filed were probably because of a failure to implement the mechanism described above correctly on some platforms.

PVST is generally safe because if you filter BPDUs for a vlan, you also filter the data traffic. However, vlan 1 is an exception because it is sending its BPDUs on this so-called native vlan. So suppose that on a port the native vlan X is disabled. If you have vlan 1 on this trunk then without the mechanism described earlier, the traffic for vlan 1 can go through, while the control protocol for vlan 1 is lost -> that leads to a loop in vlan 1 only. For MST, the control protocol for all the vlans is sent untagged. So if you filtered the control protocol for vlan X on this port, all the vlans could be affected could enter a bridging loop.

I'm going to stop there, because I'm not sure you are interested in this level of details;-)

I think your approach for the management of vlan 1 and native vlan is sensible (and you certainly have more experience than I do in this regard). It's just that I'm not sure that every current platform is able to perform the HW trick I mentioned. That's not an issue for PVST because even in that case, there could only be a loop in vlan 1 and you are not using vlan 1. But that could definitely be one if you were using MST.

High end or recent platforms you should not have any issue... and if there is one, you're likely to "experience it" in a matter of seconds:-(


Thanks again,

Francois

Actions

This Discussion