MikroTik Bridge VLAN Filtering: A Complete Tagged and Untagged Port Configuration Guide

Byadmin
Share
Tweet
Share
Pin
0 Shares

MikroTik RouterOS bridge VLAN filtering turns a bridge into a VLAN-aware Layer 2 switch: it classifies untagged ingress traffic using each port’s Port VLAN ID (PVID), checks VLAN membership, and sends frames tagged or untagged according to the bridge VLAN table. The safe pattern is to configure bridge ports and VLAN membership first, confirm management access, and enable vlan-filtering last.

This guide uses RouterOS v7 syntax and a small example network. Interface names, VLAN IDs, IP addresses, and hardware capabilities vary by deployment; adapt the examples before applying them. A mistaken VLAN table can expose traffic between segments or disconnect management access.

1. Example topology

Assume a MikroTik switch has one upstream trunk and two endpoint ports. VLAN 10 is for staff, VLAN 20 is for guests, and VLAN 99 is for device management.

Interface Role VLAN membership Endpoint framing
ether1 Trunk to upstream router/switch 10, 20, 99 tagged 802.1Q tagged
ether2 Staff access 10 untagged Untagged; PVID 10
ether3 Guest access 20 untagged Untagged; PVID 20
bridge1 Router CPU/management VLAN participation 99 tagged Tagged VLAN 99 to the CPU

In this design, the upstream device must also carry VLANs 10, 20, and 99, and provide routing/DHCP services if required. A Layer 2 bridge does not automatically create IP interfaces, DHCP scopes, or inter-VLAN routing. For the DHCP side of a routed VLAN design, see our MikroTik DHCP relay guide.

2. Tagged, untagged, PVID, and VLAN table

  • Tagged port: sends frames with the relevant VLAN tag. Trunks normally carry several tagged VLANs.
  • Untagged port: sends frames without the VLAN tag for that VLAN. Endpoint-facing access ports normally use this mode.
  • PVID: assigns untagged and priority-tagged ingress frames to a VLAN on a bridge port. It does not rewrite an already tagged frame into the PVID VLAN.
  • Bridge VLAN table: defines which bridge ports may forward each VLAN and how egress frames are tagged or untagged.
  • frame-types: restricts the kinds of frames accepted on a port, such as tagged-only or untagged-only.
  • ingress-filtering: checks VLAN membership on ingress. Keep it enabled unless a specific, understood design requires otherwise.

These settings work together but are not interchangeable. Setting pvid=10 on ether2 classifies untagged incoming traffic as VLAN 10; it does not, by itself, prevent VLAN 20 from being sent out of that port. The VLAN table controls egress membership, so define each access VLAN separately.

3. Configure access and trunk ports

Use a maintenance window or an out-of-band/serial connection where possible. Export the current configuration and ensure you have a recovery path before changing bridge filtering remotely. The following commands are an illustrative baseline for a new bridge, not a drop-in script for an existing configuration.

Step 1: Create the bridge with filtering disabled

/interface bridge
add name=bridge1 vlan-filtering=no protocol-mode=rstp

If a bridge already exists, do not create a duplicate. Inspect and adapt the existing bridge instead.

Step 2: Add ports and set ingress policy

/interface bridge port
add bridge=bridge1 interface=ether1 frame-types=admit-only-vlan-tagged ingress-filtering=yes
add bridge=bridge1 interface=ether2 pvid=10 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes
add bridge=bridge1 interface=ether3 pvid=20 frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes

The trunk rejects untagged ingress frames. The access ports accept untagged or priority-tagged frames and classify them into their configured PVID. If the trunk must intentionally carry a native/untagged VLAN, do not use this tagged-only policy without designing that native VLAN explicitly.

Step 3: Add VLAN membership

/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge1 tagged=ether1 vlan-ids=20

Because the access ports use matching PVIDs and admit untagged frames, RouterOS dynamically adds them as untagged members of their PVID VLANs. Inspect the effective table after enabling filtering. Explicit entries can be used in some configurations, but avoid combining multiple VLAN IDs in one entry when that would make several access ports members of every listed VLAN.

