I had an interesting discussion with a colleague about how to handle the configuration if multiple RouterOS devices are used. We couldn't find a definite answer.
Let's say we have a network with multiple RouterOS devices, like a core router, some switches, and some WLAN APs.
The question is, where would you configure things, because with RouterOS, even a WLAN AP has some serious routing capacities. The scenario is a business inside a building or on a campus.
My approach would be keeping the complete configuration, firewalls, NAT, etc., centralized on the core switch as much as possible. The switches and WLAN APs would primarily do VLAN tagging. My argument is this configuration ensures that the configuration overall is consistent and clear - and the performance is the best because a core router is built for this. Even if this means higher network traffic. I think it's hard to map/document all the unique configurations for each switch and WLAN AP. Basically, I would primarily use the RouterOS switches like I would use SwOS. I don't think that resilience is an issue here, because if a core switch is going offline, a business can't work anymore, because the servers and internet are usually connected to the core switch. The usability of a locally still active network is very limited.
My colleague thinks that routing between devices, which are connected to the same device, e.g., a switch, should be done locally. It avoids unnecessary traffic in the up-/downstream of the switch. The scope of the configuration is smaller and more clearly laid out. This can reduce mistakes. The core switch has more capacity to do the heavy centralized stuff because small things are offloaded externally. The resilience is higher because if the core switch is going offline, the users still can use the network to a certain capacity locally.
I think both standpoints are valid and have their advantages and disadvantages. What do you think is the best approach here?
In at least the last decade your version, i.e. shipping all traffic to a core router has become the common setup. Then the traffic is handled via virtual interfaces, which for smaller installations usually meand vlans.
If you have any sort of size to your setup, consider only a proper router for the core, which means from the rb5009 or ccr2004 up.
Routing on routers, switching on switches (I keep the switches as simple as possible), WiFi config via CapsMan from the core router or ??? and VLANs as needed. (I tend to NOT tag ports with a single VLAN, but rather set the PVID accordingly, and mainly VLAN backbone/trunks. Again, K.I.S.S.)
Thank you for your answers!
I think I have to make it clearer what I am talking about.
With other networking equipment than MikroTik, this question wouldn't even come up. Usually a WLAN AP or switch doesn't have any routing capabilities. But because MikroTik is using RouterOS for WLAN APs and switches, this question comes up. I know that a lot of people here don't like SwOS, but I think it's the right step in the right direction. The next consequent step would be a WifiOS.
I have no issue with ROS on wireless and switch devices . . . just because features are there doesn't mean that you need to use them (and if a wireless device is used standalone, the routing features have merit.) There is benefit to a consistent platform wide UI, after all.
I do acknowledge the massive excess complexity, though, and not that I use SwOS on switches when available. I lost nothing that I need, and prefer the simplicity and smaller footprint. (I've tried both . . )
"Smarten up the users, don't dumb down the product" is a statememt that I think applies here . . .
I think it really depends on the size and complexity of the network, but in most business environments I'd lean toward your approach.
Keeping routing, firewall policies, NAT, and most Layer 3 configuration centralized on the core router makes the network much easier to manage and troubleshoot. The access switches and APs can then focus on VLANs and switching, which keeps their configurations relatively simple and consistent.
That said, there are cases where local routing makes sense—especially if there's significant traffic between VLANs on the same switch or if reducing latency and uplink utilization is a priority. The trade-off is added complexity, since you're now managing Layer 3 policies across multiple devices.
For a typical office or campus deployment, I'd generally prefer centralized routing unless there's a clear performance or resilience requirement that justifies distributing the Layer 3 functionality.