BladeSystem Virtual Connect
Showing results for 
Search instead for 
Did you mean: 

Tradeoff between Map VLAN Tag and Tunnel VLAN Tag

Trusted Contributor

Tradeoff between Map VLAN Tag and Tunnel VLAN Tag

Always an interesting discussion when System Admins are looking to use Virtual Connect and have the option of using Tunneled Mode or Mapped VLAN mode. Our Blades Engineers discussed the PROs and CONs of the implementation types and I wanted to share their thoughts with you.


Prasenjit asked:




Can anyone make me understand in VC FlexFabric Network design what would be the tradeoff factors in between Map Mode VLAN and Tunnel Mode VLAN. Also what would be the implications in each of the scenarios, keeping VMware in mind.


Any help would be great.




From Jim:




Mapped vs. Tunneled

The difference is that with Mapped VLAN mode the Virtual Connect module handles the VLan mapping and will place packets on the correct VC network based on the VLAN ID. In Tunnel mode, VC does not look at the VLAN tag within a packet and just passes the packet to the destination MAC address. It is then up to the destination device to untag the packet and move it to where needed.


One advantage of Mapped Mode is that by burdening the ultra-fast FlexFabric Module to separate out the VLAN packets, you eliminate what could be significant operating system interrupt service routine overhead, depending on the OS and driver. In Tunneling mode, as Gary mentions, each OS in the enclosure will by definition have to parse out 1Q trunked traffic. In Mapped Mode, you have a choice --- even when you trunk VLANs through your SUS, you can present non-tagged traffic to any or all FlexNICs, depending on how many ports and VLANs you're working with.

If your environment isn't ultra-high security and enjoys 10G uplinks, enough FlexNIC ports allow Mapped Mode to keep even a hypervisor environment free of VLAN tagging. This "keeps it simple" in the VMware side, pushing all of the VLAN configuration between the FlexModules and your upstream switches


With the release of VC v3.30:


  • Simultaneous tunneled and mapped networks in a single domain
  • One type per server connection

      –      One per physical port or one per FlexNIC

  • 162 VLANs per physical connection
  • 1000 networks per SUS



From Chris:




As Jim pointed out, Tunnel Mode is 802.1Q-in-Q operation at the VC level.  Meaning, as a frame ingresses into VC, the VID field (even if it does not contain a VLAN ID) is moved into the payload of the frame, increasing the size of the frame by 4 Bytes), until it arrives at the destination port, and is reinserted back into the VID field (reducing the size of the frame.)


Just as Jim pointed out that there can be performance issues, there can be issues with Multicast and Unicast where a physical external device may participate on two or more VLANs (i.e. Load Balancer.)


I always try to steer customers away from this capability.  With VC v3.30, you can mix and match these different configs, so you don’t have to make a VC Domain wide decision.  If your customer or design can fit within the VC limitations VC v3.30 improves upon, then stick with Mapped Mode.




Your comments or experiences?