From what I understood, NO-local forwarding (or manager forwarding) causes the system to create new interfaces that pratically reflect the wireless interfaces of each AP.
This requires a bridge (and only a bridge) to be declared as datapath in manager configuration.

As I use VLANs , how can I set datapath correctly ?
Should I configure a new bridge including VLAN as slave , to be used as datapath for CAPsMAN ?

The existing ip address assigned to vlan and dhcp server running on it, should be moved on bridge ?

Hi,

I could never get Manager forwarding working with VLAN's and in the end settled for local forwarding. If you ever do find a solution, please let me know.

Whilst I would agree that I would prefer to have manager forwarding, in the end, having spent a good number of hours trying to make it work, I decided it was of limited value for me and not worth the time or effort. As I said though, if you do get it working I'd love to know how to do it

• if you use datapath, the frames received from the air get encapsulated into UDP and are forwarded to the manager device, where they are decapsulated and land in the bridge on that device indicated in the datapath configuration
• if you use local forwarding, which I didn't yet, I've understood it the way that the frames received from the air land in the indicated bridge on the cAP (/interface wireless cap set bridge=some-cap-bridge-name)

If you configure VLAN usage for a wireless interface, the VLAN tag is added to the frames as soon as they get received from the air, so regardless whether local forwarding on cAP or datapath on manager is used, the VLAN handling on the appropriate bridge must be set.
(Everything applies mirrored for frames sent over the air).

And for each VLAN for which you want to provide the IP subnet and DHCP server locally (rather than on some external device to which you extend that VLAN on L2), you need to create an /interface vlan with the appropriate brigde as its carrier interface, and attach the IP and DHCP server configuration to that /interface vlan. That /interface vlan may be on the cAP, but you may also set up an L2 trunk between the cAP and the manager (so the wireless frames end up on the manager device anyway but using a VLAN rather than UDP encapsulation) and the /interface vlan may be on the manager device.

Sindy,
I admit CAPsMAN philosophy is a little tricky for unexperienced like me.
I always used NO local forwarding, just all traffic controlled by manager (mostly wifi for some hotels)
But they don't need VLANs yet, I'm doing some experiment in laboratory where are four VLANs

I need a pair of SSID (master-slave config on CAP) each associated to a VLAN.
Meanwhile, I tried to build a pair of bridges, including the VLAN interface into each
Then I choosen them as datapath for each SSID configuration
SSID1 traffic has bound to VLANx, SSID2 traffic has bound to VLANy
DHCP servers are still working on VLAN interfaces, however clients receive their appropriate leases correctly.


It seems to work but probably it couldn't be the right way to do it
Still looking for some suggestion from someone more experienced.....

Hi Sindy,

Thinking back, actually I did get the VLAN traffic back into the CAPs controller. I was using a CRS as the controller, and what I couldn't get working was the manager forwarding with VLAN's and wirespeed switching on the switch chip on the CAPs controller.

I could have manager forwarding, but probably because of the need for multiple bridges, I needed to switch using CPU on the controller, or alternatively I could have local forwarding using the switch chip on the both the CAPs client and controller. In the end I valued the speed from the switch chip more than the manager forwarding.

That was before the new bridge/HW offloading though. With the new bridge and HW offload, do you think it would be possible to configure manager forwrding whilst still using the switch chip to get wire speed?

With the new bridge and HW offload, do you think it would be possible to configure manager forwrding whilst still using the switch chip to get wire speed?

I'm afraid there is no difference. The new bridge implementation changes nothing in hardware, it just changes the way how the user configures the Ethernet ports of the switch chip belonging to the same bridge. The "old" way, you chose one "master" port and made it a member of the bridge, and the other member ports of the same bridge on the switch chip were marked as "slave" ports of the "master" one rather than individual member ports of the bridge. The "new" way, you make all ports members of the bridge, and the RouterOS automatically switches on "hw-offload", which actually means switch chip forwarding between member ports on the same switch chip if other pre-requisites are met.

But the wireless interface has no direct path to the switch chip, so the frames from the wireless module to the switch chip are always forwarded by the CPU, regardless whether old or new bridge implementation is running on the same hardware.

A small speed-up might be obtained if you would use local forwarding, where the frame received from the wireless interface would be sent to the switch chip already at the cAP and then forwarded to its L2 destination directly, whereas in case of manager forwarding, the frame is first encapsulated into UDP, then sent to the switch chip, delivered to the manager, unpacked from UDP there and sent to the manager's switch chip again and forwarded to its L2 destination from there. But this obviously only makes a difference where the L2 destination is not the manager so the frame only passes through the switch chip and CPU on the cAP with local forwarding, as compared to two passes through a switch and CPU with manager forwarding. If the L2 destination is the manager, the only difference which remains is the encapsulation and decapsulation to/from UDP.

Thanks for the confirmation.

It was probably my issue, but the issue that I had was that with manager forwarding was that I couldn't implement it successfully using the VLAN's without breaking the full switch chip implementaiton on the core swtich, meaning that all of the switching on the core switch was happening in software rather than on the switch chip.

I would have been happy with just the wireless being switched in the bridge and the rest being switched at wire speed.

In any case, I settled with the slightly more efficent config that you described of having Local forwarding on and the wireless bridged to the local switch chip.