Bridge VLAN Filtering Problem

RouterOS General
1

Below is a config of a very simple bridge setup using new VLAN bridge method

The line I am interested in is

add interface=bridge name=bridge.vlan2 vlan-id=2

If that line is not in DHCP on VLAN2 will not traverse the bridge yet static IPs work.
No IP in it and really you would think does nothing but it enables DHCP to work on vlan 2

Anyone able to explain why???

Full code of bridge now

/interface bridge
add name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="Transit Trunk"
set [ find default-name=ether2 ] comment="VLAN 2 Access"
set [ find default-name=ether3 ] comment="VLAN 2 ACCESS (Old Port 4)"
set [ find default-name=ether4 ] comment="VLAN 2 ACCESS (Old port 9)"
set [ find default-name=ether5 ] comment="OFFICE WIFI (VLAN 145 ACCESS)"
set [ find default-name=ether6 ] comment="VLAN 2 ACCESS (Old Port 11)"
set [ find default-name=ether7 ] comment="VLAN 2 ACCESS (Old Port 12)"
set [ find default-name=ether8 ] comment="VLAN 2 ACCESS (Pold Port 13)"
set [ find default-name=ether9 ] comment="VLAN 2 ACCESS (Port Old 21)"
/interface vlan
add interface=bridge name=bridge.vlan2 vlan-id=2
add interface=bridge name=bridge.vlan5 vlan-id=5
/interface bridge port
add bridge=bridge interface=ether1 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether2 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether3 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether4 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether5 pvid=145
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether6 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether7 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether8 pvid=2
add bridge=bridge interface=ether9 pvid=2
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=5
add bridge=bridge tagged=ether1 vlan-ids=2
add bridge=bridge tagged=ether1 vlan-ids=145
/ip address
add address=10.0.5.2/24 interface=bridge.vlan5 network=10.0.5.0
2

Configuration of ether1 is contradictory:

/interface bridge port
add bridge=bridge interface=ether1 pvid=2

/interface bridge vlan
add bridge=bridge tagged=ether1 vlan-ids=2

So ether1 it will tag untagged frames with PVID on ingress but won’t untag them on egress. It will accept tagged frames, tagged with VID , on ingress though. So it all depends on how device, connected to ether1, handles VID 2.

Adding VLAN interface with VID 2 to bridge interface should not change the behaviour, bridge port is not member of VLAN 2, neither tagged nor untagged.

It’s not clear where DHCP server for VLAN 2 is and how that relates fo configuration shown.

3

bridge vlan filtering is new but not so new

was officially released in v6.41 (2017-Dec-22), more than 7 years ago

4

http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

5

mkv you are correct ether 1 pvid should be 1 not 2 … that doesn’t change anything because on ether 1 device there is only vids 2, 5, 145

So to clarify the gateway 10.0.2.1 which has the DHCP comes in on VID 2 on ether 1

So the behaviour on any vid or pvid dragged out on any other ethernet to an appropriate setup device is this.
1.) If the device has a static IP it works perfectly (so the vlan is correctly connected)
2.) The device can not get a DHCP lease unless the vlan 2 bridge interface is explicitly declared

So the bridge VLAN2 appears transparent and correct to everything EXCEPT the DHCP putting in the bridge VLAN 2 interface suddenly makes it also transparent to the DHCP.

6

So you’re saying that device, connected to ether1, talks tagged VLAN 2? In this case it should be fine … but the setup is inconsistent regardless and inconsistent configs (port should never be member of some VLAN both tagged and untagged) on ROS end up in inconsistent behaviour.

Do you have configured anything else on that switch of yours? DHCP snooping, IGMP, proxy ARP? Everything is tied together and sometimes it’s necessary to see full config to figure it out (and that includes configuration on adjacent devices).

7

Got rid on inconsistency and behaviour unchanged as expected :slight_smile:

