I am puzzled… I respect the abilities of ROS and am still learning, but I don’t really understand why you would want to run ROS on a Switch when you have SWOS?
Now I have one 24P Switch that runs SWOS and I am getting another 48P Switch that is not capable of running SWOS and thus will be running ROS… because there is no other way, so I guess I better run ROS on my SWOS capable switch as well?
I get that some people want advanced configuration options on switch, well to me they are, currently, only basic forwarding boxes, thus SWOS is enough.
If one can (safely?) assume that switch performance is the same when running either of supported OSes (ROS, SwOS), and one doesn’t need L3 functions, then it boils down to personal preference regarding administrative UI. Some users, very well acquainted to CLI and ROS, will obviously prefer running ROS. Others, not having any affinity towards CLI, or those who don’t use ROS (much), will probably prefer simpler GUI of SwOS.
I’m from the first group and thus possibility to run ROS on a switch is a big benefit.
I will probably run WebFig / (Web)SWOS a lot so while Winbox is damn nice to have I tend to be minimalist, don’t use more resources than needed. I assume it will be ok to run ROS on any ROS capable device but as I will use the switches it just seems like overkill.
I think it’s more than just the UI of the switch or simplicity, in-fact i believe an argument can be made for the simplicity or ROS new bridge implementation, exporting and importing configs allows for easy backups and mass deployments.
ROS also has dot1x which SWOS does not, plus how would you handle authentication on the device? Allow all staff who have access to it to do whatever they want unrestricted? With ROS you can do Radius auth, allow some users read, some read/write. If a staff member leaves, he will leave with your password.
TBH, if this is a home user with 1 switch, sure SWOS may do, but unless you stare at the screen you wouldn’t even know (for example) that a port is flapping, there is no logging.
Here’s my two cents on it. I run my two MT routers strictly as routers, and I have five MT switches that perform all switching function. The switches run SwitchOS (including one CRS326 that was shipped to me in error instead of a CSS326) and the routers of course run RouterOS. I like SwOS for it’s simplicity. I don’t need any of the router functionality in the switches because the routers perform those functions.
Missing the LOG in SwOS, and the ability to set RSTP parameters (path cost, diameter, port type), or L2 bridge parameters like “horizon”
Default diameter for RSTP is 20 in ROS, what is it for SwOS ?
Like a Switch that in our environment only is supposed to forward signal, nothing else. Why would you want a Switch to do the job of a Router? Or be exposed to the same challenges?
A switch is a switch and a switch and a router is a router. Different hardware for different jobs. Yes, you can make a router play switch, but not the other way around.
RouterOS gives you the ability to take advantage of all the features on the switch and a powerful management
In my case i use RouterOS in switches because this features:
Winbox
More Versatile Webfig
RoMON
Tools Graph
Tools Ping
Tools Telnet
MSTP
Full management Using Serial Console when needed
Can configure more users with different profiles
Using RouterOS to manage a switch using it as a Switch, not even thing to use a Switch as a router please dont
Off course RouterOS 7 supports Layer 3 switching but that’s a specific use case, do not replace common router
Actually, a ‘common router’ (IPv4 routing and little else) is exactly what it does replace. Depending on the ASIC, it can even do firewalling and NAT in hardware.
Pretty much everything your run-of-the-mill router needs to do. IPv6? Nope, not (yet). Anything more esoteric is off the table as well.
Your CSS326 can do IGMP snooping, but it can’t establish an IGMP querier, so if long-running multicast streams are started and then abandoned, how do they get shut down? Answer: they don’t, they just keep pouring into the port that once upon a time requested them, arbitrarily long ago. Not all multicast protocols have this sort of indefinite duration, but there are some, such as in many IPTV systems. A lot of autoconfiguration type protocols have this, too, constantly sending out some sort of update message. These streams shouldn’t keep going out to ports that no longer have a host trying to receive them.
RouterOS also offers several VPN options, including the uncommonly easy to setup WireGuard in the v7 beta. There is no VPN option in SwOS, so you’re relegated to handling that some other way. I see from your signature that you have a separate MikroTik router, but not everyone has that luxury. If they have whatever their ISP provided, or if the ISP modem’s “VPN” feature is simply terrible, or if they have a third-party non-MikroTik router without a VPN feature, port-forwarding VPN packets to the switch is a viable alternative.
SwOS has no firewalling capability whatsoever. “Okay,” you say, “but I already have a firewall.” And I tell you that yeah, I see that in your signature, but it’s affecting the whole LAN. How do you use it to say something like “nothing down this leg of the LAN gets Facebook”? For that, you either need per-port firewalls, or you’re going to have to promote knowledge of leaf MACs clear up to the border gateway router.
A similar case is DHCP. By running that on the switch, you can tie it to a port or a VLAN. And why would you want to do that when you have a perfectly-good DHCP server already, you ask? Because you might have certain clients with special needs. For years, I ran a second DHCP server to feed a bunch of strange little hardware boxes that needed the “next server” DHCP option, which none of the common “Internet gateway” type DHCP servers provide. RouterOS’s DHCP server allows me to do that, scoping it to just the devices that need it so the two DHCP servers don’t fight each other.