Bridge VLAN Filter : not possible to use tagged traffic with VLAN ID = 1

RouterOS General
1

According to the test i did it’s not possible to use tagged traffic with vlan ID = 1 in a bridge using a VLAN filter setup.

It is conflicting with untagged traffic that is using VLAN ID = 1 internally.

As soon as we add an hybrid port with untagged traffic, the bridge create a dynamic vlan filter rule with VLAN ID = 1. This is conflicting with a rule using vlan 1 tagged.

This is a limitation that is not present on hardware switches, (at least procurve ones i’m used to).

This is a problem if there is a need to bridge an hybrid port, where there is untagged traffic and tagged VLAN 1 traffic.
Wouldn’t it be possible to use VLAN ID = 0 for untagged traffic, instead of ID = 1 ?

Seems to be like this inside Cisco hardware and probably most hardware switches.

https://community.cisco.com/t5/routing/what-is-vlan0/td-p/1817088

This problem is not documented in the Router OS wiki.

https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge

Last, what the bridge do if using COS tagged traffic with VLAN ID = 0 ? It is translating it to VLAN ID = 1 internally ?

This seems weird and not logical.

2

The dynamic VLAN memberships are generated from the pvid= setting under /interface bridge port for access and hybrid ports, so if you have all the PVIDs set to something other than 1 there should be no dynamic entries with the value 1.

Internally everything is tagged inside a VLAN-aware bridge, tags matching the PVID are removed on egress though a port. This includes the implicit port between the switch-like role of the bridge and the port-like role connecting the bridge to services within the Mikrotik.

The various switch chips in different models operate in different ways.

3

My test has been done on a Hap ac lite using Router OS 7.1 beta 2.

Does this mean that untagged traffic should be moved to something else than 1 to allow Tagged traffic on port 1 ?

In this case, for example, untagged traffic is moved to VLAN 1000 using PVID = 1000

And then a VLAN interface with VLAN ID = 1000 must be placed on the bridge to access untagged traffic ?

This should free up VLAN 1 for tagged use but this is not intuitive at all and is not designed like this inside hardware switches.

To simplify things i did remove the VLAN 1 in my network and did replace it by another ID.

If i’m right, the best practice with Mikrotik hardware to keep things clear would be to not use VLAN 1 inside trunks (tagged traffic with VLAN ID = 1), at least if untagged traffic should be carried at the same time inside the bridge.

This is not in accordance with the 802.1q standard that say that every ID between 1 and 4094 can be use for a VLAN.

If vlan 1 (or another one if changing the default PVIDs) is reserved inside mikrotik bridge for untagged traffic, then the available number of VLAN IDs is 4093, not 4094 as in the 802.1q standard.

It would be better to use PVID = 0 to classify untagged traffic inside the bridge with dynamic filter rules, so that all other IDs could be used for tagged traffic, including VLN ID = 1.

Last, using VLAN ID = 0 to classify untagged traffic internally would be in accordance with 802.1q, as VLAN 0 in a 802.1q frame is used for a frame that must be managed as a non VLAN frame (untagged), but carriyng a COS priority.

It seems to me than a lot of small business networks are using VLAN ID = 1 for historical reasons because this is the default VLAN ID inside hardware switches.

Then it is probable that Mikrotik users can met this problem when those networks have to be extended with VLANs and some bridging inside the routers.

Another point is that it’s most of the time quite complicated to modify VLAN numbering inside a network without disruption.


Did i miss something ?

4

I don’t know if 7.x handles things differently to 6.x, but certainly with that all traffic within the bridge is tagged - untagging only occurs on egress for access and hybrid ports.

When a port is added to a bridge the default is an access port with PVID 1, as with many other settings on Mikrotiks defaults do not appear in /export but can be seen in /export verbose or Winbox.

If you want a trunk (the Cisco meaning, not the HP static link aggregation group meaning) with VLAN IDs 1-4094 tagged the port in question should be set to frame-types=admit-only-vlan-tagged ingress-filtering=yes under /interface bridge port for attached ports or /interface bridge for the implicit port, the VLANs added under /interface bridge vlan, plus VLAN interfaces on the implicit bridge port for any requiring access to services on the Mikrotik.

It isn’t particularly intuitive, some of that comes from the breadth of configuration possible on a Mikrotik, unlike something designed specifically to be a switch. Having learnt abount VLANs on Procurve using
vlan N
tagged PORTLIST
untagged PORTLIST
no untagged PORTLIST
having to faff around directly with PVIDs and access/hybrid/trunk operation directly is a pain, and afflicts other manufacturers devices as well as Mikrotik,