What you see is the singular switch the devices are just PC’s waiting for DHCP from ether1 (via VID 2) and they all get no DHCP unless that interface is present. Ether 1 is another router with only VIDS 2,5,145 and a DHCP server in VLAN 2

It’s not even a device model thing we have about 4 different device models all do same thing … tried all that when we were perplexed.
There are no snooping or ARP proxies and we don’t change anything except enable/disable interface to change behaviour.
OS version 7.17.2 - 7.18.1 all tried and all behave same

It transpires no vlan 2 interface in bridge then no DHCP on VLAN2 goes thru bridge but normal IP traffic does.

8

Can you post full config of the switch (redact sensitive information, like serial number, but don’t overdo it)? And leave model number in it, some devices have some quirks due to hardware layout.

9

You don’t need my config

1.) Setup a bridge in new format with a vlan and connect it to two ports one VID (trunk) one PVID (access)
2.) Have a device with a DHCP server in the VID and connect to your VID trunk port
3.) On the other PVID port have a DHCP client device

I guarantee you the DHCP client on the PVID port will not get a lease.

The only way I can get a DHCP to go thru the bridge is
1.) If it is on the PVID on the trunk port
2.) The bridge has an interface on the VID in the bridge

Behaves like that on all MPSIBE, ARM, ARM64 devices I have tried.

That is why I am asking is this a bug or by design, its not something specific to one configuration.

With this I am guessing ubiquiti unifi users will often be wondering why there APs will adopt but clients can’t get a DHCP lease on the WIFI network. The adoption DHCP runs in PVID the wifi DHCP’s run in the Wifi VLANs. The adoption DHCP will go thru the bridge the wifi DHCP won’t unless they put an interface in bridge.

10

Which I translate into: you don’t need my help.

Out of courtesy, here’s explanation: if you have a problem and can’t solve it yourself, then you’re not really competent to decide which information is crucial for problem analysis and which is not. If you are sure I don’t need information which I think I might need, then you don’t need my expertise. BTW, I have at least one “gotcha” in mind, which could explain what you see … but I won’t bother explaining it if it doesn’t apply to your device model. But you seem to know better, so …

11

I can reproduce this behavior. However, in my case, even adding the VLAN as /interface vlan entry with bridge as parent doesn’t help. Test config were:

A. ether1 as hybrid port, with VLAN 124 tagged. ether5 as access port of VLAN 124. No /interface vlan entry configured for VLAN 124.


/interface bridge vlan
add bridge=bridge tagged=ether1 untagged=ether5 vlan-ids=124

/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=124
add bridge=bridge interface=ether1 pvid=14

vlan124-wo-interface.png
B. ether1 as hybrid port, with VLAN 124 tagged. ether5 as access port of VLAN 124. A VLAN interface is added to /interface vlan for VLAN 124.


/interface vlan
add interface=bridge name=vlan124 vlan-id=124

/interface bridge vlan
add bridge=bridge tagged=ether1,bridge untagged=ether5 vlan-ids=124

/interface bridge port
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=124
add bridge=bridge interface=ether1 pvid=14

vlan124-w-interface.png
in both cases, a client connected directly to ether5 (untagged VLAN 124) gets no DHCP configuration from a router (running OpenWrt) connected to ether1 on tagged VLAN 124 running DHCP server. However the client gets full IPv6 connectivity (with SLAAC/ND) and can use the (OpenWrt) router connected to ether1 to get to the internet with IPv6 only.

In the log of the OpenWrt DHCP server (on ether1) I can see that the router does receive DHCP Discover messages from the client (on ether5), and it did send back DHCP Offer messages but the client never received those answers.

vlan124-dhcp-failed.png
The main router (acting as the bridge for VLAN 124) has settings like DHCP Snooping and IGMP Snooping turned off. It’s a RB5009 with hardware offload for Bridge VLAN Filtering active on the bridge.

It really looks like an undocumented behavior or bug in RouterOS to me too.

12

This thread makes no sense nor do the replies.

