The MikroTik CRS418-8P-8G-2S+RM is a 16-port 1GbE switch with two SFP+ 10G ports. What makes this more interesting, however, is that MikroTik added a decent Qualcomm Arm-CPU to the Marvell Prestera switch chip and then added PoE+ to the device. That means that it can both power downstream devices and act as a router for those on reasonable, but not super-fast connections. Still, what was neat about reviewing this, beyond the hardware, was that we found an interesting performance quirk due to having such a high-end setup.
As a caveat, we also have the MikroTik CRS418-8P-8G-2S+5axQ2axQ-RM, which adds 4×4 MIMO WiFi 6 to the mix, making it an even better all-in-one if you want to add WiFi 6 as well. We went over that in the video, but we will have another review on that one in the future. For many, that will be the better device given the additional WiFi integration. Still, from a feature perspective, they are almost identical save for that difference. We just had to pick one to go first.
Also, if you want to check pricing, here is an Amazon Affiliate link to where you can purchase this switch.
MikroTik CRS418-8P-8G-2S+RM External Hardware Overview
The switch itself is a 1U unit that looks very MikroTik with a white metal rackmount chassis. When we get inside the switch, you will see the purpose of that front vent as it may not be obvious looking at the box.
On the left front, we have sixteen 1GbE ports. I think a lot of our readers would be more interested in this switch if it were a 2.5GbE switch instead. That is probably fair given how many devices are now coming with 2.5GbE. On the other hand, for common PoE/ PoE+ devices like cameras, 100M is still sufficient, so 2.5GbE would add needless expense. It is almost like the market is bifurcating into PoE switches designed for higher-power devices like WiFi 7 APs and lighting, and then lower-power devices like cameras.
The first eight are standard 1GbE ports.
The next eight are PoE+ ports with a total power budget of 150W between them.
We hooked up both the Fluke LinkIQ-Duo (Amazon Affiliate) and the MicroScanner PoE (Amazon Affiliate) to confirm we are getting PoE+ power from the ports. Both showed results as we would expect.
Next, we get two SFP+ ports that are 10Gbps ports. As shown in the block diagram, these are on the switch with the 1GbE ports, which differs from some of other switch designs, where 10GbE ports are off a management processor.
There is also a USB port that can be used for configuration and storage.
Next, there are two more ports. One is the console port and one is a management port.
As a switch, this makes a lot of sense as a 1U box. The WiFi model might seem a bit more unusual, since mounting WiFi in a rack is usually not ideal. We will get to the workaround for that in the WiFi model’s review.
On either side, there are vents.
On the rear, we get fans and power inputs.
There are two AC inputs for the dual internal power supplies. MikroTik has wire retention to keep the power cables secure.
There are four fan vents in the rear as well.
As you might imagine, the switch also comes with rackmount ears.
Next, let us get inside to see how this works.
A few comments about the packet loss:
When testing with an IXIA you need to make sure that you have turned off any features that could cause the switch to generate its own traffic. This means disabling protocols like LLDP, spanning tree, router announcements, etc.
Management packets like LLDP and route announcements are typically sent with highest priority. If traffic is traversing the switch at line rate, then there’s no “idle” time on the egress port. If the switch sends an LLDP packet, then it has to drop (or queue) one of the IXIA-generated packets. This isn’t a failure, it’s the nature of a switched network.
Second, packet loss can also be caused by clock skew (also called “clock offset”). In an asynchronous network like Ethernet, one of the oscillators will always be a few “Parts per Million” (PPM) faster then the other.
The Ethernet standards allow +/- 100ppm of clock offset. This means each piece of equipment has a different view of “line rate”. One again, dropping packets due to PPM differences is not a “failure”, it’s an inherent behavior of an Asynchronous network.
Queuing can mitigate some of these effects, but too much queueing is undesirable.