Community discussions

MikroTik App
 
woro
Member Candidate
Member Candidate
Topic Author
Posts: 104
Joined: Sun May 24, 2015 12:47 am

capsman local forwarding clarification

Sun Sep 05, 2021 6:47 pm

I used to use CAPsMAN with central forwarding for a while to allow better roaming within my house (just 3 access points). A while ago I was thinking to optimize a bit and switch to local forwarding as the wire to my CAPsMAN is a potential bottleneck with traffic going back and forth at the same wire anyway.
At the time I forgot that I did not do it in the beginning most likely because I was scared about disruptions of network during roaming events.
Even after searching the web and forum a bit I'm still unsure.
Therefore the question:
Is CAPsMAN local forwarding causing potential issues when roaming for the case the client stays in the same DHCP subnet as well as the 3 APs being connected via a pretty normal hardware switch?
 
ConnyMercier
Forum Veteran
Forum Veteran
Posts: 723
Joined: Tue Dec 17, 2019 1:08 pm

Re: capsman local forwarding clarification

Sun Sep 05, 2021 7:01 pm

roaming shouldn't be an issue ...
Just make sure, all your AP's have access to the Wifi-Client-Network/subnet
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: capsman local forwarding clarification

Sun Sep 05, 2021 7:03 pm

CAPsMAN does not influence roaming of clients at all ... if APs forming same wireless network are also members of same wired broadcast domain (e.g. same DHCP serves requests made via all APs), then the roaming performance will be just the same with central forwarding and with local forwarding (or without CAPsMAN).
You nay want to check the bridge mode settings on APs though ... either set mode=none or set wireless ports (members of bridges) to edge=yes if bridge mode is set to anything else than none. The rationale: by default wireless interface without any registered client becomes inactive. When a client connects, wireless interface transitions to active. At this moment bridge with any xSTP mode enabled enters discovery mode (checking if newly active interface causes a loop in network) and during discovery phase it's blocking all traffic. It takes seconds (with original STP mode it takes tens of seconds) before port is enabled ... which affects mobility pretty much. The problem is differently addressed with CAPsMAN central forwarding as every CAP uses a port in bridge on CAPsMAN device, local settings on CAPs are ignored.
 
woro
Member Candidate
Member Candidate
Topic Author
Posts: 104
Joined: Sun May 24, 2015 12:47 am

Re: capsman local forwarding clarification

Sun Sep 05, 2021 8:35 pm

Thanks for the explanation!

Probably let me tell some context why I though there could be issues because I actually saw some.

I had local forwarding running for a while but faced issues (maybe STP related or not that is not clear right now) so I decided to switch to capsman forwarding again to see if the issues are gone.
The problem is that switching the datapath seems to totally "break" my wifi network and I apparently do not understand enough why.
The baseline issue which is happening immediately is that the CAP do not have a reliable connection to the manager anymore.
They sometimes connect but run into "CAP sent max keepalives without response" or they cannot even connect with "failed: timeout".
I find no other useful errors in the log but on the capsman I see:
"ether3-Office: bridge port received packet with own address as source address (cc:2d:e0:c2:cf:8e), probably loop"
The mac is the bridge on one of the caps and it is wired in the end with ether3-Office. But I'm not sure what the message really wants to tell me and if that is related to my capsman connection issues.

Any help would be appreciated.

Thanks,
Wolfgang
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: capsman local forwarding clarification

Sun Sep 05, 2021 9:01 pm

I'll just write this: if you're sure there can not be any loops in your network (these are almost every time due to wired connections), then try to set "mode=none" on all bridges on all MT devices. Or, alternatively, set it on the device which is complaining ... and observe performance.

Whenever network topology changes, and switching from central forwarding to local forwarding is a change in topology, it is possible to see transient misbehaviour due to some ARP caches containing now obsolete entries etc. which should fade away in few minutes.
 
woro
Member Candidate
Member Candidate
Topic Author
Posts: 104
Joined: Sun May 24, 2015 12:47 am

Re: capsman local forwarding clarification

Sun Sep 05, 2021 9:36 pm

Whenever network topology changes, and switching from central forwarding to local forwarding is a change in topology, it is possible to see transient misbehaviour due to some ARP caches containing now obsolete entries etc. which should fade away in few minutes.
Yes, that's actually what I would have expected. But even rebooting the MT devices and the Netgear switch inbetween was not enough to fix this (and this was already more than an hour after the switch to capsman forwarding). I switched back to local forwarding for the moment which recovered the issue immediately.
I will try again at some point and try to hunt it down.
 
woro
Member Candidate
Member Candidate
Topic Author
Posts: 104
Joined: Sun May 24, 2015 12:47 am

Re: capsman local forwarding clarification

Tue Sep 28, 2021 11:26 pm

I think I found the issue finally for my detected "loop" when switching from local to capsman forwarding.

On the CAP I have the wireless devices connected to a local bridge (which also has wired devices).
When I switch to capsman forwarding the devices get some sort of inactive on that bridge and the MAC of the two radios are pulled ino the capsman device.
The problem is that the local bridge on the CAP still carried the MAC address of one of the radios. Therefore I had the same MAC on the two devices.

If you ask me that is a bug in ROS because the bridge must not keep the MAC address if it was taken from a now inactive interface but should choose another one from the active interface list?
Worth to report to support?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: capsman local forwarding clarification

Tue Sep 28, 2021 11:39 pm

If you ask me that is a bug in ROS because the bridge must not keep the MAC address if it was taken from a now inactive interface but should choose another one from the active interface list?

Indeed bridge should be selecting another MAC if "donor" interface is removed from bridge. Unless bridge MAC address was set manually (auto-mac=off and admin-mac set), in this case bridge should not change MAC (but setting MAC manually to globally-administered one is administrator's mistake if not error). So if bridge MAC settings are set to automatic, then I think it's worth reporting it as a bug. Create supout.rif files both before switching to capsman forwarding and after.

Who is online

Users browsing this forum: 0xsepa, Google [Bot], jaclaz, Kanzler and 33 guests