Switch Rules working without HW on interface?

[Seko777]

Hardware:

Tested on CRS310-8G+2S+IN and CRS326-24G-2S++RM

Software:

Tested on RoS 6 and 7 (last versions)

Hi folks,

I´ve been playing around with Switch Chip features, and to my best understanding once you have disabled Hardware Offloading any settings from Switch menu should not work anymore, since all the work is now supposed to be done by CPU instead the Switch Chip.

But Switch Rules are working, even with hw=no.

Am I mising something here? Can someone explain the logic behind this behavior?

Thanks in advance.

[tdw]

The physical ports on the device are wired to the switch chip so packets will always pass through and be processed by the switch. The underlying architecture has a single interface beween the switch chip and CPU - the ether1..etherX interfaces shown in winbox/CLI are logical interfaces, the driver multiplexes these using vendor proprietary headers in the packets between CPU and switch.

When hardware offloading is disabled the switch is using port-based VLANs which is completely hidden, a packet arriving on ether3 would be sent to the CPU with the additional header containing the physical port ID, the driver removes this and presents the remainder of the packet on the logical ether3 interface.

[Seko777]

The physical ports on the device are wired to the switch chip so packets will always pass through and be processed by the switch. The underlying architecture has a single interface beween the switch chip and CPU - the ether1..etherX interfaces shown in winbox/CLI are logical interfaces, the driver multiplexes these using vendor proprietary headers in the packets between CPU and switch.

When hardware offloading is disabled the switch is using port-based VLANs which is completely hidden, a packet arriving on ether3 would be sent to the CPU with the additional header containing the physical port ID, the driver removes this and presents the remainder of the packet on the logical ether3 interface.

Agree tdw, but in this case, “some” features on the Switch Chip will need hw=yes to work, and others don’t.

For example: Port Isolation is something that does not work if hw=no.

But ACL does, with or without VLAN Filtering active on the bridge.

Seems pretty unclear for me.

[tdw]

I would imagine rules are processed before switching, but wouldn’t imagine port isolation would apply unless the ports are being switched in the chip - with hw=no the packet flow would be etherA > CPU interface > software bridge > switch chip interface > etherB, it isn’t passing directly between etherA and etherB in the switching section of the switch chip.

A diagram and/or description of packet processing in the switch chip would be nice, but given the silicon vendors think this is secret and only release data under NDA I doubt it will happen.

[mkx]

Agree tdw, but in this case, “some” features on the Switch Chip will need hw=yes to work, and others don’t.

Settings under /interface/bridge and /interface/ethernet/switch are 99% unrelated. What hw=yes does is to (try to) program switch chip to do some tasks instead of bridge. If you configure things in both menus, then in best case things will work nicely according to union of both setups. In worst case, however, settings will collide in the most myterious ways.

[Apachez]

The physical ports on the device are wired to the switch chip so packets will always pass through and be processed by the switch. The underlying architecture has a single interface beween the switch chip and CPU - the ether1..etherX interfaces shown in winbox/CLI are logical interfaces, the driver multiplexes these using vendor proprietary headers in the packets between CPU and switch.

When hardware offloading is disabled the switch is using port-based VLANs which is completely hidden, a packet arriving on ether3 would be sent to the CPU with the additional header containing the physical port ID, the driver removes this and presents the remainder of the packet on the logical ether3 interface.

Agree tdw, but in this case, “some” features on the Switch Chip will need hw=yes to work, and others don’t.

For example: Port Isolation is something that does not work if hw=no.

But ACL does, with or without VLAN Filtering active on the bridge.

Seems pretty unclear for me.

I think unfortunately the RouterOS is all over the place when you have experience from other NOSes such as Cisco IOS, Arista EOS, Juniper JUNOS etc.

Just the thing how vlans are setup through the bridge configuration and this differs between CRS1xx, CRS2xx and CRS3xx is just a shitty move by Mikrotik.

Personally I think they should switch the syntax so it becomes universal similar to how you setup vlans on lets say a Arista EOS so the broken bridge syntax by Linux kernel will be hidden.

It turns for exampel out that you must have l3hw-offloading=off for the switchchip when doing MLAG (why?) but the L2 offloading (regular switching) will still work as long as you configured the bridge correctly with its ports.