MikroTik CRS418-8P-8G-2S+RM Review An All-in-One PoE Switch and Router

1

MikroTik CRS418-8P-8G-2S-RM Performance

We found something really interesting. To test this, we are using a single Keysight XGS2 with a NOVUS 1/10G dual PHY card. We also upgraded our IxNetwork 11 revision to IxNetwork 26 this year (26 for 2026.) One of the advantages of using a high-end FPGA-based tester is that we can generate not just 64B packets at line rate and over 1.6Tbps on our setup, but we can also get solid metrics on latency and jitter. We are using the RFC2544 Quick Test template and adding extra time per step, along with some additional IMIX variants, to provide more data. Starting with the 64B line rate test, here is what we saw:

MikroTik CRS418 8P 8G 2S RM 64B 100 Line Rate Loss
MikroTik CRS418 8P 8G 2S RM 64B 100 Line Rate Loss

Did you catch it? At 64B running at full 100% line rate, we saw 3,185 of 1,607,142,854 frames get lost. Sure, this is still five nines of completion rate, but there was some loss.

MikroTik CRS418 8P 8G 2S RM 64B 100 Line Rate Loss Flows
MikroTik CRS418 8P 8G 2S RM 64B 100 Line Rate Loss Flows

Since the testing is scaling from 10% load, the last full step was 99.297% of line rate. We tried a few different firmware versions, and generally we were OK up to at least 99.94% line rate, but then sometimes we would see loss after that point.

MikroTik CRS418 8P 8G 2S RM 64B 99.297 Line Rate
MikroTik CRS418 8P 8G 2S RM 64B 99.297 Line Rate

To understand what is going on here, MikroTik tests these with a Teledyne LeCroy XenaBay solution that has a lot of the same functionality as our Keysight (Ixia) XGS2 NOVUS platforms. MikroTik uses a 0.1% tolerance in its testing, which is totally valid as a test methodology. We have access to do the same using IxNetwork, where there is a box even in the Quick Tests to add a tolerance. Also, 0.1% is common in the industry. A key difference is that we do not test with that tolerance. We require the exact number of frames sent to match the number received.

MikroTik CRS418 8P 8G 2S RM Performance Test Tolerance
MikroTik CRS418 8P 8G 2S RM Performance Test Tolerance

We sent our findings to MikroTik, and they were able to reproduce on their XenaBay setup. This was a super neat finding, and not one you will see in the average web review, since it takes six figures in hardware/ software to reproduce accurately.

It is probably worth noting that you are unlikely to experience this in any real-world scenario. Most traffic, especially on PoE+ switches, is not 64B at 100% line rate. Most network admins observing a 16-port 1GbE and 2-port 10GbE switch running all eighteen ports at 64B and 100% line rate, or even 95% line rate, would think that is crazy. Perhaps better to say, what we found was a very unique edge case that most will never run into. Still, we found something that is exciting.

Moving on to our 1518B tests, or really anything over 64B, was less exciting, but we did get quite a bit of jitter at 100% line rate.

MikroTik CRS418 8P 8G 2S RM 1518B 100 Line Rate
MikroTik CRS418 8P 8G 2S RM 1518B 100 Line Rate

We also tried mixed packets using a standard IMIX profile and again, you can see 100% line rate is straining the switch.

MikroTik CRS418 8P 8G 2S RM IMIX 100 Line Rate
MikroTik CRS418 8P 8G 2S RM IMIX 100 Line Rate

Here is the Cisco IMIX profile:

MikroTik CRS418 8P 8G 2S RM Cisco IMIX 100 Line Rate
MikroTik CRS418 8P 8G 2S RM Cisco IMIX 100 Line Rate

Here is the IPSec IMIX profile.

MikroTik CRS418 8P 8G 2S RM IPSec IMIX 100 Line Rate
MikroTik CRS418 8P 8G 2S RM IPSec IMIX 100 Line Rate