5

You really need to read this reference…
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

6

Good descriptions here but i know what a VLAN is, Q in Q, Cos in VLans, the internal structure of the frame, ingress and egress filtering, DHCP on vlans, inter vlan routing, VRF, MPLS, VPLS, and so on.

What i’m saying here is that the Mikrotik implementation does not follow the 802.1q standard because it does not allow hybrid ports (trunk + access, or tagged + untagged as you want) using VLAN ID = 1 for tagged traffic entering inside a bridge where untagged traffic is present.

Not more, but this is a hassle when you have a network that have a trunk port containing tagged traffic with VLAN ID = 1 and a the same time you need to input it in a Bridge that was previously setup with untagged traffic coming from other ports or eventually from a hybrid port.

Simply read the title of the thread : try to put tagged traffic with VLAN ID = 1 inside a bridge where untagged traffic is used as well. It’s not more complicated than that.

I don’t think that Router OS 7 is different at this level. I could take another router to test with Router OS 6, but i’m almost sure it is the same thing.

And yes Procurve is smart with VLANs, for example when you put a VLAN as untagged traffic on some ports, it does remove automatically previous untagged VLAN assignments on those ports.

The way Procurve configuration work is really more intuitive for Vlans, in the console or in the Gui.

But here we are working with a router, definitely with low level setup access. So it is quite ok that a lower level is available for configuration, even if it is very hard for beginners.
There has been some efforts in this regards with Router OS, mainly with some setup warnings. Probably more could be done, and the Winbox Gui enhanced in a lot of areas to make things clearer.

7

It’s not exactly like this in terms that the behaviour is not hard-linked to VLAN ID 1. VLAN ID 1 is nothing special, except that is is used as the default PVID of the virtual local interface connected to the bridge, and default values are not shown in configuration export unless you use the verbose modifier.

To clarify: an /interface bridge configuration row actually adds two objects - the bridge itself (a “virtual switch”), and a virtual local interface connected to that virtual switch. When you assign an IP address to a “bridge”, you actually assign it to that virtual interface. The pvid parameter is also a property of that virtual interface - it is the pvid applied to the untagged frames the CPU is sending. So by changing bridge’s pvid from 1 to some N, frames belonging to VLAN 1 become tagged for egress through that interface and frames belonging to VLAN N stop being tagged.

But otherwise you are right, it is not possible to have all the 4094 VLAN IDs in use as tagged and still have tagless frames pass through the bridge transparently. A tagless frame always gets some VID on ingress, which is the pvid of the virtual or physical interface connected to the bridge. The only difference is that for all interfaces except the “bridge” one itself, the pvid is specified on /interface bridge port rows; there is no such row for the virtual interface mentioned above, whose membership in the bridge is implicit, so this port’s pvid is specified in the configuration of the bridge. And pvid cannot be set to 0 neither at this virtual interface nor at the other member ports of the bridge.

However, I’m not aware of any vendor’s switch which would permit tagless frames to pass transparently through the switch without being made members of some VLAN, and you cannot e.g. specify an instance of MSTP to handle tagless frames along with some group of VLAN IDs.


Frames which arrive with VID=0 in the 802.1Q tag are treated as tagless ones at ingress, in terms that the PVID of the ingress port is placed to the VID bits of the tag, and the COS bits remain unchanged. This is how VID 0 is intended to work in general.

8

I’m not sure i was clear enough.

So lets take a simple example :

  1. Create a Bridge

  2. Put a port inside it, for example ether5. It will get PVID 1 by default.

  3. activate vlan filtering on this bridge. This will create a dynamic vlan rule with bridge(cpu) and ether5 ports.
    You have now a bridge with untagged traffic from port ether5 that can go to the CPU.

  4. put an IP on this bridge and access the router through this IP and ether5 port. you should be able to connect if the firewall does allow it. Internally VLAN ID 1 is routed to the bridge CPU.

  5. Now add a vlan rule on this bridge with VLAN ID = 1, and tagged port ether5.

As soon as you do this you will loose communication with the router because there is a conflict between tagged and untagged on the same internal ID.

According to me and to be in accordance with 802.1q standard, as well as to be intuitive and to not loose one VLAN ID, internally VLAN 0 ID should be used instead of VLAN 1 ID to mark untagged traffic.

This would avoid a conflict between untagged and tagged traffic on VLAN ID 1.


