Hi,

I have question about hardware routing with Mikrotik devices. Are there any plans to implements some CAM/TCAMs to Mikrotik devices for hardware routing? Or just expand MPLS accelerated hardware like CRS317?



Regards,
Blažej

ASIC devices are always expensive... There are many in the market and are with high price! Mikrotik is for most of customers and prices are not in that level!

Sure, ASICs are expensive. But CRS317 looks cheap. More switches like this. Some SFP versions, ethernet versions and some combination SFP/ETH as provider core routers.

Maybe I'm doing something wrong but software routing is unable to transfer multicast traffic for IPTV without packet loss. Not extreme problem, but some random loss there is. We need offload and predictable performance.

It's not problem of implementation in SW, the problem is capacity ... CRS series have CPU with low capacity (compared to their switching capacity) which is a fact that many people fail to notice.
Performance is predictable just not very precisely. The problem here is that ROS is hugely versatile and practical capacity very much depends on amount of processing needed to execute all the tasks configured.

My guess is that price-wise combination of CRS3xx switch (or many of them) and CHR/x86 router is a winner ... but you don't get it in a single box. You can get similar capacity in a single box (or a stack), but price tag will probably be 10dB higher.

You should not compare CRS with other manufacturer's "L3 routing switches". Those are completely different things.
CRS is just an L2 switch with a Raspberry-Pi built in to do some routing e.g. for a management network only.
It is not possible to route "production traffic" with a CRS at anywhere near the switching speed.

Instead you could get a router device from MikroTik (RB4011, RB1100, CCR1009) or of course a device from another manufacturer (more expensive, but for a reason).

Of course I don't consider CRS as router. It was example for offload of MPLS. But RB3011/RB4011 and CCR has also unpredictable performance for critical traffic.

MikroTik routers are Linux boxes using "SoC'" (System on a Chip intended for small network applicances), with software routing for comparatively low prices. That is their market niche.
To expand into the hardware routing market they would need to develop new hardware, develop software to use it, and in general improve the system and customer support required to serve the market that expects those features. And of course, as a result, the price of that kind of device would be higher than the current devices, and it could be difficult to compete with brands that have already done such development in the past.
It could always happen, but I would not count on it. At the moment there is a lot to do even in the software solution and we have seen how long it has been postponed.

Routing in hardware is a challenge, especially when taking policy rules, firewall, VRF, QoS and NAT in consideration.

MPLS (and Ethernet as well) is far simpler to do in hardware.

You should not compare CRS with other manufacturer's "L3 routing switches". Those are completely different things.
CRS is just an L2 switch with a Raspberry-Pi built in to do some routing e.g. for a management network only.
It is not possible to route "production traffic" with a CRS at anywhere near the switching speed.

Instead you could get a router device from MikroTik (RB4011, RB1100, CCR1009) or of course a device from another manufacturer (more expensive, but for a reason).

CRS 600MHz are derived from the RB2011.

So it is time to make CRS based on the RB4011.

Even that would be completely incomparable to "L3 routing switches" from other manufacturers!
These operate similar to switching with only little assistance from the processor. Patterns are put into TCAM which match the destination IP field and send the packet to the correct interface similar to what an L2 switch does with the destination MAC address and switchport.
There is usually a single lookup in a routing table by the processor, which then inserts the proper pattern in the TCAM, and other packets to the same destination do not touch the processor.
This is completely different from the CRS concept, which in fact is just a VLAN-capable switch with a router attached to it. A slow router, yes, but replacing it with a faster router still does not make it into an L3 switch.
That would require inserting switch rules into the switch hardware depending on the actual traffic. Possibly doable, given that you can manually insert switch rules that match on destination IP and then redirect the packet to a specific port, but it is unclear if the hardware would also be able to decrease TTL and recalculate header checksum after that, and how realistic it is to use in a real L3 routing situation. The limited number of rules would mean it can only be used to handle the top of traffic volume anyway.

