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
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;-)
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:
hope that clarifies.
Pls rate all helpful posts.
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.
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).
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.
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.
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.
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, 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:
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. **
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.
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.
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..
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.