Native VLAN assumptions that leak across namespaces

Introduction to VLAN Segmentation

Overview of VLANs and Their Purpose

Virtual LANs (VLANs) are a Layer 2 mechanism that partitions a single broadcast domain into multiple isolated broadcast domains. By assigning a VLAN identifier (VID) to Ethernet frames, switches forward frames only to ports that belong to the same VLAN, limiting the scope of ARP, DHCP, and other Layer 2 protocols. In a security context, VLANs create trust boundaries: traffic from one VLAN should not reach another VLAN without explicit routing or firewall policy.

Types of VLANs: Tagged and Untagged

• Tagged VLANs carry the 802.1Q VLAN tag (TPID 0x8100, 12‑bit VID, 3‑bit priority). Devices that understand 802.1Q can send and receive frames on multiple VLANs over the same physical link (trunk).
• Untagged VLANs (access or native VLANs) transmit frames without an 802.1Q tag. On a trunk port, the VLAN configured as the native VLAN receives untagged frames on ingress and strips the tag on egress for frames whose VID matches the native VLAN.

Understanding Intended Tenant Segmentation

Designing VLANs for Isolation and Security

Tenant segmentation is expressed as a matrix of allowed communications. The intent is translated into VLAN assignments:

• Each tenant receives one or more VLAN IDs.
• Access ports facing tenant endpoints are placed in the tenant’s VLAN (untagged).
• Trunk ports between switches carry all tenant VLANs as tagged frames.
• The native VLAN on trunks is typically reserved for management or left unused to avoid accidental mixing.

Policy path for a frame

1. Ingress port determines VLAN ID (untagged → port’s PVID; tagged → tag’s VID).
2. Forwarding decision looks up the VLAN filtering database (FDB) for the destination MAC.
3. Egress port adds/removes the 802.1Q tag according to its PVID and tagging mode.
   Any deviation from the intended VLAN assignment can cause leakage to another tenant’s broadcast domain.

Configuring VLANs on a Bridge

On Linux bridges (bridge utility) or Open vSwitch (OVS), VLAN segmentation is configured by setting the port VLAN ID (PVID) for access ports and adding VLANs to the bridge’s VLAN filter for trunk ports.

Linux bridge – access port

# Create bridge br0
ip link add name br0 type bridge
ip link set dev br0 up

# Add access port eth0 for VLAN 10 (untagged)
ip link set dev eth0 master br0
bridge vlan add dev eth0 vid 10 pvid untagged
bridge vlan del dev eth0 vid 1   # remove default VLAN 1 if not needed

# Verify
bridge vlan show dev eth0

Linux bridge – trunk port

# Trunk port eth1 carrying VLANs 10,20,30; native VLAN = 99 (management)
bridge vlan add dev eth1 vid 10,20,30 self
bridge vlan add dev eth1 vid 99 pvid untagged   # native VLAN 99
bridge vlan show dev eth1

OVS example

ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0 tag=10        # access port, VLAN 10
ovs-vsctl add-port br0 eth1 tag=20,30,99  # trunk, tagged VLANs 20,30; native 99
ovs-vsctl set port eth1 tag=99            # set native VLAN (untagged) on trunk

After these commands, a frame entering eth0 without a tag is considered VLAN 10, and a frame leaving eth1 without a tag is treated as VLAN 99.

Observed Traffic on a Bridge

Capturing and Analyzing Traffic with CLI Tools

To verify whether observed traffic matches the intended VLAN assignment, capture frames on the bridge or its ports and inspect the 802.1Q tag presence and VID.

Using tcpdump on a Linux bridge port

# Capture on eth0 (access port) looking for any tagged frames
tcpdump -i eth0 -e -vvv 'ether proto 0x8100'

The -e flag prints the Ethernet header; the filter selects frames with EtherType 0x8100 (802.1Q).

Using ovs-ofctl to dump flows (OVS)

ovs-ofctl dump-flows br0

Each flow shows the vlan_tci field (12‑bit VID + priority + CFI). A value of 0xffff indicates no VLAN tag.

Using bridge fdb show to see learned MACs per VLAN

bridge fdb show dev br0 vlan 10

Example CLI Commands for Traffic Analysis

# 1. Count tagged vs untagged frames on eth0 over 10 seconds
timeout 10 tcpdump -i eth0 -e 'ether proto 0x8100' 2>/dev/null | wc -l   # tagged
timeout 10 tcpdump -i eth0 -e 'not ether proto 0x8100' 2>/dev/null | wc -l # untagged

# 2. Show VLAN distribution of learned MACs on bridge br0
bridge fdb show dev br0 | awk '{print $NF}' | sort | uniq -c

Interpreting Traffic Capture Results

• Observed tagged frames on an access port indicate a misconfiguration: the port’s PVID is not stripping tags on egress, or a connected device is sending tagged frames unintentionally.
• Observed untagged frames on a trunk port that belong to a VLAN other than the native VLAN suggest the trunk is allowing frames to leak without a tag, which can happen if the native VLAN is mis‑set or VLAN filtering is disabled.
• MAC addresses appearing in multiple VLAN FDBs signal that the bridge is flooding frames across VLAN boundaries, usually because VLAN filtering is not enabled (bridge vlan filtering off) or the bridge is in learning mode without VLAN awareness.

If the observed state diverges from the intended state, the divergence is typically traced to:

1. Port VLAN configuration (PVID/tagging mode) – incorrect bridge vlan add … pvid or OVS tag= setting.
2. VLAN filtering/global mode – bridge VLAN filtering disabled (bridge link set dev br0 type bridge vlan_filtering 0) or OVS other_config:disable-in-band=true.
3. Device behavior – endpoints sending tagged frames when they should be untagged (or vice‑versa).

Native VLAN Shortcuts and Porous Isolation

