Native Vs Default VLAN:
===================
This is an often-confused
point for people new to the Networking, in particular to people coming up the
Cisco track, due to Cisco's over emphasis on this point. It is more or less
just a terminology thing.
Explanation:
The 802.1q
standard defines a method of tagging traffic
between two switches to distinguish which traffic belongs to which VLANs.
In Cisco terms, this is what happens on a "trunk" port. I've seen other vendors refer to this as
a "tagged" port [Eg. Brocade ICX Series]
In this context, it means the same: adding an identifier to frames to indicate what VLAN
the frame belongs to. Terminology aside, the main think to keep in mind is a
VLAN tag is necessary, because often the traffic traversing two switches
belongs to multiple VLANs, and there must be a way to determine which 1's and
0's belong to which VLAN.
But what
happens if a trunk port, who is expecting to receive traffic that includes the
VLAN tag, receives traffic with no tag?
In the
predecessor to 802.1q, known as ISL (cisco proprietary, but archaic, no one
supports it anymore, not even Cisco), untagged
traffic on a trunk would simply be dropped. ISL has no concept of a native
VLAN.
802.1q however, provided for a way to not only receive this
traffic, but also associate it to a VLAN of your choosing. This method is known
as setting a Native VLAN.
Effectively, you configure your trunk port with a Native
VLAN, and whatever traffic arrives on that port without an existing VLAN tag,
gets associated to your Native VLAN.
As with all configuration items, if you do not explicitly
configure something, usually some sort of default behavior exists. In the case
of Cisco (and most vendors), the Default Native VLAN is VLAN 1. Which is to say, if you
do not set a Native VLAN explicitly, any untagged traffic
received on a trunk port is automatically placed in VLAN 1.
The trunk port is the "opposite" (sort of) from
what is known as an Access Port. An
access port sends and expects to receive traffic with no VLAN tag. The way this
can work, is that an access port also only ever sends and expects to receive
traffic belonging to one VLAN.
The access port is statically configured for a particular
VLAN, and any traffic received on that port is internally associated on the
Switch itself as belonging to a particular VLAN (despite not tagging traffic
for that VLAN when it leaves the switch port).
Now, to add to the confusing mix. Cisco books will often
refer to the "default VLAN". The Default VLAN is simply the VLAN which all
Access Ports are assigned to until they are explicitly placed in another VLAN. In the case of Cisco switches (and most other Vendors), the
Default VLAN is usually VLAN 1. Typically, this VLAN is only relevant on an
Access port, which is a port that sends and expects to receive traffic without
a VLAN tag (also referred to an 'untagged port' by other vendors).
So, to summarize:
- The Native
VLAN can change. You can set it to anything you like.
- The Access
Port VLAN can change. You can set it to anything you like.
- The Default
Native VLAN is always 1, this cannot be change, because its set
that way by Cisco
- The Default
VLAN is always 1, this cannot be changed, because it is set that
way by Cisco.
Some More Info. On this Topic:
=======================
- We
speak about the native VLAN in terms of data frames and not management
frames such as CDP, STP, VTP
- The
ONLY difference between a regular VLAN and the native VLAN is that frames
from/to the native VLAN are carried untagged; this is it.
- The
IEEE 802.1q TRUNKING encapsulation standard says the NATIVE VLAN represents
traffic sent and received on an interface running 802.1q encapsulation
that does not have a tag. So although the NATIVE VLAN exists also on
access ports, its role is relevant only on trunk ports.
- NATIVE
VLAN can be modified on a per-port basis or it can be
"disabled", meaning you can configure some higher-end
switches to tag all frames, so there is not NATIVE VLAN.
- Native
vlan should be same on both the ends.
For a More Detailed understanding of Native
Vlan,802.1q, Tagged, Untagged ports refer to the below link.
Question:
Let’s say there was a 802.1Q Trunk between
two Switches and the native VLAN command (switch port trunk native vlan x) was used on both ends as required. What affect does
that have on VLAN 1...? Does this mean that VLAN X and
VLAN 1 are both carrying less (untagged) overhead across the
Trunk link...? Furthermore, all defined VLANs will still continue to propagate
across the Trunk thanks to VLAN 1.
Answer:
When a switch port is configured with the
default native vlan, you will really not see a native vlan configured in the
configuration on that port. This is the equivalent of "switchport trunk
native vlan 1".
In this case any traffic on vlan 1 that is
leaving the switch is untagged. Any untagged traffic coming into the switch is
assumed to be on vlan 1.
If we changed it to say vlan 10, then any
traffic on vlan 10 that was leaving a switch would be untagged. Any traffic
arriving untagged would be assumed to be on vlan 10. Additionally, in this
case, traffic leaving the switch that was on vlan 1 would be tagged just as any
other traffic except the traffic that was from vlan 10. As stated, any traffic
arriving untagged would be assumed to be part of vlan 10, and therefore cannot
be part of vlan 1.
There is only one native vlan per trunk. This
must match on both ends of the trunk and is responsible for all of the untagged
traffic. The native vlan could also be called the untagged vlan.
Nice Explanation on Native Vlan with quick Vedio:
======================================
Nice Explanation on Native Vlan with quick Vedio:
======================================
No comments:
Post a Comment
Note: only a member of this blog may post a comment.