The workaround, i think, to allow untagged traffic and tagged vlan 1 traffic at the same time, would be to put the untagged traffic on a PVID different from 1. But then we’ll need to put a VLAN inteface for untagged traffic on top of the bridge to access untagged traffic from the CPU !

But doing this we reserve a VLAN ID that will not be available anymore for some tagged traffic, and it is really counterintuitive.

I tried to use PVID = 0 when adding a port to the bridge but unfortunately this does not work. This should be the default.

9

However, I’m not aware of any vendor’s switch which would permit tagless frames to pass transparently through the switch without being made members of some VLAN, and you cannot e.g. specify an instance of MSTP to handle tagless frames along with some group of VLAN IDs.

Thanks i see i’m not mad now.

Yes on hardware switches (i’m talking about the ones i know quite well, procurve ones) tagless frames need to be on a VLAN you can choose.

But internally i think that untagged traffic is marked with ID = 0 or something different that the range 1-4094, so that remaining 4094 vlans can be used at the same time.

This make a big difference. This mean that you can use VLAN 1 tagged on some ports, and on the same ports use untagged traffic from another VLAN.

Mikrotik would not allow this, except if you decide to use the workaround i described (use a specific VLAN ID for untagged traffic, and use a VLAN interface on top of the bridge to access it though the CPU).

Doing this is counterintuitive, and you need to put a VLAN interface on top of the bridge to access untagged traffic ! Even more counterintuitive.

10

Nope. It is quite normal also on Mikrotik to have some ports set as access ones for VLAN N (and possibly trunk ones for other VLANs), and other ports set as trunk ones to VLAN N (and possibly access ones to other VLANs):

/interface bridge
add name=xxx vlan-filtering=yes pvid=10 ...

/interface bridge port
add bridge=xxx interface=ether1 pvid=10 ...
add bridge=xxx interface=ether2 pvid=10 ...
add bridge=xxx interface=ether3 pvid=20 ...
add bridge=xxx interface=ether4 pvid=20 ...

/interface bridge vlan
add vlan-ids=10 bridge=xxx tagged=bridge,ether3,ether4 ← Edit: see @Buckeye ‘s comment below
add vlan-ids=20 bridge=xxx tagged=ether1,ether2

With such a configuration, tagless frames that ingress through ether1, ether2, or the virtual port xxx will get tagged with VID 10, and frames that ingress through ether3 or ether4 already tagged with VID 10 upon arrival will be forwarded to any member port of VLAN 10; tagless frames that ingress through ether3 or ether 4 will get tagged with VID 20.

/interface bridge vlan print will show ether3 and ether4 as current-tagged, and xxx,ether1,ether2 as current-untagged, for for VID 10; for VID 20, the contents of current-tagged and current-untagged will be swapped as compared to VID 10.

11

I think you are misunderstanding IP on the bridge.
This is the vlan that the bridge itself is on. So when you add a IP to the bridge you put that IP on that vlan. View this as the MGMT VLAN.

Now according to the example the last thing you do is to set a rule for vlan 1 that is tagged for Bridge but also tagged for Ether1. This rule will override the dynamic and thus remove untagged vlan1 on ether 5 and you will lose access to the to the router/switch. You need to add vlan 1 as untagged on ether 5 in your example.
I have switches for multiple vendors and none of them allows me to put the same vlan as tagged and untagged at the same time on the same interface. I have not tested this on mikrotik but in the Zyxel switches you cannot via the gui set a vlan as tagged and untagged at the same time for the same interface. Note I can still have PVID set on a interface to for example 20 but set vlan 20 to tagged on the interface. This means that the interface does not work as untagged.
If you follow your example but add ether 5 as untagged for vlan 1 it should work if I understand this correct.

Also note that when you say vlan filtering enabled you basically say that everything must have a vlan. There is no untagged vlan used internally. Only on the port configuration can you say untagged and PVID thus making it a access port and traffic inbound on that port gets vlan added to it according to PVID and if vlan filtering allows for untagged vlan on the same port it works.
Now I do not use vlan 1 but for example all my access points are connected to a MT switch that have PVID set to 3000 and untagged for same port set to 3000. Then all networks that can be accessed over the AP use vlan and tagging. Then I have det all other vlans as tagged on same interface. Works like a charm.

A short disclaimer. I read and wrote this on a phone while tiered. I can have misunderstood everything and all I wrote could be useless :slight_smile:

VLAN Filter - how do ingress and egress rules work?
VLAN Filter - how do ingress and egress rules work?
12