Understanding Native VLANs and Their Impact

The native VLAN on a trunk is the VLAN ID assigned to frames that arrive without an 802.1Q tag. When a switch receives an untagged frame on a trunk, it implicitly places that frame into the native VLAN. Conversely, when sending frames out a trunk, the switch strips the 802.1Q tag if the frame’s VID matches the native VLAN.

This behavior creates a shortcut: any device that can send untagged frames onto a trunk can effectively communicate with any other device in the native VLAN without needing a tag. If the native VLAN is used for tenant traffic (or left as the default VLAN 1), the shortcut becomes a path for cross‑tenant leakage.

How Native VLANs Create Security Risks

Consider two tenants, A (VLAN 10) and B (VLAN 20), both connected via a trunk whose native VLAN is set to VLAN 10 (tenant A). A device in tenant B that mistakenly sends an untagged frame (perhaps due to a misconfigured NIC or a software bug) will have that frame classified as VLAN 10 on the trunk. The switch will then forward the frame to all ports in VLAN 10, including tenant A’s access ports, bypassing the intended VLAN 20 isolation.

Policy path for such a frame

1. Ingress on trunk: frame is untagged → assigned native VLAN 10.
2. Forwarding lookup: destination MAC learned in VLAN 10 FDB.
3. Egress on tenant A access port: frame sent untagged (PVID 10) → delivered to tenant A.
   Thus, the observed state shows traffic from tenant B appearing in tenant A’s broadcast domain, even though the intended state had no VLAN overlap.

Example Configuration: Native VLAN Shortcut

# Linux bridge with native VLAN = 10 (tenant A) on trunk eth1
ip link add name br0 type bridge
ip link set dev br0 up

# Access ports
ip link set dev eth0 master br0          # tenant A access
bridge vlan add dev eth0 vid 10 pvid untagged

ip link set dev eth2 master br0          # tenant B access
bridge vlan add dev eth2 vid 20 pvid untagged

# Trunk port (eth1) carrying both VLANs, native = 10
ip link set dev eth1 master br0
bridge vlan add dev eth1 vid 10,20 self
bridge vlan add dev eth1 vid 10 pvid untagged   # native VLAN 10

# Verify
bridge vlan show

If a host on eth2 (tenant B) sends an untagged ARP request, the bridge treats it as VLAN 10 and forwards it to eth0. The observed traffic will show ARP replies from tenant A arriving at the tenant B host, indicating a breach.

Troubleshooting VLAN Segmentation Issues

Common Issues: VLAN Misconfiguration and Unintended Traffic

Using CLI Tools for Troubleshooting VLAN Issues

Linux bridge

# Show global VLAN filtering state
bridge link show dev br0 | grep vlan_filtering

# Dump VLAN port settings
bridge vlan show

# Show FDB per VLAN
bridge fdb show dev br0 vlan 10
bridge fdb show dev br0 vlan 20

OVS

# Show port VLAN configuration
ovs-vsctl list Port eth0 eth1

# Debug flow table for VLAN mismatches
ovs-ofctl dump-flows br0 | grep vlan_tci

# Enable detailed logging (if needed)
ovs-vsctl set Open_vSwitch . other_config:dbg-level=dbg

Example Troubleshooting Scenarios

Scenario 1 – Untagged leakage via native VLAN

1. Observe: Host B (VLAN 20) receives ARP replies from Host A (VLAN 10).
2. Capture on trunk: tcpdump -i eth1 -e shows untagged frames with source MAC of Host B.
3. Check native VLAN: bridge vlan show dev eth1 reveals vid 10 pvid untagged.
4. Fix: Change native VLAN to an unused VLAN (e.g., 99) or enable VLAN tagging on all ports and set pvid to none.

Scenario 2 – Tagged frames on access port

1. Observe: tcpdump -i eth0 -e shows frames with 802.1Q tag.
2. Check port config: bridge vlan show dev eth0 lists vid 10,20 without untagged.
3. Fix: Remove extra VLANs, set bridge vlan del dev eth0 vid 20 and ensure only vid 10 pvid untagged remains.

Scenario 3 – MAC flapping across VLANs

1. Observe: Same MAC appears in FDB for VLAN 10 and VLAN 20, flaps every few seconds.
2. Verify filtering: bridge link show dev br0 shows vlan_filtering 0.
3. Fix: Enable VLAN filtering: bridge link set dev br0 type bridge vlan_filtering 1.

Scaling Limitations of VLAN Segmentation

VLAN ID Limitations and Scalability Concerns

The 802.1Q VLAN identifier field is 12 bits, allowing 4094 usable VLAN IDs (IDs 0 and 4095 are reserved). In large multi‑tenant environments, this limit can be exhausted when each tenant requires multiple VLANs (e.g., for separate tiers, DMZs, or service chains). Additionally, VLAN pruning and trunk bandwidth consumption increase linearly with the number of VLANs carried.

Impact of Large-Scale VLAN Deployments on Network Performance

• MAC table size: Each VLAN maintains its own forwarding database; a switch with 4094 VLANs and many hosts may exceed the hardware FDB capacity, causing flooding or learning failures.
• Broadcast traffic: Broadcast, unknown unicast, and multicast (BUM) traffic is replicated per VLAN, increasing CPU and bandwidth load on switches.
• STP/MSTP overhead: More VLANs mean more spanning‑tree instances (if using MSTP per VLAN or per VLAN group), increasing convergence time and CPU usage.
• Management complexity: Tracking VLAN assignments, native VLAN settings, and trunk allowed lists becomes error‑prone, raising the risk of misconfiguration.

Strategies for Mitigating Scaling Limitations

1. VLAN stacking (Q-in-Q): Encapsulate customer VLANs inside a service‑provider VLAN