Community discussions

MikroTik App
 
GiovanniG
Member
Member
Topic Author
Posts: 338
Joined: Sun Nov 15, 2015 4:12 pm

Put a classic unmanaged switch between CAPs

Fri Nov 12, 2021 2:02 pm

Hi, I'm projecting a network, actually there aren't enough ports on CAPSman to manage all CAPs in the building, can I use a normal switch to expand them? Does capsman respect the standard MTU value or it may create issues?
I've read somewhere that it just tunnelling, so it should not, but I can't more find that particular info, so I need your confirmation here before I send to client my estimation.
Thank you a lot!
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: Put a classic unmanaged switch between CAPs

Fri Nov 12, 2021 5:24 pm

You can freely use whatever standard ethernet switch between CAPsMAN and CAP devices. CAPsMAN operates over IP ... normally CAP devices use broadcasts to discover CAPsMAN device and proceed using unicast IP communication. If datapath is set up with local-forwarding=no, then all user traffic will be tunneled between CAP devices and CAPsMAN device, but will observe set MTUs never the less.

If you fear that the dumb switch on the was might actually clip/discard frames longer than 1500/1504 bytes and you run into problems with CAPsMAN forwarding, then you should set l2mtu on involved ethernet ports (under /interface ethernet) to whatever switch is guaranteed to pass ... on both CAP devices and CAPsMAN device.
 
GiovanniG
Member
Member
Topic Author
Posts: 338
Joined: Sun Nov 15, 2015 4:12 pm

Re: Put a classic unmanaged switch between CAPs

Sun Nov 14, 2021 2:40 pm

Thank you for kind answer, can you explain me " but will observe set MTUs never the less"? It means the MTU will not be touched if I set "local-forwarding=no"?
Trying to simplify the concept, I can guess:

1) local forward is enabled by default, it means that when a connecton throug cap-capsman is esablished, the IP packes will be directly placed on bridge and sent by ethernet protocol to the Capsman MAC, which knows how to treath them. Less CPU, no fragmentation, it looks ideal.
In this case for me it is interesting if 2 different caps SSID, placed on 2 different IP domain, will work too.

2) local forward is not set, it means all the packets (probably ethernet ones) should be tunneled by IP to capsman, here or MTU should be increased (how? is it worth?) or fragmentation occours. Also tunnelling all will request CPU, and that's not a good news especially for capsman managing different caps. Is this useful only whn capsman is located on another ethernet broadcast domain?

My goal is:
capsman with 2 ethernt gateways (given by provider), one is for LAN/WiFi private (192.168 /24), second is for guests (10.0 /22) with autentication, on other ports (located on the same bridge) are connected capsman, with a LAN IP address. On Capsman I'll define a new bridge, assign the guests ethernet and the guests SSID (slave) to it. Should it work also with local forward?
Thank you!

I'll buy a small 5 gigabit dlink new switch, I suppose there may no problems with new technology..
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: Put a classic unmanaged switch between CAPs

Sun Nov 14, 2021 3:10 pm

1) local forward is enabled by default, it means that when a connecton throug cap-capsman is esablished, the IP packes will be directly placed on bridge and sent by ethernet protocol to the Capsman MAC, which knows how to treath them. Less CPU, no fragmentation, it looks ideal.
In this case for me it is interesting if 2 different caps SSID, placed on 2 different IP domain, will work too.
Local forward means that client data will be treated by CAP device exactly the same as if wireless was configured locally, i.e. without using CAPsMAN. In this case CAPsMAN manager only provisions wireless interface(s).

2) local forward is not set, it means all the packets (probably ethernet ones) should be tunneled by IP to capsman, here or MTU should be increased (how? is it worth?) or fragmentation occours. Also tunnelling all will request CPU, and that's not a good news especially for capsman managing different caps. Is this useful only whn capsman is located on another ethernet broadcast domain?
In this case CAP establishes a tunnel to CAPsMAN and forwards all client traffic to CAPsMAN. As with otger PtP tunnels packets with gross size exceeeding net payload of tunnel packets will be fragmented (and re-assembled at other end of tunnel) making tunnel transparent to all involved devices (other than CAP device and CAPsMAN device).

Use cases for CAPsMAN forwarding (i.e. disabled local forwarding) are various, one is the one you mentioned. The other might be possibility to properly separate traffic of different SSIDs (belonging to different subnets) if one can not or doesn't want to bother with VLANs. And surely there are more use cases. When deciding upon whether to use CAPsMAN forwarding one has to keep in mind additional burden placed on CAPsMAN by pushing all the traffic over it.
 
gotsprings
Forum Guru
Forum Guru
Posts: 2087
Joined: Mon May 14, 2012 9:30 pm

Re: Put a classic unmanaged switch between CAPs

Sun Nov 14, 2021 4:37 pm

I gave up on caps forwarding in my first month of testing.

Once I figured out the "serious performance gaps"... I found the sandbox Mikrotik wireless could work in.

Moving on.

During Proof of Concept testing... I set up a cap at home and joined it to the office controller.
First time was via a firewall rule that would have been about the same as port forwarding.
The second test was using a VPN to connect back to the office and setting the cap to connect over the VPN.
Both worked.

Who is online

Users browsing this forum: dinosgb, duartev and 34 guests