Trying to understand vlan-filtering + datapath.vlan-id in capsman AX

RouterOS Wireless Networking
1

I’ve been trying to wrap my head around vlan isolation while using capsman.
My setup:

  • ccr2116 as a capsman and two hap ax2 and one ax3 as CAPs.
  • Two wifi networks: “trusted” (vlan-id 10) and “untrusted” (vlan-id 30)


/interface wifi datapath
add bridge=bridge bridge-horizon=10 client-isolation=yes name=untrusted-datapath vlan-id=30
add bridge=bridge name=trusted-datapath vlan-id=10

It’s all working perfectly on a CAP i can seed dynamically added interfaces with correct vlan ids

  • 5 D wifi1 bridgeLocal 10 0x80 none
  • 6 D wifi11 bridgeLocal 30 0x80 none

but… vlan-filtering is set to “no” on the bridge itself which in my mind defeats the purpose isolating wifi networks, what I’m i missing?
BTW bridge horizon from the datapath is not applied as well :frowning:

2

Do these interfaces get added as access ports or trunk ports to bridge? Check it using /interface/bridge/vlan/print .

If they are added as untagged, then it VLAN settings are ihnored and you’ll have to set vlan-filtering=yes on bridge on all cAP devices. (Do enable safe mode before enabling vlan-filtering on bridge, you could loose management access if bridge config is not “ready” for vlan-filtering).

If they are added as tagged, then traffic separation based on VLAN IDs works without bridge being aware of it, wifi interfaces make sure of it (bridge is in this case operating as a dumb switch, passing frames between ports only according to dst MAC addresses … which means that occasionally a frame with wrong VID will be delivered to wifi interface, but wifi interface will drop it as unusable according to its own config).

3

That’s the thing: the interfaces were added as access ports (PVID were added), but since vlan-filtering is not enabled

/interface/bridge/vlan

table is not populated at all

4

I have a related question. To the OP, I think without vlan-filtering, it just means the bridge is VLAN-unaware which works just fine, albeit not that secure.

My question is about when vlan-filtering is enabled. It appears that my wi-fi interfaces are added with the Wi-Fi interface set with PVID from the datapath, and it is also tagged. In other words, if my datapath has VLAN ID=4, the Wi-Fi interface will have PVID=4, and the Wi-Fi interface is tagged for that VLAN in the VLAN table. This config doesn’t work (i.e. Wi-Fi client can associate but unable to get an IP address).

I believe the traffic should have entered the bridge from the Wi-Fi Interface tagged with VLAN 4. So the PVID should not be set (i.e. default to 1).

I wonder how this should be setup if I want vlan-filtering enabled?

5

Generally with bridge which is vlan enabled, there are two halves of the story, both halves are more or less unrelated (whether more or less depends on some config details):

  1. /interface/bridge/port is about ingress. PVID is set there and it affects the ingress untagged frames. If frame-types is set either to all or untagged, then untagged i gress frames get tagged with PVID.
    If frame-types is set to all, then frames already tagged with VID equal to PVID setting are accepted and passed on unaltered (since PVID only affects untagged ingress frames)
  2. /interface/bridge/vlan is about egress. If port is set as tagged member, then frames with matching VID will egress tagged. If port is set as untagged member, then frames with matching VID will egress untagged. Frames with VID not natching any of VLANs configured will not egress such port.

And then there are a few settings which start to relate bullets a) and b):

  • setting PVID on a port according to bullet a) will automatically add port as untagged member of said VLAN according to bullet b)
  • setting ingress-filtering=yes on port will filter ingress frames on such port according po port membership from bullet b) … Without setting it, connected device could inject frame with any VID set and would be alliwed on ingress … and would be delivered to devices proper members of target VLAN. Settings in b) would block bi-directional traffic (but if the other device would exploit the same “hole”, then even bidirectional communication between devices supposed to be in different VLANs would be possible)
  • setting PVID doesn’t matter if connected device is talking tagged frames
  • automatically adding port as untagged member of VLAN due to PVID setting (bullet a) ) is overriden by setting said port as tagged member of same VID (bullet b) )

In case of capsman with datapath.vlan-id and wifi-qcom (not -ac) on CAP, wifi interface is indeed configured with pvid and frane-types=all in port section, but is also configured as tagged member of same VLAN. And since wifi driver actually manipulates VLAN tags, things work out as intended.
Problem is with CAPs running wifi-qcom-ac though … those require some manual workarounds.

6

We specifically come to this forum to not know what those “some” manual workarounds are. It’s nice you know about them and take your time to mention them, but rather use that time to include them, otherwise the post is borderline pointless as this is known major change/issue for lifecycle management. Remember to abstract the subject by not including comparable excerpts of said configuration differences. Not to mention the poor owners of https://help.mikrotik.com/docs/spaces/ROS/pages/103841836/CRS1xx+2xx+series+switches+examples devices which do VLAN completely differently.

7

No offense but you might want to change tone a bit.

You are not the poster asking for assistance and since in his initial post, he only mentioned AX devices, mkx rightfully mentioned the fact it is slightly different for ac devices.
There is no added value to add that info here in this thread because within this context it is completely irrelevant.

If you are looking for that specific info, then simply ask. And it helps to do so nicely.
Surely some knowledgeable members will chime in to provide you that info.

8

Hi mkx!

Thanks. Your reply is clear. I somewhat understood how this is all supposed to work, but started to doubt myself when things didn’t work out as I expected. Nevertheless, your reply prompted me to dig deeper and consider other possibilities. TL;DR, I think my problem was due to VLAN filtering / hw-offload on a multi-switch RB4011. Although this isn’t quite the original topic of this thread, let me just share anyway the background.

This is my test setup when vlan filtering did not work as I expected at the hAP ax:

RB5009(WAN/router/capsman) - RB4011 - hAP ax(cap)

There was no problem with RB5009 to hAP ax directly. So I narrowed down specifically to the RB4011. I had not considered it before because my earlier troubleshooting step tested this scenario:

RB5009 — (ether1) RB4011 (ether4) — test PC that worked fine

That was fine because ether1 and ether4 are on the same chip. However, my hAP ax was on ether10 which is a different switch chip from ether1 on the RB4011:

RB5009 — (ether1) RB4011 (ether10) – hAP ax

Disabling hw-offload on the RB4011 worked. Replacing the RB4011 with an old RB962 also worked fine. And of course, knowing what the issue now, there are many other ways to resolve (e.g. put everything on the same switch chip at the RB4011 if I still want hw-offload).

Hope this might help someone. :slight_smile:

9

Which version of ROS is running on your RB4011? When HW offload was introduced, it had a bug: the CPU ports of switch chips was not made tagged member of VLAN if bridge (CPU-facing bridge port) was not member of same VLAN (but should have been because pirts on different switch chios were members of same VLAN). IIRC it was said to be fixed. The workaround was to set bridge port as tagged member of that VLAN (but vlan interface is not needed). HW offload still enabled …