VLAN Design Strategies – One-VLAN-per-Switch

Disclaimer

This post only discusses end-user switch VLAN’s, not core infrastructure VLAN’s, and not management VLAN’s.  We have special VLAN’s assigned based on jack physical-location/data-sensitivity security assessments, but those are also outside the scope of this post.   I am also not recommending the one-VLAN-per-switch design  as a best practice for Cisco switches, just sharing with you what works in our environment.  I am interested in comments from other network professionals.

Why would anyone want to go to the trouble of one VLAN-per-switch?

We have found it very beneficial when receiving  alerts from IPS’s , security log event monitors, other security software, centralized anti-virus/malware monitors, and when analyzing the centralized logs.  Just by looking at the IP address we can tell immediately where an issue is coming from and respond to it quickly.  When correlating events, it also helps us visualize patterns of activity.  

 

Avoid 802.1q Native VLAN’s with VMware

“VMware recommends you not associate any ESX Server virtual switch port group VLAN IDs with the native VLAN. Also, as long as you avoid using native VLAN for your VLAN port groups, there is no native VLAN related configuration necessary on the ESX Server systems.”

The easiest way to comply is to not assign any native VLAN the external switch port.  In switching it is often a common practice to assign a desired data port VLAN as the native VLAN.  But with VMware let the external switch go ahead and tag your VLAN(s) and then your vSwitches will be happy and behave as intended.

VMware ESX Server 3 802.1Q VLAN Solutions (originally written for ESX 3, but applies to ESX 4)
The Great vSwitch Debate - A great series of articles on vSwitches