Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Mapping VLAN Tags to Virtual Private Cloud Subnets
In a typical virtualization environment, a virtual machine (VM) sends untagged traffic out of its virtual network interface card (vNIC). By default, the virtual switch drops any traffic that has an 802.1Q VLAN tag. To allow this type of traffic, a feature called Guest VLAN Tagging (GVT) must be explicitly enabled on the vNIC port connection. Before we dive into the simple yet powerful approach available in VPC subdomains , let’s review how this has traditionally been handled.
Traditional guest VLAN tagging (Trunking)
In a vSphere distributed port group (dvPortGroup) or a VLAN-based segment in NSX, GVT is enabled by configuring the port as a trunk . This involves specifying a range of allowed VLAN IDs instead of just one ID. In this trunk model, traffic sent by a VM with VLAN tag X is sent to the physical network as if it were tagged with X. The physical network infrastructure is then responsible for processing this tagged traffic.
Guest VLAN Tagging on Overlay Segments in NSX
Enabling GVT on an overlay segment in NSX (by configuring a VLAN range) works similarly at first. VM traffic that has a VLAN tag is entered into the overlay segment, retaining the same tag. Because NSX sees the tagged frames, it treats them as simple Layer 2 traffic. As a result, many advanced NSX services that only apply to IP traffic (such as routing, load balancing, or distributed firewalling) cannot inspect or process this tagged traffic. To solve this problem, NSX provides the VLAN Mapping feature . This feature allows a vNIC to distribute its tagged traffic to multiple different segments. With this configuration, traffic sent by a vNIC with a VLAN X tag is automatically stripped of its tag and injected as untagged traffic into the segment specified for VLAN X. Since the traffic on the segment is untagged, the full set of NSX capabilities can be applied to it.
This feature, which uses the concept of parent/child port , is explained here:
Implementing VLAN-to-Subnet Mapping in a VPC
In the Virtual Private Cloud (VPC) model , there is no option to trunk Guest VLAN Tagging across a subnet, but this model provides a simpler and more powerful method that is equivalent to the VLAN routing/segmentation feature in NSX Segment . The main difference is that this routing is done at the subnet level , rather than on each vNIC port, which makes management significantly simpler.
Scenario: Before applying the route
In this example, there is a virtual machine ( VM1 ) that sends traffic tagged with VLAN 10. This VM is connected to a subnet called sub-nogvt . Since sub-nogvt expects only untagged traffic, any frames arriving from VM1 with VLAN 10 tag are dropped .
Solution: Subnet Binding
To fix this problem, we first create another subnet in the same VPC called subnet-10 . This subnet is going to receive VLAN 10 traffic, except that the VLAN tag has been removed. We then create a binding between the subnets to route VLAN 10 traffic from sub-nogvt to subnet-10 . This is done with just one API call:
/policy/api/v1/orgs/{org-id}/projects/{project-id}/vpcs/{vpc-id}/subnets/{subnet-id}/subnet-connection-binding-maps/{map-id}
In our example, let’s say there is a VPC named myVPC . The API call would look like this:
PATCH /policy/api/v1/orgs/default/projects/default/vpcs/myVPC/subnets/subnet-10/subnet-connection-binding-maps/map-vlan-10
Content-Type: application/json
{
"vlan_traffic_tag": "10",
"subnet_path": "/orgs/default/projects/default/vpcs/myVPC/subnets/sub-nogvt"
}
This binding instructs the VPC switching infrastructure to first remove the tag and then forward the untagged frame to subnet-10 whenever VLAN 10 tagged traffic is seen on any port connected to sub-nogvt .
Now, if VM2 connects to subnet-10, VM2 will receive untagged traffic that was originally sent by VM1 on VLAN 10. This mechanism is bidirectional and creates a communication path—similar to port-level routing in NSX but now implemented at the subnet level .
Key Benefits of Subnet-Level Mapping
The main advantage of this approach is that it is automatically applied to all virtual machines on the subnet , without the need for separate configuration on each vNIC.
New machines on the Source Subnet
If we connect VM3 to the sub-nogvt subnet , it will automatically inherit this behavior. VM3 can send VLAN 10 tagged traffic and communicate with VM2 without any additional configuration.
New machines on the destination subnet
If we connect VM4 to subnet-10 , it can immediately communicate with VM1, VM2, and VM3 via untagged traffic .
Intra-Subnet Communication
This binding also allows communication between machines on the same source subnet. If VM1 and VM3 are both on the sub-nogvt, their traffic tagged with VLAN 10 is normally dropped.
But with Binding enabled, traffic from both VMs is directed to subnet-10 , allowing communication through the routed subnet.
Conclusion: A Flexible Way to Manage VLAN Tagging
This sub-segment routing approach provides a clean, scalable, and API-based solution for managing VLANs in virtual environments. This approach ensures that VLAN-tagged traffic can be processed by the entire set of VPC network services. Of course, a vNIC can be connected to multiple sub-segments simultaneously using multiple VLAN tags , allowing for more complex and flexible communication topologies.
