The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

VLANs are locally significant

By stretch | Friday, April 11, 2008 at 6:46 p.m. UTC

One common misconception regarding VLANs is that they are significant beyond a single switch. Of course, VLAN numbers have to match for trunking to work, and VTP can be used to automatically propagate VLAN information. However, a VLAN, being essentially little more than a number, is significant only within a device. Consider the following scenario:

access_vlans.jpg

All of the ports on switch A are set to access mode in VLAN 10, and all of the ports on switch B are set to access mode in VLAN 20. Note that the connection between the two switches is not a trunk; each end is configured as an access port in the respective VLAN. Our two hosts A and B are similarly connected to different VLANs, but still reside in the same IP subnet. Can hosts A and B communicate?

The answer is yes. Follow the path of a frame leaving host A destined for host B. Switch A receives this frame on a port in VLAN 10, so it can only egress out another port in VLAN 10 or a trunk port. It performs the usual MAC lookup to determine the appropriate outbound port is its link to switch B. Now, here's the key: the frame is forwarded to switch B without a VLAN tag, because this is an access port. Switch B receives the frame on an interface it considers VLAN 20 and performs the same switching decision to forward the frame to host B.

So, does it work? Yep! Is it a good idea? Probably not. In an instance where VLANs are used, you're probably using more than one. For this reason and others, it's recommended to always trunk between switches using IEEE 802.1q or (less favorably) Cisco ISL.

Posted in Switching

Comments


drkfiber
April 12, 2008 at 11:16 a.m. UTC

Great, simple explanation. I think the site is great, keep posting. I also was in the AF, AFSC 2A452. I would imagine the pay jump from enlisted to contractor was very nice... :)


cisco
June 24, 2009 at 9:29 a.m. UTC

Great tutorial. One of the best sites. Keep it up


lec4 davis
July 25, 2009 at 8:49 a.m. UTC

ur website is very usefull t ome b coz it helps alot to my studies


Arthur Lashin
August 8, 2009 at 2:25 p.m. UTC

This kind of design is very dangerous when one uses PVSTP because PVSTP BPDUs carry VLAN number they belong to inside themselves and VLAN number mismatch on access interfaces leads to error disable state of those interfaces.


tamizh
June 20, 2010 at 6:28 a.m. UTC

Well this seems innocuous but this caused a big problem at my work. Due to some undocumented change, one of the trunk link between two switches were changed to access port, each switch port being assigned to a different Vlan.

When end hosts in Vlan A booted up, the DHCP packets traveled up the mis-configured access port and reached DHCP server in Vlan B. As a result, quite a few hosts (supposed to be) in Vlan A got kicked out from the LAN and got assigned a Vlan B IP address. Luckily it was just a couple of printers and a PC, but it had the potential to be a bigger issue.


Malik
September 8, 2013 at 8:40 a.m. UTC

Good Tutorial!!!

Please,let me know what will happen if the Host's in VLAN 10 and 20 are in different IP subnets for example Host A in Network 192.168.10.0/24 and Host B in Network 192.168.20.0/24.

Will the Ping between host A and host B work then? say host A IP address is 192.168.10.1 and host B IP address is 192.168.20.1.

Thanks & Regards
Malik


Pramz032
October 30, 2014 at 8:00 p.m. UTC

Hi Jeremy, Pls explain on importance of Native Vlan and what happens in-case of native vlan mis-match.


Baranan
September 15, 2015 at 12:03 p.m. UTC

Hi What happens if a second link is connected between the two switches with exactly the same vlan configuration ( access vlan 10 - access vlan 20) Will spanning tree works to block one link? Which link will be selected to pass traffic

Thanks


Ye Min Oo
January 22, 2016 at 2:35 p.m. UTC

Interesting post!

Comments have closed for this article due to its age.