I’m wanting to run capsman remotely but have the local APs keep the WiFi up even when the connection to capsman is lost. It seems that when capsman disconnects, all the APs go down as soon as they try to connect to capsman again.
Any ideas on how to keep the APs online?
edit: I am using Local Forwarding
What you want is not possible. In CAPsMAN it is manager that always handles client authentication, no matter what forwarding mode is in use. That’s by design.
Kinda kills it as a replacement for unifi. If the path to the device manager goes down for some reason, you really don’t want all the APs to go down. That doesn’t mean the internet is down. Just rebooting the manager for an update shouldn’t kill all the APs connected.
You can have multiple CAPsMAN device manager on the same network. When one is offline, CAPs connects to another one.
while shutting down all the WiFi interfaces and bringing them back up, say 10 seconds of outage for the end user.
This is the ONLY management platform I know of that doesn’t have the option to disable connection monitoring etc so the APs can stay online when the controller is down.
Well not entirely my experience, even with high end professional systems.
It depends what the role of the wlan controller is. Pure management? Mostly not. It is involved in the operation itself, either all data passing through it, or just the control over that data and AAA (authentication, authorization and accounting) of the network.
Therefore the WLAN controller was always double , at least. Either active-passive for the simpeler systems , or active-active for the more advanced. (EG. Fortigate cluster versus FortiAP access points).
And the pendulum central-decentral keeps swinging … https://www.spacewalkers.com/why-distributed-wi-fi-control-is-now-the-right-option/
I’m sure we each have different experiences. Mine are with Cisco, Unifi, Meraki, Ruckus, Aruba. Each of these allows the AP to stay operational when communication to the controller is lost. Some stats are lost, but there is no ‘outage’. If you wanted to argue about Meraki you could, but as long as the controller can be seen once a day all is well.
Mikrotik should, IMO, offer an option for the cAP units to stay in their existing state for x hours if they can’t reach a capsman.
While I understand the role Mikrotik decided for their CAPs architecture (active controller instread of passive or hybrid), I will agree that having the whole network go down even for a simple update or reboot of the controller is annoying. This architecture makes the whole wifi network very dependent upon the state of the controller and thus it makes the addition of high-avaiolability mechanisms necessary for any serious deployment. For example, it would be better if the network could operational albeit with reduced functionality, while the “offending” operation (reboot, update, etc) is underway. Or a second controller with automatic state synchronization and seamless (no downtime) failover between the controllers.
Yes uou can. If you are using local (VLAN) offloading of course. Sending the data through a tunnel or VLAN to the WLAN controller is not going to work. Local authentication and authorisation is also no problem (PSK, EAP) if this is not a SCA wifi environment (with one virtual AP distributed over many physical APs). So CAPsMAN with local aurhentication and local offloading should be able to do it. (Work without manager supervision.). Does it ?
It Is very annoying and cant deploy this system in hotels (24x7). I hope MK add this feature soon.
just to reiterate my position a bit here.
I have a substantial network of Unifi APs, approaching 3,000, hosted on just a few cloud controllers. I have some on-prem systems for ubiquiti and manage a few on-prem systems from other vendors as well. Zero of these installations are reliant on perfect uptime/connectivity to the controller.
I’ve been somewhat soured on most of these other vendors and was looking to mikrotik as an option, but in experimenting with CAPsMAN and cAPs this is a 100% deal breaker. This will be a deal-breaker for MANY people, I’d go so far as to say for the majority of people.
I cannot use this product in this state as all. It requires some ability to operate for some short period of time without the controller without disconnecting WiFi clients.
Not sure about the majority, we successfully use CAPsMAN in the office, where 24x7 is not a requirement, so that’s not a deal breaker for us at all. But you are right, in some cases (like hotel installations) this kind of dependency on the controller IS a problem. This is a community forum, however, so your request/complain may remain unnoticed by the actual Mikrotik staff. If you are really looking into using Mikrotik solutions in your installation, I’d suggest you writing to support@ directly. Or, better yet, talk to a local Mikrotik distributor, and ask to forward your request to Mikrotik. Or do both.
Because CAPSMAN allows LF (local forwarded) and NLF (non-local forwarded modes) including mixing of the two it doesn’t make sense to keep CAPSMAN clients up if the controller goes down for systems where NLF is used. Maybe Mikrotik can add it as an option for those who need to implement LF systems only and need to manage 100’s and 1000’s of radios remotely from a single CAPSMAN controller, assuming you want something turnkey.
NLF is really quite powerful, especially on sites where you only need to support WAN speeds and not LAN speeds (like a Windows client needing to use a local SMB server). Having all the traffic run over a central common bridge makes configuration, filtering and control of the network very easy. The multicore devices make this very easy to achieve, especially the RB4011 with it’s SPF+ interface and very capable CPU.
the reason why other vendor can put their controller on the cloud and let the access point run when having loss connection with the controller is because all the wifi functions (like channel selection, authentication, acl filter etc) is done on the access point, the controller function just like probing, query status, and push configuration back to the access point. with this architecture, the access point is running independent and only need a few times to sync with the controller to report status and keep the config up to date.
capsman on the other hand, all wifi functions is running on the capsman, that’s why it requires constant communication between controller and access point.
anyway, if you want to make mikrotik to behave like other vendor (something i called pseudo-controller), actually you can but you have to develop the system by yourself. make a script the access point to report status and push running configuration to your server, and on the server you have to develop application to receive the data from the access point and process it, and also to push back configuration to the access point. make a script on the access point to retrieve the config from server and execute it on the access point. depends on how good you can develop, this can be quite powerful to manage the access point. with this, you now have a cloud controlled mikrotik router, just like other vendors have.
i’ve used this method long before capsman introduced. it’s useful when deploying wifi hotspot on remote area.
Reference manual link or source for this fact…
https://wiki.mikrotik.com/wiki/Manual:CAPsMAN#Radio_Provisioning
Interfaces on CAPsMAN can be static or dynamic. Static interfaces are stored in RouterOS configuration and will persist across reboots. Dynamic interfaces exist only while a particular CAP is connected to CAPsMAN.
Great use for vrrp maybe an example for capsman so it can be implemented