I am not interested in better CRS switching, but better routing.

I am not interested in better CRS switching, but better routing.

Which takes more expensive silicon. MT don't need te develop it themselves, there is merchant silicon like Broadcom Qumran-UX available, which would make a dandy 'CRS426' full L3 switch, but that stuff isn't cheap. At least not compared to the Marvell PresteraDXes they are using now.

10G L2 switching is cheap. Real 10G routing (read 'wirespeed or close on all available ports') is not. Yet.

There is an important point the OP is asking about that is not being addressed. The marvell prestera ASIC that is in the CRS317 and CRS309 is capable of routing in hardware (not the CPU).

The question he is asking is if MIkroTik is considering enabling that functionality (which already exists in the chip) in RouterOS.

Here is the overview of the capabilities of the 98DX8216 ASIC
https://www.marvell.com/content/dam/mar ... 014-04.pdf

The question he is asking is if MIkroTik is considering enabling that functionality (which already exists in the chip) in RouterOS.

My point (explained above) is that such things are not a matter of "enabling that functionality", which you could read as "set some bit during init, maybe load some routing table in the chip".
It is more likely that this requires more complicated interaction where the chip sends an interrupt to the CPU on the first packet it receives for some new destination, then expects the CPU to program some match rule to handle packets for that destination, then the chip can route packets for that destination by itself until the rule is removed in some housekeeping job.
But that means the whole routing functionality currently being done by Linux will have to be connected to that chip interaction, and of course it is more complicated than looking up the destination IP in a routing table, as they may be policy routing with multiple routing tables and selection rules.
So this is not something that can be programmed on a rainy afternoon.

I completely get that it's not trivial. I spend a lot of time consulting in disaggregated networks where we deploy IP Infusion or Cumulus Linux on ONIE switches and sometimes we have to contend with issues in getting the FIB pushed down into the ASIC.

My point is that it's possible in software and the hardware is already capable - this particular board was designed for L2/L3/L4 forwarding if you read the specs. There would be a huge benefit in the development time spent on this IMO

I am not interested in better CRS switching, but better routing.

Which takes more expensive silicon. MT don't need te develop it themselves, there is merchant silicon like Broadcom Qumran-UX available, which would make a dandy 'CRS426' full L3 switch, but that stuff isn't cheap. At least not compared to the Marvell PresteraDXes they are using now.

10G L2 switching is cheap. Real 10G routing (read 'wirespeed or close on all available ports') is not. Yet.

I am not asking for wirespeed routing, just that they leverage what they already developed.

To take advantage of full HW-L3 features on chip you basically have to re-implent a big part of the IP-stack. This is probably fine when making a hardware customized platform, but problematic when you are trying to be generic and have a broad compability in general.

However, I think that RouterOS could in theory use some HW-L3 features in specific cases, but with a very reduced number of features (just plain forwarding, no queues, filters, rules, vrf, nat and such) by basically transfer the system FIB down to the chip. But personally I think MPLS in HW is a wiser choice since it's based on the system routing table and much less logic involved.

The CRS could route faster just by having the same CPU as the RB4011 similarly to what has been done before, that is the point.

The CRS could route faster just by having the same CPU as the RB4011 similarly to what has been done before, that is the point.

As you can see in the block diagram posted above, the CPU is not a distinct chip that you can replace with a faster one, it is an integral part of the switching chip used.
It has limited performance because it was intended to be used mainly for management and monitoring, not for routing.

The CRS could route faster just by having the same CPU as the RB4011 similarly to what has been done before, that is the point.

As you can see in the block diagram posted above, the CPU is not a distinct chip that you can replace with a faster one, it is an integral part of the switching chip used.
It has limited performance because it was intended to be used mainly for management and monitoring, not for routing.

But new models could route faster if they were a RB4011 with different switch chip.

It looks like my idea was implemented in v7.0beta7. Thumb up! I'm excited to check it out.