Has anyone else experienced CRS328 lockups? I had my second one tonight. The first time this switch just lost all MGMT connectivity but still passed traffic. Tonight it locked up 100%. No management and no data passed. Winbox neighbors showed nothing.

Six days later I got another lockup.

Generate supout file on your router while it is "locked" over serial console and send it to support@mikrotik.com.

Has anyone else experienced CRS328 lockups? I had my second one tonight. The first time this switch just lost all MGMT connectivity but still passed traffic. Tonight it locked up 100%. No management and no data passed. Winbox neighbors showed nothing.

yes. Same problem. viewtopic.php?f=21&t=143042#p704660
The saved log shows only the disconnection of the external communication. Sometimes the communication between ports in hardware offloading will also be interrupted. The same thing is done by the CRS317 that we have connected with it. Sometimes it happens that the neighbors work only one way.

All series CRS3xx on ARM is bad. CRS328 with incoming 10Gbit is masive droped packets.

Supout I do not have. I do not have a serial cable and there is no time to generate supout on the backbone.

It is at a remote site so it is not likely I'll be able to get a supout when it is locked up.

I'm still seeing lockups on 6.44.1

That is sad to hear but you must understand that mikrotik can't do anything if you don't give them any hard facts (i.e. autosupout)

You actually don't need anyone on site when it happens. You can use typical USB-serial cable and connect it to some other device (does not matter if you leave there another RB or full blown computer) Then, you can use serial terminal in that other device and connect to your locked-out CRS.
I have done this with Cisco ASA 5505 and hAP ac^2 without any issue. If it works between different vendors, it must work within same vendor as well.

I am seeing theme same symptoms on a new CRS328 with an uncomplicated configuration on 6.45.6. I am able to log in via the serial port and it is still running but it looks like the CPU stops talking to any of the network interfaces so ND, MAC Winbox and DHCP clients no longer work. I made some supout.rif files and sent them in so hopefully this bug will get quickly squashed. Even after the event it looks like the switch hardware is still doing what it is configured to do.

I had some VLAN priority rules - they look like the below. At Mikrotik's suggestion I disabled them and now the CPU stays online. The tricky thing was the problem only manifested itself after about 8 hours. I am using VLAN filtering too.

/interface ethernet switch rule
add disabled=yes new-vlan-priority=7 ports=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 switch=switch1 vlan-header=present vlan-id=100
add disabled=yes new-vlan-priority=3 ports=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 switch=switch1 vlan-header=present vlan-id=101
add disabled=yes new-vlan-priority=4 ports=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 switch=switch1 vlan-header=present vlan-id=102

@UpRunTech - thank you for sharing this. We managed to reproduce this locally and it will be fixed soon. Your reported issue was introduced since 6.45beta version, so the current long-term version is not affected.