Configuring Mixed VLAN Modes (Tagged/Untagged) on OpenWrt Switch Ports for Ubiquiti Device Management


2 views

When managing network devices like Ubiquiti Nanostations through OpenWrt, we often need to handle both:

  • Untagged traffic for client devices (wireless clients)
  • Tagged traffic for device management (SSH/web interface)

The proper configuration requires these key elements in /etc/config/network:

config switch_vlan
    option device 'switch0'
    option vlan '3'        # Management VLAN (tagged)
    option vid '3'
    option ports '0t 3t'   # Tagged on CPU and port 3

config switch_vlan
    option device 'switch0'
    option vlan '4'        # Client VLAN (untagged)
    option vid '4'
    option ports '0t 3'    # Untagged on port 3

config switch_port
    option port '3'
    option pvid '4'        # Default VLAN for untagged packets

After applying changes, always verify with:

swconfig dev switch0 show
vconfig list
ifconfig -a

Key things to check:

  • The 't' flag appears for tagged VLAN ports
  • PVID matches your untagged VLAN ID
  • VLAN interfaces appear in ifconfig output

For this hardware platform, note these characteristics:

# Check switch capabilities
swconfig dev switch0 help
  • Maximum 16 VLANs supported
  • Port 0 is always the CPU port
  • Hardware offloading available for VLAN processing

If connectivity issues persist:

# Capture VLAN tagged traffic
tcpdump -i eth0 -e -n vlan

Potential solutions:

  • Reboot after configuration changes
  • Clear switch configuration cache
  • Check for firmware updates

When working with the MikroTik RB750UP running OpenWrt BARRIER BREAKER (r36085), I encountered a specific networking scenario that required both tagged and untagged VLAN traffic on the same physical port. This setup is particularly relevant when:

  • Managing network equipment (like Ubiquiti NanoStations) that require tagged management traffic
  • Providing untagged access to client devices simultaneously
  • Maintaining separate broadcast domains on a single interface

Here's the original switch configuration that wasn't working as intended:

config switch_vlan
    option device 'switch0'
    option vlan '3'
    option vid '3'
    option ports '0t 3t'

config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '4'
    option ports '0t 3'

config switch_port
    option port '3'
    option pvid '4'

After extensive testing, here's the corrected configuration that properly handles mixed VLAN traffic:

# Management VLAN (tagged)
config switch_vlan
    option device 'switch0'
    option vlan '3'
    option vid '3'
    option ports '0t 3t'  # Must include 't' for tagged

# Client VLAN (untagged)
config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '4'
    option ports '0t 3'   # No 't' suffix for untagged

# Port configuration
config switch_port
    option port '3'
    option pvid '4'       # Default VLAN for untagged traffic
    option enable_egress_tag '3'  # Critical for proper tagging

The crucial elements that made this configuration work:

  1. Proper Tag Notation: The tagged VLAN must include the 't' suffix (3t) while the untagged VLAN must not (3)
  2. Egress Tagging: The enable_egress_tag option ensures proper VLAN tag handling on egress
  3. PVID Assignment: The port's PVID must match the untagged VLAN ID

After applying the configuration, verify with these commands:

swconfig dev switch0 show
vconfig list
ifconfig eth0.3
ifconfig eth0.4

Common issues and solutions:

  • Missing tagged traffic: Check if enable_egress_tag is properly set
  • VLAN interface not coming up: Verify VLAN IDs match between switch and interface config
  • Port assignment conflicts: Ensure no duplicate VLAN assignments on the same port

The complete working interface setup:

config interface 'management'
    option proto 'static'
    option ifname 'eth0.3'
    option ipaddr '192.168.20.1'
    option netmask '255.255.255.0'

config interface 'client_network'
    option proto 'static'
    option ifname 'eth0.4'
    option ipaddr '192.168.100.1'
    option netmask '255.255.255.0'