Hello all. I'm looking at the block diagram for the rb5009 boards. I see all ports are behind the 88E6393X switch chip at 10G, so CPU routing on this platform is going to be limited to 5G FDX or 10G Aggregate since data has to pass in and out that 10G FDX interface to the CPU.

The obvious fix here is hardware accelleration that keeps it in the switch. However, I've dug through the help.mikrotik area and I can't find an actual reference to hardware accellerated routing. I can enable fasttrack in the firewall but I don't see any reference to that so I'm not sure if it's actually doing it.

What's got me confused is that I don't have any 'H' on my active routes but it shows up in the red/inactive routes . Not sure if that's just a bug/anomoly or what.

I do see hardware accell on this switch in the hardware matrix, including support for VLANs.

My goal here is to use an rb5009 connected to an upstream switch and handling VLANs. (Tachyon 2.5G PoE switch, router on a stick design) and then the ethernet ports on the 5009 for local access in an MDU style deployment. Also, I want to keep what routing I can off the CPU because I may want to do some firewalling or shaping on the CPU. Site(s) would be passing traffic from other sites as well.

Anyone clarify this for me?

(I would prefer to not use the tachyon but I have little choice for 2.5G ports from mikrotik

I do see hardware accell on this switch in the hardware matrix, including support for VLANs.

What you see is L2 HW offload (VLAN switching). What you're asking about is L3HW offload which (AFAIK) is not supported (yet?) on RB5009. So no, RB5009 can't perform full speed routing, it peaks at around 3Gbps give or take (depending on exact configuration).

I don't care which method, I just want the switch doing the heavy lifting. Whether that's l3hw offload or a fasttrack, I'll take either.

As others have explained, RB5009 switch chip fully supports L2 offloading for VLANs and IGMP/DHCP snooping in HW. (aka L2hw).

For routing, there is no HW support (aka L3hw). Fasttrack bypasses parts of ROS. Data is directly passed in low level SW. This is still CPU based, but with less load. Fasttrack bypasses firewalling/mangling/queuing/policies and hence should only be applied to traffic not needing any of these.

The RB5009 has a quite powerful CPU. With usual firewalling, it should be able to route 2.5GBit/s without bottleknecking in the CPU. I suggest to give this a try before resorting to fasttrack if required.

As others have explained, RB5009 switch chip fully supports L2 offloading for VLANs and IGMP/DHCP snooping in HW. (aka L2hw).

For routing, there is no HW support (aka L3hw). Fasttrack bypasses parts of ROS. Data is directly passed in low level SW. This is still CPU based, but with less load. Fasttrack bypasses firewalling/mangling/queuing/policies and hence should only be applied to traffic not needing any of these.

The RB5009 has a quite powerful CPU. With usual firewalling, it should be able to route 2.5GBit/s without bottleknecking in the CPU. I suggest to give this a try before resorting to fasttrack if required.

You missed the point. As soon as I put other duties, specifically shaping, on the CPU it's no longer 2.5Gbps capable and then some customers are geting stuck behind the CPU for a customer's shaper. I have done this, it's not adequate for the task in these conditions so I'd have to add additional hardware to both route the network and shape the prem.

Your main point in the first paragraph or your OP seemed to be a concern that the 10Gb link would be a bottleneck.

I see all ports are behind the 88E6393X switch chip at 10G, so CPU routing on this platform is going to be limited to 5G FDX or 10G Aggregate since data has to pass in and out that 10G FDX interface to the CPU.

If 10G aggregate is the actual bottleneck for your traffic, then the RB5009 isn't the best router for your traffic. But is this really a valid concern? My guess is that there will be some other limiting factor in most real world traffic cases.

My goal here is to use an rb5009 connected to an upstream switch and handling VLANs. (Tachyon 2.5G PoE switch, router on a stick design) and then the ethernet ports on the 5009 for local access in an MDU style deployment. Also, I want to keep what routing I can off the CPU because I may want to do some firewalling or shaping on the CPU. Site(s) would be passing traffic from other sites as well.

For the next question let's assume that the 88E6393X supports L3 hw assisted routing (the 88E6393X product brief suggests it does), and that ROS supported this feature on the 88E6393X (as far as I know it does not).

Given the above assumptions, (e.g. L3 acceleration support for 88E6393X switch), can you explain how it would be possible to offload the routing to switch hardware and then have the CPU do firewalling or shaping? Wouldn't the fact that the routing is being done off the CPU prevent the CPU from even seeing the traffic?

The rb5009's CPU cannot push 1G through 'untouched' and simultaneously push 1G shaped. The CPU maxes out and the 'untouched' throughput drops well under.

This is the real bottleneck, trying to handle ~5Gbps FDX peak with an occupied CPU. if I don't have the customers on the CPU, then it'd do it.

The core 'issue' here is that I'm wanting to have a single router at these sites instead of multiples and by forcing traffic through the CPU the other duties there remove the 5Gbps option and make it more like 1-1.5Gbps. The CPU can do about 10Gbps fastpathed, but half that for firewall rules and when you put a shaper in there it's about 1.5Gbps. While the CPU is pegged from the shaper, there's nothing left for the other routing.

And for the shaping vs not, I only want to shape traffic hanging off a couple of the 1G ports (not all) to on-prem customers, anything flying past the site doesn't need touched.

ie, if I could keep the packets that flow by in the switch chip then I wouldn't have the issues with the CPU, the 5Gbps 'bottleneck' there, or the CPU crunch there.

basically, ignore most of the bottleneck bits and focus on the CPU being the bottleneck while shaping.

The bottom line is that queuing on MT devices is AFAIK always done by CPU, hence L3HW offload will not help (because in this case, queuing wouldn't work at all). Shaping is a bit different beast, it could be done by switch chip (some switch chip models used in 'tiks support that feature), but it's done on L2. I've no idea whether this fits the bill fir you or not.

But as noted, if you want to do fancy stuff at multi-gig speeds, then you need something much more powerful than a (decent) home router (RB5009 is a SOHO device, not a corporate beast ... and no, your personal opinion doesn't matter).

The bottom line is that queuing on MT devices is AFAIK always done by CPU, hence L3HW offload will not help (because in this case, queuing wouldn't work at all). Shaping is a bit different beast, it could be done by switch chip (some switch chip models used in 'tiks support that feature), but it's done on L2. I've no idea whether this fits the bill fir you or not.

But as noted, if you want to do fancy stuff at multi-gig speeds, then you need something much more powerful than a (decent) home router (RB5009 is a SOHO device, not a corporate beast ... and no, your personal opinion doesn't matter).

I just described the scenario where some data is shaped and some is not. The shaped obviously lives on the CPU, but the unshaped flows should be in hardware routing. This is functional on other marvell platform devices, the rb5009 seems to be the lone device that has a capable marvell switch that doesn't seem to have a hardware routing option in routeros.

the rb5009 seems to be the lone device that has a capable marvell switch that doesn't seem to have a hardware routing option in routeros.

The 88E6393X chip is part of the LinkStreet familiy which is much simpler (and cheaper and cooler) than the Prestera Familiy used in CRS devices. Presteras have 16'000 to 128'000 fdb entries for HW routing.
88E6393X has only 256 entries for HW routing and ACLs combined. While this could be supported in ROS and would be better than nothing, it would probably be to limited for use cases like yours.