MikroTik CRS320-8P-8B-4S+RM Management
We are not going to spend a ton of time on the management since MikroTik has a lot of options including a CLI, a web interface, and a WinBox interface (that looks similar to the web interface and you can access the CLI on) shown below.
A cool feature of the CRS320 is that MikroTik has a power cycle button for the switch in the UI. Many of these switches are going to SMBs without dedicated network admins. For them, having a GUI is important since it is more accessible than a CLI. Having the ability to cycle power on a PoE port is important when there are devices that are hard to reach.
MikroTik CRS320-8P-8B-4S+RM Block Diagram
In the block diagram, we can see the Marvell Prestera 98DX226S. This handles all of the ports.
Something to keep in mind is that the link between the 800MHz 32-bit Arm dual core CPU and the main switch chip is only a 1.3Gbps link. As a result, if you are using the CPU for a networking feature, you are automatically going to be limited to 1.3Gbps maximum. Straight port-to-port traffic traverses the switch chip without going through this link.
MikroTik CRS320-8P-8B-4S+RM Performance
Here is a quick look at this in action.
As a note, we missed the management port. We typically hook this up to our management network since it is often a 100M port on other switches, and often goes through the management processor. This was a case where it was not, so we only tested the sixteen 1GbE ports and the four 10GbE ports.
Here are MikroTik’s switching results:
Here are the company’s bridging and routing results:
Of course, the big limitation here is that we are on 1GbE links, not 2.5GbE or faster for most of the ports. Also, the bridging and routing results clearly show the impact of hitting the CPU.
Next, let us get to power consumption.
Still not 2,5Gbe or 5Gbe ethernet port, for new deployement with access point in 2,5Gbe it’s not usefull
How much, if any, control do you have over what ports get priority in the case of loss of one of two power supplies?
Obviously full redundancy is nicer, if you can justify the price; but for a lot of intermediate applications it seems like a relatively low risk of having to shed some of the load could be acceptable; but only if you can control what load gets shed.
If losing a PSU means that everything browns out and then renegotiates a more or less random(or at least unpredictable and uncontrollable) subset of the original devices depending on which ones reboot how quickly and how the chips fall then that makes losing one PSU potentially nearly as bad as just losing the switch(especially if you are taking advantage of Microtik’s taste for POE-powerable switches in the vicinity); but if you can set up a POE config for the lower budget and one for the higher budget and have losing one PSU just move you neatly from one to the other that would be something you could work with; especially given the fairly low failure rate of decent PSUs.