First the OP, is this a router or a switch and what model, without context, your questions or observations, are meaningless.

+++++++++++++++++++++++
So we have to play the assume game
a. assumption1 → switch with ether1 uplink to a dhcp router
b. assumption2 → C3XXX series switch where bridge vlan filtering makes sense.
c. assumption3 → vlan5 is the management vlan
d. assumption4 → ether1 as stated transit trunk, is indeed a trunk port, a logical conclusion.

ISSUES:

  1. Only one vlan needs to be identified on the switch and that is the BASE or TRUSTED or MGMT Vlan, in this case remove vlan2.
    /interface vlan
    add interface=bridge name=bridge.vlan2 vlan-id=2
    add interface=bridge name=bridge.vlan5 vlan-id=5

  2. You name your ether1 as a transit trunk and this implies that it is a trunk port to the router.
    Trunk ports ONLY carry tagged vlans. Since you are running a number of vlans, the idea that this is somehow a hybrid port is very far fetched.
    But hey, due to the lack of context and clarity in the post, we have to guess.

Based on your ethernet port comments…
/interface bridge port
add bridge=bridge ingress-filtering=yes frame-types=admit-only-tagged interface=ether1 comment=“trunk port”
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=145
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether9 pvid=2

/interface bridge vlan
add bridge=bridge tagged=ether1 untagged=ether2,ether3,ether4,ether6,ether7,ether8,ether9 vlan-ids=2
add bridge=bridge tagged=bridge,ether1 vlan-ids=5
add bridge=bridge tagged=ether1 untagged=ether5 vlan-ids=145

Any dumb device attached to the switch on ports ether 2-4, 6-9 will get an IP on the vlan2 subnet
Any dumb device attached to the switch on ether5, will get an IP on the vlan 145 subnet.

personally I find ether5, a bit strange, assuming this is a dumb AP that cannot read vlan tags??

13

CG, lets say for shits and giggles the OP made an error calling ether1 a trunkport and for some reason the upstream router passed one subnet untagged on the port leading to ether1 and then a bunch of tagged vlans as well. In other words, the upstream was providing a hybrid port to the MT switch.

This is also very doable. Lets assume First, that vlan5 is coming in untagged on ether1

Option1: Vlan5 is coming in untagged:

/interface bridge port
add bridge=bridge interface=ether1 pvid=5 comment=“hybrid port”
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=145
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether9 pvid=2

/interface bridge vlan
add bridge=bridge tagged=ether1 untagged=ether2,ether3,ether4,ether6,ether7,ether8,ether9 vlan-ids=2
add bridge=bridge tagged=bridge untagged=ether1 vlan-ids=5
add bridge=bridge tagged=ether1 untagged=ether5 vlan-ids=145

+++++++++++++++++

Option2: Vlan5 is coming in tagged and vlan145 is coming in untagged, so still a hybrid port.

/interface bridge port
add bridge=bridge interface=ether1 pvid=145 comment=“hybrid port”
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=145
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 pvid=2
add bridge=bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether9 pvid=2

/interface bridge vlan
add bridge=bridge tagged=ether1 untagged=ether2,ether3,ether4,ether6,ether7,ether8,ether9 vlan-ids=2
add bridge=bridge tagged=bridge,ether1 vlan-ids=5
add bridge=bridge untagged=ether1,ether5 vlan-ids=145

14

Hi Anav,

It appears to make no sense to you because really in this case the MikroTik devices (at least my RB5009 as well as OP’s devices) are not acting as expected with regards to DHCP traffics. The OP (and I in the tests) want the MikroTik device to act as a switch, its job should only be to pass ethernet frames belonging to VLAN 2 (in OP’s case, 124 in my test) between one port and another. And it looks like it fails to do that for frames containing DHCPOFFER messages.

