Changing port egress rate causes lockup - CRS328

RouterOS General
1

Hi all,

I’ve recently bought a CRS328-4C-20S-4S+RM with intent to use as a simple access layer switch - dot1q trunk in via one of the SFP+ ports, then client connections out via the SFP ports. Each client has a dedicated VLAN untagged/retagged at their respective port. The switch shipped with RouterOS 6.42.5, I upgraded to 6.43.8 during my testing, without seeing improvement to the issue I suffer from. Of course, I performed the firmware upgrade, too, including multiple reboots.

In my initial testing, I’ve been testing each function with the device running RouterOS, including port INGRESS and EGRESS rate, tagging/untagging VLANs, etc. As my test bench doesn’t have any fibre capabilities at the moment, all testing so far has been using the copper RJ45 ports from the 4 combo port group.

During testing, I discovered that when changing the egress rate for a port (Winbox/Switch/Port) from “” (default, nothing) to anything, the switch behaves as expected (change from default nothing to 200M, traffic drops to 200M as expected) but when I click the little UP arrow to revert to no entry in the field, the switch locks up. This requires a reboot to resolve.

The same behaviour DOES NOT occur when doing this on port INGRESS. I can go from default to 200M (or any other value, it works fine) then back to default and the switch continues to function.

If I set egress rate from default to 200M (again, example rate) then back to 1G, the switch behaves normally - it’s the act of clicking the up arrow to revert the field to default that causes the lockup.

Does anyone else have one of these to test this function with? I haven’t tested this in SwitchOS, as I’d prefer run RouterOS for this application - I feel the SNMP stack in SwitchOS is missing too many tree entries to be deployed in my particular application (from experience with a CSS326).

I have supout files, a full log of my testing, exported configs incase anyone wants to duplicate my setup directly.

2

What happens when you make the same change via the command line?

3

That’s a good point, pcunite - I hadn’t tried that yet.

I tried using the terminal inside of winbox to first set the ingress-rate, then unset the ingress-rate. Much like in GUI, success.
However, using terminal to unset egress-rate causes the same lockup. A few seconds later, traffic ceases, Winbox shows disconnected.
To be clear, I used command:

[admin@Mikrotik] /interface ethernet switch port> unset value-name=egress-rate
numbers: combo2
4

I did some more testing on this today.

I’ve updated all of my test lab devices (2x HexS, 1x RB1100, the CRS328) to 6.43.11 (current stable). Included in this was a firmware update, as usual, plus the reboot associated.

I’ve now also tested the “Safe Mode” feature in conjunction with this issue; setting Safe Mode immediately prior to unsetting the egress-rate. As expected, Safe Mode works perfectly; first I see the switch lock up, Winbox disconnects, I lose connectivity to and through the switch - a few seconds later, Safe Mode rolls back the change; and connectivity is restored.

It seems whatever the lock-up is, it doesn’t actually kill the management processes, but traffic forwarding doesn’t continue.

Has anyone else got one of these to do their own testing with (as case there’s something I’m missing), or should I simply avoid using the egress-rate limit feature?