I think there is a typo in the above. Since the bridge has pvid=10, the /interface bridge vlan entry for vlan-id 10 should have untagged=bridge tagged=ether3,ether4 (or with ROS 7.16 or above, you don't even need to specify the tagged and untagged for this config)

The point is that the /interface/bridge/vlan add vlan-ids=10 bridge=xxx bridge entry is applying to the port of the virtual switch that is connected to the router block's bridge interface, and the traffic for the bridge itself is untagged.

Example from 7.19.6 on RB760iGS

[demo@MikroTik] /interface/bridge> export
# 2025-10-07 00:16:41 by RouterOS 7.19.6
# software id = 
#
# model = RB760iGS
# serial number = 
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment=defconf name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=210
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
[demo@MikroTik] /interface/bridge> vlan print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge       200  bridge                          
                 210                                  
;;; added by pvid
1 D bridge       210                  ether4          
;;; added by pvid
2 D bridge       200                  ether2          
;;; added by pvid
3 D bridge         1                  bridge          
[demo@MikroTik] /interface/bridge> set bridge pvid=10  
[demo@MikroTik] /interface/bridge> export            
# 2025-10-07 00:17:09 by RouterOS 7.19.6
# software id = 
#
# model = RB760iGS
# serial number = 
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment=defconf name=bridge pvid=10 vlan-filtering=yes
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=210
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
[demo@MikroTik] /interface/bridge> vlan print        
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge       200  bridge                          
                 210                                  
;;; added by pvid
1 D bridge       210                  ether4          
;;; added by pvid
2 D bridge       200                  ether2          
;;; added by pvid
3 D bridge        10                  bridge          
[demo@MikroTik] /interface/bridge>

For those wondering, I was connected through ether4 in vlan 210 when I made the change. i.e. not using vlan 1 when I changed the bridge pvid from vlan 1 to 10.

Configuring vlans on MikroTik ROS is much easier since 7.16, and I don't enter anything in /interface/bridge/vlan unless I am configuring a bridge vlan that doesn't have a corresponding vlan interface on the router, i.e. configuring a device as a switch where you have multiple ports in a data vlan, but that vlan has no "connection" to the router block.

13

... I don't enter anything in /interface/bridge/vlan unless I am configuring...

Helps when you understand what the config is doing on your behalf, but imagine the new user having it happen automagically and never learning what is going on in the config........ At some point basic learning of setup is instructional and useful.

14

I would not call it a “typo”, it’s a copy-paste error at the best, but most likely plain wrong.

I just cannot remember whether 5 years ago I had in mind to make the VLAN 20 tagged or forbidden on the router-facing-port of the bridge, i.e. whether bridge should just be removed from the tagged list on the vlan-ids=10 row or placed on that list on the vlan-ids=20 row instead.

15

If private messages were allowed, I would have sent you one. I was sure that you understood how it worked.

You explained it well here.

My guess is that it was a copy paste of a config where the bridge had it's default (but hidden from non-verbose exports) pvid=1, and what you did was to manually add pvid=10 to the /interface bridge entry.

I really like the 7.16 change to dynamically update the router to virtual-switch vlan config on the virtual switch port (dynamically adding the bridge as tagged when a vlan interface is created). What I don't like is that there isn't anything in the export that shows this. And there also isn't anything that shows the potential for dynamic entries to be added as a result of setting pvid on an external bridge port. /interface bridge vlan print only shows the entries for external bridge ports that are "up". That's why @anav likes to explicitly add them in the config. The problem with adding them is that it makes it much easier to end up with an inconsistent config if you do change the pvid of a port; it's one more thing that must be changed. I came from cisco and then Ubiquiti EdgeOS (vyatta), and in EdgeOS you configure switch-ports with the pvid and vids, so it is easy to see in the config what is happening (but impossible to change the pvid of the "internal trunk switch-port").

I wish ROS had an export option to show-dynamic additions due to pvid and vlan interfaces (whether link is active or not). The "bridge link" is always up, so the bridge will always show up in output of interface bridge vlan print in the in the current-untagged (for the pvid vlan) and as current-tagged for any vlans that vlan interfaces were created for. What doesn't show up are the external bridge-ports either tagged or untagged when nothing is plugged into the port, you just have to know that any external port with pvid will have an implicit dynamic untagged entry, even though the external bridge-port my not show up in export of vlan bridge port output. That's confusing, at least to people not familiar with the way MikroTik does things.

16

This gross memory lapse, is forgiven, just this once. I cant remember if I brushed my teeth yesterday ......