Let’s look at the config from both your Option 1 and Option 2 examples. If you implement that, and have a device running as DHCP server connected to ether1, sending and receiving frames tagged with VLAN ID 2, and then have a device connected to, let’s say ether7 from both your Option 1 and Option 2 config, with DHCP client active. You would agree with us that that client device on ether7 should be able to send DHCP requests and get a DHCP lease from the device running DHCP server plugged to ether1, right? That’s the logical expectation.

But in reality, it currently doesn’t work like that. The DHCP server sees the DHCPDISCOVER packets arriving, and answer with DHCPOFFER, but the client never sees this answer. What interesting is that, as OP has written, if you set static IPv4 addresses on the client device then it can send and receive all other kind of packets without problem. Or in my case, because my OpenWrt router (plugged to ether1 on tagged VLAN 124) has working dual stack with both IPv4 and IPv6, the client device fails to get the DHCP config, but has no problem receiving router advertisement for IPv6 and has fully working IPv6 connectivity. It can use IPv6 over that VLAN 124 link to the OpenWrt router and to the internet, browsing all the websites that support IPv6 without issue.

Only the packets related to DHCP are somehow blocked/filtered, although the MikroTik device should only acts as a switch, with no L3 involvement. And as I wrote, DHCP Snooping is turned off on the MikroTik device.

I made further tests, and the problem is the same if the “client” port is not an access port but a trunk port too.


/interface bridge vlan
add bridge=bridge tagged=ether1,ether2 untagged=ether5 vlan-ids=124

VLAN 124 is tagged on ether1 and ether2, and untagged on ether5. OpenWrt LAN is connected to ether1 on VLAN 124 (tagged). Not-VLAN-aware devices connected to ether5, or VLAN-aware devices consuming VLAN 124 connected to ether2 all fail to get DHCP lease, but have full IPv6 internet connectivity via the OpenWrt router on ether1.

15

The Router providing the DHCP service for all vlans sends all the traffic to ether1 on the Switch, on that we agree.
The switch then takes that traffic coming in ether1 and distributes to any dumb devices on access ports (untagged) or to smart devices, if applicable on trunk ports (tagged) on that we agree.

It would seem yes, that the device requests an IP and it should work, on that we agree.

++++++++++++++++++++++++++++++++++++++++++++++++

The op claims to having issues BUT his configuration was wrong so I will agree with you when
a. config is fixed
b. COMPLETE CONFIG is shown.

I never make leaps of faith without all the facts.

16

VLAN 124 is tagged on ether1 and ether2, and untagged on ether5. OpenWrt LAN is connected to ether1 on VLAN 124 (tagged). Not-VLAN-aware devices connected to ether5, or VLAN-aware devices consuming VLAN 124 connected to ether2 all fail to get DHCP lease, but have full IPv6 internet connectivity via the OpenWrt router on ether1.

This obviously should work.
You have DHCP snooping disabled, still the bridge (resp. the RB5009 switch ASIC) seems to drop ingress DHCP offers on ether1. This is what DHCP-snooping would do on an untrusted port. For the sake of an experiment:
Does it make a difference if you set
a) trusted=yes on ether1
b) trusted=yes on ether1 and DHCP-snooping on bridge enabled

If one of the above helps, there is a bug with DHCP filtering for tagged ports on bridge VLANs without CPU facing interface.

17

I love how we are attacked for reporting a behaviour that seems odd and it takes a mikrotik and 10 minutes to test.

CGGXANNX took 10min and tested and confirmed but still that isn’t enough .. begs question how many people need to confirm to believe it?
Seems weird and even ANAV concluded that it should work.
I solved it myself to some degree I don’t give a flying toss.
All I was trying to do is help others who run across the weird behaviour because it seems wrong.
jbl I will test your ideas and report back later today … so that sounds like you have identified the possible source of the behaviour.

It’s not rocket science to fix the inconsistency in the config above which makes no difference change the PVID on ether1 to 1
Here that is obviously hard … allow me to cut and paste from above and do the single edit

This will not work the DHCP will not traverse the VID 2, you can even remove all VLAN 5 and VLAN 145 stuff and it still won’t work the problem exists for a single VID on a bridge.

