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

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

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

I see that L3 hardware offloading is supported only on the CRS317.

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:

Code: Select all

[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:C ... 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:C ... _.28ACL.29

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

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

Ah, cool! Me too want have it

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.

IMO Hardware offloading requirement for Routers:

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.

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.

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.

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.