Native VLAN

The native VLAN has two main functions:

1. Tags incoming un-tagged traffic on trunk links with the native VLAN.
2. Un-tags outgoing traffic that has already been tagged with same VLAN that is being used for the native VLAN on the trunk.

Let me elaborate on this a little bit with aid of the diagram shown below.

A normal design would use the same native VLAN both sides of the trunk.  But to understand the native VLAN properly, I’ve designed it this way instead.  So going back to the bullet points above (specifically bullet point 2), when the switchport connecting to Host A has been configured to use the same access VLAN (vlan 50) that is being used as the native VLAN on the trunk, the data sent from Host A is un-tagged as it leaves Switch 1 towards switch 2.  This leads us up to bullet point 1 (above), where switch2 now receives an un-tagged frame (i.e. a frame without a VLAN tag on it). Switch2 will always tag this, currently tag-less frame with the configured native VLAN on the trunk, in this case VLAN 60. So this actually leaks VLAN 50 into VLAN 60’s broadcast domain.

I’ll now configure this to demonstrate that it actually works. Below is the current configuration (notice I’ve not configured the native VLAN yet).

s1#
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/20
 switchport access vlan 50

s2#
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/20
 switchport access vlan 60

Now to configure the native vlan.

s2(config)#int fa0/23
s2(config-if)#switchport trunk native vlan 60
####### now i quickly switched over to switch1 ########

s1(config)#int fa0/23
s1(config-if)#switchport trunk native vlan 50
s1(config-if)#
*Mar  1 00:53:14.851: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 60 on FastEthernet0/23 VLAN50.
*Mar  1 00:53:14.851: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet0/23 on VLAN0050. Inconsistent local vlan.
s1(config)#
*Mar  1 00:53:44.119: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on FastEthernet0/23 (50), with s2 FastEthernet0/23 (60).
s1(config-if)#end

So what’s happened here is spanning-tree is not happy about the native VLAN mis-match we’ve just configured and ended up putting the port into the inconsistent state, as shown below.

s1#sh span int fa0/23

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg FWD 19        128.25   P2p 
VLAN0050            Desg BKN*19        128.25   P2p *PVID_Inc

What this means is that the port is in blocking state which, in spanning-tree, means BPDU’s can be sent/received but mac addresses cannot be learned (i.e. the data-plane will not work). So by default a native VLAN mis-match causes spanning-tree to block the port. So if we disable spanning-tree for vlan 50 and 60, we should find that the port will become useable in the data plane and allow host A (192.168.1.1) to ping host B (192.168.4.1) even though they are on different subnets/broadcast domains and don’t have a gateway configured.

S1(config)#no spanning-tree vlan 50
S2(config)#no spanning-tree vlan 60

Now to send some pings from host A to Host B.

HostA#ping 192.168.4.1               

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
!!!!!

So now, the data plane is working, and we are learning mac-addresses on VLAN50.  Notice that Host B appears as being in VLAN50 on Switch 1, even though on switch 2 I put it in access vlan 60.  This is because Switch1 tagged the un-tagged frame as it arrived on the trunk port with the native VLAN (vlan 50).

s1#sh mac address-table int fa0/23
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
   1    0023.0443.0c99    DYNAMIC     Fa0/23
  50    0016.4661.a4c1    DYNAMIC     Fa0/23 (this is Host B)
  50    0023.0443.0c99    DYNAMIC     Fa0/23 (This is Switch 2)

Other Discussion 

allow host A (192.168.1.1) to ping host B (192.168.4.1) even though 
they are on different subnets/broadcast domains and don’t have a gateway
 configured.”
How it’s possible ? For me 2 hosts in 2 subnet can’t speak without router  

You are right in the fact that when you send a ping to another subnet, the device ARPs for its gateway, and the gateway does the rest. If this wasn’t the case, then you’d have an ARP entry for every device on the internet :). However!!!! If you do not configure a default gateway on the host machine, and you send a ping to an IP in a different subnet, an ARP is still sent to the destination MAC of FFFF.FFFF.FFFF, but you are ARPing for the original destination IP (as opposed to the gateway). Now, since layer 2 broadcast domains are controlled by VLANs, this ARP is allowed to go from Host A in VLAN 50 and over the trunk. Now because the Native VLAN is also 50 on Sw1, the packet loses its VLAN tag, and it gets tagged with VLAN 60 as it arrives on Switch2 (Sw2’s native VLAN), and therefore allows the ARP to flood the VLAN 60 domain, which encompasses Host B.
As an update to this, I tested this using two methods. I tried using a switch with #no ip routing configured for both Host A and Host B, and it worked. However, on a Windows machine, you just get a “PING: transmit failed. General failure” message. So it looks like Windows has prevented you sending ARPs like this if you don’t have your gateway configured. I bet in Linux it would let you do this though I haven’t tested on my Raspberry Pi.

So you mean to say if we configure the gateway on windows pc it should work to communicate between itself and another pc in different vlan. But to my understanding the gateway is the ip address of the router or any layer 3 device in which case it should work. But as far a layer 2 is concerned there is no concept of gateway configuration and the communication between two devices on two different vlans configured on separate switches will not work. Disabling Spanning Tree Protocol means you are broadcasting the two domains (or vlans) in which case the communication should work regardless of the vlan tags.

Page Courtesy : http://ccieblog.co.uk/spanning-tree/native-vlan