/interface bridge
add name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="Transit Trunk"
set [ find default-name=ether2 ] comment="VLAN 2 Access"
set [ find default-name=ether3 ] comment="VLAN 2 ACCESS (Old Port 4)"
set [ find default-name=ether4 ] comment="VLAN 2 ACCESS (Old port 9)"
set [ find default-name=ether5 ] comment="OFFICE WIFI (VLAN 145 ACCESS)"
set [ find default-name=ether6 ] comment="VLAN 2 ACCESS (Old Port 11)"
set [ find default-name=ether7 ] comment="VLAN 2 ACCESS (Old Port 12)"
set [ find default-name=ether8 ] comment="VLAN 2 ACCESS (Pold Port 13)"
set [ find default-name=ether9 ] comment="VLAN 2 ACCESS (Port Old 21)"
/interface vlan
add interface=bridge name=bridge.vlan5 vlan-id=5
/interface bridge port
add bridge=bridge interface=ether1 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether2 pvid=1
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether3 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether4 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether5 pvid=145
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether6 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether7 pvid=2
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether8 pvid=2
add bridge=bridge interface=ether9 pvid=2
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=5
add bridge=bridge tagged=ether1 vlan-ids=2
add bridge=bridge tagged=ether1 vlan-ids=145
/ip address
add address=10.0.5.2/24 interface=bridge.vlan5 network=10.0.5.0
18

jbl42 you are correct doing b solves problem as well

b) trusted=yes on ether1 and DHCP-snooping on bridge enabled

I take it then it’s a bug exactly as you worked out.

I also tried 7.18.2 and it’s unchanged

I dumbed it down to a single vid on two ports … your idea works and the CPU forward facing works
Anything else doesn’t

Here we do b) trusted=yes on ether1 and DHCP-snooping on bridge enabled

/interface bridge
add dhcp-snooping=yes fast-forward=no name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether2 pvid=2
add bridge=bridge1 interface=ether1 trusted=yes

Or just adding the CPU facing interface works

/interface vlan
add interface=bridge1 name=vlan2 vlan-id=2
/interface bridge
add fast-forward=no name=bridge1 vlan-filtering=yes
/interface vlan
add interface=bridge1 name=vlan1 vlan-id=2
/interface bridge port
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether2 pvid=2
add bridge=bridge1 interface=ether1
19

The problem with discussion so far is that I still don’t know which kind of device @OP was working with (and when I asked him to provide details, he outright rejected to give them).

I have hAP ac2, audience and wAP ax running 7.18.1, all with VLANs, most of them confiugred to pass VLANs between interfaces but CPU is not member of all of them. Some are running bridge in CPU, some use L2 HW offload. And for me, DHCP works as expected.

So what you observe might be very specific to certain device model (some of you mentioned RB5009) in certain scenarios (L2 HW offload used). And IMO such details are highly important when chasing a marginal bug (if this bug was mainstream, this forum would be full of reports about it, so far this thread is the only with report of such behaviour).

20

Bullshit I told you above I have tried MPSIBE, ARM and ARM64 devices that I have available

This is what gets me people can’t even bother to spend 2 minutes to read and it’s my fault.
Please understand I don’t need you to solve a problem or help me … I was simply trying to understand the behaviour
One person has already got off there arse and confirmed they see same issue
Someone looks like they worked out why it does it and came up with another way to control behaviour.
So if you don’t believe me I don’t give a fuck

If you want specific models I have tried

PowerBoxPro (MPSIBE)
CCR2004-16G-2S+ (ARM64)
CCR2116-12G-4S+ (ARM64)
CRS308-1G-8S+IN (ARM)

The claim above is it works for me on hAP ac2 I haven’t got that model to verify but I will take him at face value it works.

As I said the most likely audience that will be affected is unifi networks specifically on a full dream machine where the DM has all the DHCP servers and it needs to pass them thru the tik.