Step 4: Enable filtering only after the table and management path are ready

/interface bridge
set bridge1 vlan-filtering=yes

Enabling VLAN filtering changes forwarding immediately and can interrupt access. Configure management VLAN access before this step if you manage the device through the bridge. For remote changes, the MikroTik Safe Mode guide explains how to reduce lockout risk. Do not assume that an existing untagged connection will continue to work.

4. Add management VLAN access

If the MikroTik itself needs an IP address on VLAN 99, create a VLAN interface on the bridge, allow VLAN 99 to reach the bridge/CPU, and assign the management address. The example address below is documentation-only; use an address from your management subnet.

/interface vlan
add name=MGMT vlan-id=99 interface=bridge1

/ip address
add address=192.168.99.2/24 interface=MGMT

/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1 vlan-ids=99

Ensure the upstream router or management host is actually connected to VLAN 99 and that firewall input rules permit only the required management services from trusted sources. A VLAN membership entry grants Layer 2 access to the device’s CPU; it does not replace IP firewall policy. Review the broader MikroTik hardening checklist before exposing management services.

If the VLAN 99 row already exists, edit that row to include bridge1 and ether1 rather than creating a conflicting duplicate. RouterOS v7.16 and later can add a dynamic bridge VLAN entry when a VLAN interface is added to a bridge with filtering enabled; inspect the table instead of blindly duplicating it. The bridge itself may be referred to as the CPU port in hardware-offloaded designs.

5. Verify the configuration

Run these read-only checks before considering the change complete:

/interface bridge print detail
/interface bridge port print detail
/interface bridge vlan print detail
/interface bridge host print
/interface vlan print detail
/ip address print

Check that:

  • bridge1 has vlan-filtering=yes only after the intended VLAN table is present.
  • ether1 is tagged for every VLAN it must carry and rejects untagged ingress if that is the design.
  • ether2 is an untagged member only of VLAN 10; ether3 only of VLAN 20.
  • VLAN 99 includes the bridge interface as a tagged member when the router CPU must receive that VLAN.
  • Learned MAC addresses appear under the expected VLAN IDs in the bridge host table.
  • Management access, DHCP, gateway reachability, and intended inter-VLAN policy work from each relevant endpoint.

On bridge ports, the H flag commonly indicates hardware offload. Its absence can indicate that forwarding is handled by the CPU or that the particular port/configuration does not support offload; confirm against the device’s switch-chip documentation rather than treating the flag alone as a definitive fault.

6. Configure a hybrid port

A hybrid port carries at least one VLAN untagged and other VLANs tagged. For example, an access point may expect its management network untagged while carrying client VLAN 10 and 20 tagged. This requires deliberate native VLAN handling; do not simply change a trunk to admit-all and assume it is secure.

For a port where untagged ingress belongs to VLAN 99 and VLANs 10 and 20 should leave tagged, set PVID 99 and allow both tagged and untagged ingress. The port must be untagged for VLAN 99 and tagged for VLANs 10 and 20 in the bridge VLAN table:

/interface bridge port
set [find where interface=ether4] pvid=99 frame-types=admit-all ingress-filtering=yes

/interface bridge vlan
add bridge=bridge1 tagged=ether1,ether4 vlan-ids=10
add bridge=bridge1 tagged=ether1,ether4 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether4 vlan-ids=99

This example assumes ether4 is already a port of bridge1 and the VLAN 99 management row does not already exist. Merge membership into existing rows where appropriate. On a hybrid port, document the native VLAN at both ends and verify which traffic is expected to be tagged.

7. Common mistakes and troubleshooting

