A native vlan is the untagged vlan on an 802.1q trunked switchport. The native vlan and management vlan could be the same, but it is better security practice that they aren't. Basically if a switch receives untagged frames on a trunkport, they are assumed to be part of the vlan that are designated on the switchport as the native vlan. Frames egressing a switchport on the native vlan are not tagged. This is the definition however more recent switch software often will allow you to tag all of the frames, even those in the native vlan. This gives some added security and allows the CoS bits to be carried between switches even on the native vlan. Let me know if you need further clarification.
So by untagged it means that the frame has not had the extra information(tag) added to it that allows it to be "trunked" to the other switches? Couldn't there be more than one native lan? i.e if a switch, SW1, had vlan 10, vlan 20 and vlan 30 on it. Wouldnt all those vlans be native to SW1, but not necessarily native to the domain?
In your example, all those vlans would all be native to the switch, but not native from the trunk port perspective. Native has to do with the trunk itself, not the switch. If we carry your definition to the trunk, you will see that if we don't tag vlan 10, 20 and 30, the connecting switches will be very confused. That is the reason we can only configure one native vlan per port. However, a switch with multiple ports, could have different vlans specified as the native vlan for that port. In other words, trunkport 2 could have a native vlan of 20, and trunkport 3 could have a native vlan of 30 (if you choose to be really complicated in your design). The switches on either end of the trunk just need to agree so strange things don't happen.
I am looking at a network with different native vlans across multiple switches. While I understand that native command on the trunk nominates the traffic that passes untagged, I not certain that chopping and changing the Native from one of the network to the other is wise.
to get from the server in question on vlan 20 I need to get a packet across three switch stacks (2 trunks).
|Server|----->|AP VLAN 20 TP with native 20| <------>|TP native 20 TP native 40|<---->|TP native 40 AP VLAN20| ---->|PC|
So I am trying to get a packet on Vlan 20 Access Port to a PC on a Vlan 20 Access Port across two trunks with different native Vlans.
It seems that because the trunks are configured in the correct pairs that traffic still pass to the correct vlans throughout the path.
I was concerned that the native vlan was to be nominated per switch or even for your whole campus when designing the LAN....
My point is that you can mix up the native vlans but wanted to know what other people have experienced. This seems like an odd way of doing things to me.
I came across it troubleshooting ARP problems with a server....the MAC in the cam drops out of the switch where the PC is. I can ping all other servers on VLAN 20 but not once in particular and clearing the arp cache restores connectivity for about 3mins.
Your example should work. However, I agree. You can even go a step further and have mismatched native vlans on each end of a trunk. In that case, the native vlan on one side becomes part of the same broadcast domain as the native vlan of the other end. It is never a good idea to design a network this way. Maybe if there was some really weird requirement on a CCIE R&S lab or something. In practice, it is way too confusing.
In my labs, what I like to do is make a vlan for unused ports, make a vlan for inband management (telnet, ssh) with SVI on each device (subnet managment network for different routers so can keep 1 network and dynamic routing protocols can advertise all (use ACL and access class) , and make new native vlan with no SVI. Also I shut int vlan 1. I know vlan 1 is still used no mattter what for certian protocols, but new native will be the one native on trunks.
I know outband access server is best for management but this simulator labs
Would you guys mind if I pose a question here?
Scenario: "Switch A is connected to Switch B using a trunk. SA tags its native VLAN while SB doesn't, but use the same native VLAN". Would a native VLAN mismatch occur? I mean, when you tag traffic for native VLAN, how do you tell if it's for the native VLAN or some other VLAN?
In your scenario, I think frames on the native vlan would flow properly from SA to SB, but not from SB to SA. While SB does not expect its traffic destined for its native vlan to be tagged, it will not reject it. Since SA is configured to expect traffic received for its native vlan to be tagged, it will discard the untagged traffic on a trunk. This is not technically a native vlan mismatch, but traffic will only flow in one direction.
Yes, the definition of a native vlan in 802.1q is an untagged vlan. There are some exploits that can take advantage of this by stacking two sets of tags. If a user builds a frame that has an outer dot1q tag for a known native vlan and an inner tag of a vlan he wishes to attack, the first tag will be removed when the frame traverses a the first trunk. The next trunk that is encountered will put the frame on the vlan that is the attack destination. As a result, there is a new command introduced to tag all frames on a trunk. This global command is "vlan tag dot1q native".
((If a user wants to build an outer tag for anative vlan))!!! Why would it be for a native vlan anyway?
If the user builds an outer vlan tag traversing a trunk, the lookup (in terms of Switching) is always going to be for the outer vlan if the intermidiate switch allows this vlan to be tunneled However. The frame already contains an inner vlan that matches the destination victim... Why then a user needs a native vlan for that? If my out vlan tag is tunneled and the inner vlan is my destination , why would I need a native vlan for this to happen any way?
I hope i have pointed out my point here,
If a user builds a frame with another VLAN, it might be restricted on the trunk he or she has attempted, or even one hop upstream. Double tagging with the native vlan as an outer tag can throw the switch a tag to discard. In certain cases, that exposes the inner tag and allows the attacker onto the victim vlan. Take a look at the double tagging example at the following url--
Could you please clear my confusion on Management Vlan ?
Accourding to you "Native vlan and management vlan could be the same". As I know, what ever the untagged traffic is received at 802.1q it will be forwarded to Native vlan wheather it is a default vlan 1 or other Native vlan and control traffic will also forwarded through native vlan where as management vlan is only to access the devices. So, how far these both are same ? if management vlan also receive untagged traffic than how switch will decide wheather the untagged traffic should forwarded to Native vlan or management vlan.
Please correct me !