hardware offload on other Marvell DX switches?

RouterOS RouterOS beta
1

I see that L3 hardware offloading is supported only on the CRS317. I’m wondering, is this simply because that’s the chosen test-bed for this in ros7? I’m looking at some other devices (Netpower 16P big time) that also have the 98DX series chip in them. Hoping all DX based devices see the hardware offlloading.

2

Yes, I’m also looking forward to L3 offloading coming to the other PresteraDX boxes; I have a CRS309 and a CRS305 I’d like to give a boost…

3

But isn't HW Offloading already present at least on all CRS3xx devices? My CRS326 and CRS305 do have it already (both use the Marvell 98dx3236 SoC):
For example CRS305 with old software:

[admin2@CRS305] /system routerboard print
routerboard: yes
model: CRS305-1G-4S+
serial-number: XXXXXX
firmware-type: dx3230L
factory-firmware: 6.45.8
current-firmware: 6.45.8
upgrade-firmware: 6.44.6

[admin2@CRS305] /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload

INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON

0 XI ;;; defconf
ether1 bridge 1 0x80 10 10 none
1 I H ;;; defconf
sfp-sfpplus1 bridge yes 1 0x80 10 10 none
2 I H ;;; defconf
sfp-sfpplus2 bridge yes 1 0x80 10 10 none
3 I H ;;; defconf
sfp-sfpplus3 bridge yes 1 0x80 10 10 none
4 I H ;;; defconf
sfp-sfpplus4 bridge yes 1 0x80 10 10 none

>

Ie. the "H" means HW Offloading.
Haven't done any SW upgrade yet on this device.

See also https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#L3_Hardware_Offloading

Update: Oops, sorry, you mean "L3 HW Offloading", I was thinking of basic HW Offloading.

Btw. what is missing in HW Offloading is accessing the TCP flags via ACL, for example the SYN flag, as can be seen here:
https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#Switch_Rules_.28ACL.29
4

For L2 switching, yes. What the CRS317 can now do is L3 offloading: hardware-assisted routing. It makes the CRS317 twice as fast at IP routing (within its limits) as a CCR1072 is.

5

Ah, cool! Me too want have it :slight_smile:

6

IMO Hardware offloading requirement for Routers:
1 - Static Routing
2- Traffic-Flow (Netflow) since BGP Flowspec is currently being implemented in ROS7, we need the traffic-flow functionality to be Hardware accelerated to complete the DDOS Mitigation Stack. Currently traffic-flow consumes all the CPU resources under a DDOS attack and halts any Mikrotik Router.
3- Simple Firewall Filters drop rules ( simple drop rules based on src-dst address or port)
4- Static NAT

Sflow might also be a good option instead of Traffic-Flow, if the switch chips supports it.

7

You mean requirements that you put on the implementation of L3 offloading before you are going to use it?

Static routing is not a requirement. Most L3 switches implement autorouting algorithms like RIP or even BGP. I think RouterOS will do that as well.
Of course, when the autorouting protocol frequently changes the routes, there will be frequent CPU spikes to reload tables and possibly even temporary packet loss for every routing change while the hardware tables are being updated again. But in a relatively static situation (an internal network, not the internet) this should not occur so often.

There are limitations on what the offloading can do, these are set by the capabilities of the hardware. Firewall rules could be possible, especially stateless ones (no “established” but direct matches of header fields). NAT and other stateful firewalling is normally impossible, although of course anything could be done with hardware when you are persistent enough and have enough chip real estate to burn.

8

Any clue if ipv6 can be supported later? I would like to run 317s as customer edges rather than 2004s, but ipv6 needs to work offloaded at least at some point.

9

Technically, IPv6 can be supported by 317’s switch chips. How hard is to implement IPv6 offloading in ROS and when it gets done still in an open question.