Next, we decided to do a simple test. We used our Keysight CyPerf test setup (a different physical machine and software from our IxNetwork setup.) This setup is what we use for our gateway device reviews and is also capable of well over 2Tbps of network throughput. We set the MikroTik into a simple router configuration using one SFP+ port as the WAN and the other SFP+ port as the LAN. Another default option is to use Port 1 as the WAN, but we expected to exceed 1Gbps, so we selected an SFP+ port. Also, from the block diagram we saw there are 10Gbps links to the Qualcomm chip, so it seemed like we needed to be on interfaces with more than 1Gbps of capacity. First up, we tested simple HTTP traffic:

MikroTik CRS418 8P 8G 2S 5axQ2axQ RM CyPerf STH Gateway Max Throughput Test Close
MikroTik CRS418 8P 8G 2S CyPerf STH Gateway Max Throughput Test Close

In terms of raw throughput, we were just over 2.5Gbps. Remember, this is not the L1 traffic counter that we would use for IxNetwork.

MikroTik CRS418 8P 8G 2S 5axQ2axQ RM CyPerf STH Gateway Max PPS
MikroTik CRS418 8P 8G 2S CyPerf STH Gateway Max PPS

We then tried scaling our security profile traffic mix through this, and saw relatively similar levels of performance.

MikroTik CRS418 8P 8G 2S 5axQ2axQ RM CyPerf STH Security Profile Throughput Test
MikroTik CRS418 8P 8G 2S CyPerf STH Security Profile Throughput Test

Just as a quick aside, on the CyPerf testing we saw the same results on the WiFi and non-WiFi CRS418 models.

MikroTik CRS418-8P-8G-2S-RM Power Consumption and Noise

In terms of power, we get two internal power supplies for redundancy.

MikroTik CRS418 8P 8G 2S RM Rear Angled 1
MikroTik CRS418 8P 8G 2S RM Rear Angled 1

At idle, we saw 21W.

MikroTik CRS418 8P 8G 2S RM Idle Power Consumption 1
MikroTik CRS418 8P 8G 2S RM Idle Power Consumption 1

Hooking a single 1GbE port up, we got 21.3W for 0.3W as the incremental power.

MikroTik CRS418 8P 8G 2S RM 1GbE Power Consumption 1
MikroTik CRS418 8P 8G 2S RM 1GbE Power Consumption 1

Using a SFP+ to 10Gbase-T adapter we only saw 1W incremental for 22W total which was great. MikroTik rates the switch at 28W maximum without attachments, then 215W maximum. That 215W includes the 150W PoE budget.

MikroTik CRS418 8P 8G 2S RM 10G SFP+ Power Consumption 1
MikroTik CRS418 8P 8G 2S RM 10G SFP+ Power Consumption 1

The noise was very reasonable. With four fans, they did not seem to be spinning fast, so we were getting 36-38dba in our 34dba noise floor studio.

Final Words

We will let you read the performance section if you missed that, since that was really neat. At the same time, as we went through this switch, we found ourselves wondering questions like “Why not 2.5GbE? Why not PoE++? Why not 16x PoE+ ports?” Since we were doing the WiFi model in parallel, we were wondering about WiFi 7 as well. At some point, if you keep asking for more features then it becomes a different device with a different target market and different cost. I understand this device. If you have, perhaps, a 500Mbps WAN connection, and a bunch of PoE+ cameras, and a few PCs, printers, or other devices that you want to manage, then you can install this, and be ready to go in a smaller installation as an all-in-one. Of course, you could also use it as just a switch.

MikroTik CRS418 8P 8G 2S RM Front Angled 2
MikroTik CRS418 8P 8G 2S RM Front Angled 2

For a PoE+ capable switch with dual 10G SFP+ links, redundant power, and a decent processor, the MikroTik CRS418 family checks a lot of boxes.

Also, as a shameless plug, if you want to learn more about MikroTik and how it builds products like these, see Touring MikroTik in Latvia to See How They Make Awesome Networking Gear.

Where to Buy

Here is an Amazon affiliate link to where you can buy the switch.

1 COMMENT

  1. 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.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.