I am looking at this page WiFi - RouterOS - MikroTik Documentation and specifically at the CAP configurations suggested for the wifi-qcom and wifi-qcom-ac packages. What specifically catches my eye is that the wifi-qcom-ac configuration has these lines which are absent from the wifi-qcom configuration:
These set up the vLAN configurations on the Access point and allow the vLAN to be configured to use the required ethernet ports.
This element of configuration is not present in the wifi-qcom configuration. In part, as I understand it, this is because the wifi-qcom package on the CAP allows the CAPsMAN to set the CAP datapath to a vLAN.
What I don’t understand is how the vLAN on the CAP is configured to the required ethernet ports. [I can see how the datapath specified on the CAPsMAN is sufficient to connect the wireless interfaces to the vLAN]. Can anyone explain how the ethernet ports are configured? Or is it just that this has been omitted from the example configuration?
Take what I am about to say with a grain of salt as I am a network student still learning but this is so far my understanding on how it all works.
Usually no configuration is needed in terms of manually configuring trunks or assigning ports to VLANs. The wifi-driver can automatically tag packets inbound and drop packets outbound (that aren't tagged with the same vlan-id as defined in datapath vlan-id). This means you leave vlan-filtering disabled on the bridge which keeps it in SVL.
Let's pretend you have the Cap AX. Two wifi interfaces and two ethernet ports. If they are all added to the bridge and BUM traffic arrives from wifi1. It will be flooded to wifi2, ether1 and ether2. Wifi2 will drop the traffic if the tagged ID is not the same as what is set in its datapath vlan-id, then the traffic is flooded to ether1 and ether2.
Ether2 for me in this instance is disabled, so the only path left for it to go is ether1 which is upstream towards the rest of my network.
Thanks, that makes sense as far as it goes, certainly for a single CAP ax [which can take the wifi-qcom package].
But let’s pretend a bit more. Suppose I also have a L009UiGS-2HaxD-IN [which also can take the wifi-qcom package] on the same guest network. Now we are going to flood ports ether2 to ether8 with traffic for the same guest network. There is a question over ether1, which we can ignore for the moment.
Now, to make the Guest WiFi work across several Access points, we need all the [slave] wireless interfaces connected to the same vLAN, in order that we have a Single Broadcast Domain on which we can place a DHCP server. So are you saying that this vLAN would go to all of the ethernet ports?
The basic idea about VLANs is ... that they're (correctly) configured everywhere. And that includes both wifi AP device and upstream switches/routers.
The way of doing it as described by @TrevinLC1997 is fine for cAP or wAP devices which typically come with one or two ethernet ports and (at least one of them) will be used as upstream (tagged or hybrid) port. Namely without setting VLANs on bridge/wired part of device, VLAN tags won't be manipulated in any way and will hence be passed unaltered on through any of "indifferent" ports. Hence it doesn't make much of a problem if device is not (properly) configured for VLANs (and that's a pretty normal state if device is set as CAP device - "slave" to CAPsMAN which only provisions wifi part of device).
If that wifi interface is part of "larger bunch of ports" (e.g. L009 which has 8 ether ports or hAP ax2/3 which have 5 ether ports), then it's to be expected that device is properly configured for VLANs (bridge with vlan-filtering=yes, ether ports with proper VLAN membership and PVID set).
The difference between wifiX interface acting as tagged port (wifi-qcom which can tag/untag frames) and wifi interface acting as access/untagged port (wifi-qcom-ac which can't do anything about VLAN tags) is twofold: 1. difference in configuration of appropriate bridge port and 2. functional difference (tagging inside wifi driver allows for ACL-based or PPSK-based separation of stations into different VLANs).
Actually the other way around but same net result.
Wifi-qcom-ac package is not able to handle VLAN tags through datapath. That's why those wifi interfaces need to be configured on bridge to handle required VLANs properly.
Ports are set to default which means accept all. Tagged and untagged. Bridge is also no set to vlan filtering so also there, it accepts all.
You can see in capsman controller example all ether ports are defined as trunk for vlan10 and 20.
Base management traffic is done untagged over pvid=1.
My personal preference is using VLAN all the way, caps and controller, also for management traffic and including VLAN-filtering on all bridges.
OK, so part 1 of this is you can run vLANs over “indifferent” ports and let whatever other router, switch etc plug into that vLAN. That makes sense because in my carefully crafted noob CAPsMAN set up with an L009 and a CAP ac I can run ordinary LAN traffic alongside my Guest network vLAN over the link between the 2 and I have even split the link with a Netgear GS108 unmanaged switch. I wasn’t expecting to be able to do this.
And part 2 is that the configs for the reference I give in my opening post are inconsistent in that the wifi-qcom-ac example explicitly sets up the vLANs, whereas the wifi-qcom example implicitly assumes that if you want your vLANs to go to specific ports, you will have set it up on your own initiative.
Not quite sure what I have got the wrong way about? I have just checked about the element of config not being required for wifi-qcom …
But the example has vlan-filtering set on? Are you saying it would all run with vlan filtering off?
I am new at vLANs. OK I did configure a standalone access point with a purely internal vlan just to create a Single Broadcast Domain for guest network on 2 wireless interfaces. Now that I have a multi access point setup, I have had to go all the way across my LAN and I think my preference is to be explicit about entry and exit ports. But my functional requirement is only to have a Single Broadcast Domain for the Guest network, to support a single DHCP server across several access points. So I have only done the Guest network as a vLAN.
Outed me as a noob with vLANs! Fair enough. I know most of these rules.
As for the vLAN topic, I have read it before and like most vLAN material out there, it confused the hell out of me. What I have come to understand after all my reading and watching is that a vLAN allows you to define a Single Broadcast Domain and if you can’t see a need for an Single Broadcast Domain, a vLAN is not going to help you, which I think might be a good additional rule. Where I have seen a need for an SBD, I have ultimately been able to set up the required vLAN