Symptom Likely cause What to check
Lost WinBox/IP management access CPU/bridge is not a member of the management VLAN, or the PVID/native VLAN changed Management VLAN table row, VLAN interface, address, firewall input policy; recover through console or a separate unbridged port
Access ports can see another VLAN Several VLAN IDs were grouped with the same untagged ports, or ingress filtering is disabled Each VLAN table row and each port’s PVID, frame types, and ingress filtering
Tagged traffic does not pass VLAN missing from the table, trunk rejects the frame type, or upstream trunk does not allow the VLAN Bridge VLAN table on both ends and port frame-type policy
DHCP fails on one VLAN VLAN is not carried to the DHCP server/router, or the VLAN interface/DHCP relay is missing Tagging end-to-end, DHCP server/relay configuration, and packet capture
Throughput drops and CPU rises Hardware offload is unavailable for the device/chip or the configuration disables it Bridge port flags, supported switch-chip configuration, CPU profile and official compatibility notes
Traffic works one way only VLAN membership differs by direction, ingress filtering rejects return traffic, or the peer’s tagging differs Membership on both ends, PVID/native VLAN, and packet captures on both sides

A useful troubleshooting sequence is: confirm the endpoint’s expected tagging; inspect the ingress port’s PVID and frame-types; inspect the VLAN table for that VLAN and port; verify the next switch/router carries the same VLAN; then check IP services and firewall policy. Avoid disabling ingress filtering as a first response—it can hide a membership error and weaken isolation.

8. Hardware offload and RouterOS version notes

Bridge VLAN filtering is a RouterOS feature, but hardware-offload capability depends on the device and switch chip. MikroTik documents simultaneous bridge VLAN filtering and hardware offload for supported families including Marvell Prestera and several listed chips such as RTL8367, 88E6393X, 88E6191X/88E6190, MT7621, MT7531, and EN7523 under documented RouterOS conditions. Other hardware may forward VLAN-filtered traffic through the CPU or require a device-specific switching method. Consult the current MikroTik RouterOS documentation and the Basic VLAN switching guide for your exact model.

RouterOS defaults and dynamic VLAN table behavior have changed across releases. For example, ingress filtering is enabled by default in RouterOS v7, and since RouterOS v7.16, a VLAN interface added to a bridge with VLAN filtering enabled can cause a dynamic tagged membership entry to be added. Always compare commands and behavior with the documentation for the installed release and inspect the effective configuration.

9. FAQs

Does PVID make a port untagged?

No. PVID classifies untagged or priority-tagged ingress frames into a VLAN. The bridge VLAN table determines VLAN membership and whether egress frames are tagged or untagged.

Should I add access ports explicitly to the VLAN table?

Not always. RouterOS can add ports dynamically as untagged members of their PVID VLAN when their frame-type policy admits untagged traffic. Check the effective table; explicit membership may be necessary for other designs, and existing rows should be edited rather than duplicated blindly.

Why must the bridge interface be tagged in the management VLAN?

The bridge interface represents the device’s CPU-facing path for VLAN-aware bridge traffic. If RouterOS must process an IP VLAN interface on VLAN 99, that VLAN must be allowed to reach the bridge/CPU, commonly by including bridge1 in the VLAN 99 tagged membership.

Can one bridge VLAN table row contain multiple VLAN IDs?

Yes, when the same tagged trunk ports share those VLANs. Avoid grouping multiple VLAN IDs with access ports as untagged members if it would permit each access port to send or receive traffic for VLANs it should not access.

Will bridge VLAN filtering always use hardware offload?

No. It depends on the switch chip, device model, RouterOS release, and configuration. Verify hardware support and bridge port flags; otherwise VLAN forwarding may be CPU-based, and performance may be lower.

Conclusion

A reliable MikroTik bridge VLAN filtering configuration combines three separate controls: PVID for classifying untagged ingress, the bridge VLAN table for per-VLAN port membership and egress tagging, and port frame-type/ingress-filtering rules for admission and isolation. Build and verify the table before enabling filtering, explicitly plan CPU/management access, and confirm hardware offload on the exact device. Keep a backup and recovery path available whenever changing VLAN policy remotely.

References

Check our list of MikroTik guides

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *