The solution to Linux bridge VLAN tagging errors is to enable native VLAN filtering on the bridge interface itself. By setting the
vlan_filtering attribute to 1, the kernel handles 802.1Q tags internally, eliminating the need for manual sub-interface creation and resolving packet drop issues caused by mismatched MAC addresses or unconfigured ports. This approach simplifies network topology and ensures proper isolation between VLANs without complex iptables rules or additional virtual interfaces.
Understanding the Problem with Sub-interfaces
Traditionally, administrators managed VLANs on Linux bridges by creating separate virtual Ethernet interfaces, such as
eth0.10 and
eth0.20, and then attaching these sub-interfaces to the bridge. While this method works, it introduces unnecessary complexity and can lead to subtle networking errors. The primary issue arises because the bridge sees traffic from different VLANs as distinct physical links, which can confuse ARP resolution and MAC address learning tables. When packets are tagged incorrectly or when the bridge attempts to forward frames between sub-interfaces that belong to the same VLAN but are attached via different parent ports, connectivity failures often occur.
Furthermore, managing multiple sub-interfaces requires careful configuration of both the underlying physical port and each virtual interface. If a single physical port needs to carry multiple VLANs, you must create a sub-interface for every VLAN ID. This proliferation of interfaces makes the system harder to maintain and prone to configuration drift. Enabling native VLAN filtering allows the bridge to act as a single entity that understands VLAN tags natively, treating them as metadata rather than separate logical links. This reduces the attack surface and simplifies debugging because all VLAN-aware logic is contained within the bridge device itself.
For more context on related bridging issues, see
Solving VLAN Interface and Linux Bridge Connection Issues.
Enabling Native VLAN Filtering
To resolve these errors, you must configure the Linux bridge to support VLAN filtering. This feature has been available in the Linux kernel for many years but is disabled by default for backward compatibility. You can check the current status of VLAN filtering on your bridge using the
bridge command-line utility. Run the following command to inspect the settings:
bridge vlan show dev br0
If the output indicates that VLAN filtering is not enabled, you will likely see no VLAN entries or an error stating that the feature is unsupported. To enable it, use the
ip link command to modify the bridge device attributes. Replace
br0 with the actual name of your bridge interface:
ip link set dev br0 type bridge vlan_filtering 1
This command tells the kernel to start processing 802.1Q tags on incoming and outgoing frames for this specific bridge. Once enabled, the bridge will automatically strip tags from egress frames if they are part of the PVID (Port VLAN ID) or leave them intact if they belong to other allowed VLANs. It is crucial to note that enabling this feature does not automatically assign any VLANs to the ports. You must explicitly configure which VLANs are allowed on each port and define the PVID for untagged traffic.
Configuring Port VLAN IDs
After enabling filtering, you need to map physical ports to specific VLANs. Use the
bridge vlan add command to specify which VLANs are accessible through a given port. For example, to allow VLAN 10 and VLAN 20 on the physical interface
eth0 connected to the bridge
br0, run:
bridge vlan add vid 10 dev eth0 pvid
bridge vlan add vid 20 dev eth0
The
pvid flag sets the default VLAN ID for untagged traffic entering that port. If a frame arrives without a tag, the bridge assigns it to VLAN 10. Frames tagged with VLAN 20 are processed normally. You can verify the configuration by running
bridge vlan show again. The output should list the ports and their associated VLAN IDs, confirming that the bridge is actively filtering traffic.
Removing Sub-interfaces
Once native filtering is active, you should remove the previously created sub-interfaces to avoid confusion. Delete the virtual interfaces using
ip link delete:
ip link delete eth0.10
ip link delete eth0.20
Ensure that the physical port
eth0 remains attached to the bridge. The bridge now handles all VLAN logic, so the sub-interfaces are redundant. Removing them prevents potential conflicts where both the sub-interface and the bridge might attempt to process the same traffic. This step also cleans up the network namespace, making it easier to monitor traffic flows using tools like
tcpdump.
For further troubleshooting of network drops, refer to
ARP Packets Dropped in Linux Bridge: Troubleshooting a Network Issue.
Verification and Testing
Test the configuration by connecting hosts to different VLANs and verifying isolation. Ping between hosts in the same VLAN to ensure connectivity, and attempt to ping hosts in different VLANs to confirm they are blocked. Use
tcpdump -i br0 to observe tagged frames entering and exiting the bridge. You should see 802.1Q headers present on tagged traffic and absent on untagged traffic assigned to the PVID. This verification step confirms that the bridge is correctly interpreting VLAN tags and enforcing separation.
Frequently Asked Questions
Why do I still have connectivity issues after enabling vlan_filtering?
You may have forgotten to assign a PVID to the port receiving untagged traffic. Without a PVID, untagged frames are dropped because the bridge does not know which VLAN to associate them with. Ensure you set the PVID using the
pvid flag in the
bridge vlan add command.
Can I mix sub-interfaces and native VLAN filtering on the same bridge?
It is strongly discouraged to mix both methods on the same bridge. Doing so can cause unpredictable behavior, including duplicate MAC address learning and ARP storms. Choose one approach: either use native VLAN filtering for all ports or stick to traditional sub-interfaces, but do not combine them.
How do I debug VLAN filtering problems if packets are still dropped?
Use
bridge vlan show to verify that VLANs are correctly assigned to ports. Check
dmesg for kernel messages related to bridge errors. Additionally, use
tcpdump on the bridge interface to see if tagged frames are being received and how they are processed before leaving the bridge.
Does enabling vlan_filtering affect performance?
Native VLAN filtering has minimal performance overhead compared to using sub-interfaces. In fact, it can improve performance by reducing the number of network interfaces and allowing the kernel to optimize packet processing. The CPU cycles saved by avoiding extra interface lookups generally outweigh the cost of tag processing.
What happens to existing connections when I enable vlan_filtering?
Existing TCP connections may be interrupted briefly while the bridge reconfigures its internal tables. It is best to enable this feature during a maintenance window or when network usage is low. Connections will typically re-establish quickly once the new filtering rules are applied.