Time-out problem

Hello.
I have a site that has 4 switches with DAC cables uplinked between them.
SW1 to SW2
SW2 to SW3
SW3 to SW4
SW4 to SW1
Switches models below:
SW1: CRS328-24P-4S+
SW2: CRS328-24P-4S+
SW3: CRS317-1G-16S+RM
SW4: CRS317-1G-16S+RM
They are running swOS mode, no configuration. Just basic setup

  • Set the switch to static IP
  • Set the new admin password
  • Rename the switch name
    The issue:
    The original issue was the SW2 was getting too many time-outs, it was causing other switches to have some time-out too. We removed the SW2 all three switches came back normal.
    We replaced the SW2 with a new one, but now the SW3 is having some time-outs, but it is not affecting other switches to have the same issue (like SW2 before). It is just SW3 has time-outs. We found out if we disconnect any uplink cable SW2 to SW3 or SW3 to SW4, leaving only one uplink on SW3 the time-outs stop.
    We did the following steps below and none of them can stop the time-out, except removing one uplink cable.
    We have replaced the DAC cable
    Swapped the DAC cable with new one
    Changed to a different fiber port on any of the switches
    Do I need to configure something on the uplink ports?
    Any help will be very appreciated, thanks.

You created a classical ethernet ring. Without any further configuration this creates a network loop. ROS default configuration is to have RSTP active and this should detect those loops and disable one of links which should cure the problem … while still keeping the disabled link as backup (to be enabled if any other link fails). Verify that bridge protocol-mode is set to anything but “none”. If you’re have VLANs running over the ring, use MSTP instead.

One can help RSTP to work better by setting values to priority properties … by default the value is set to 0x8000, but if bridges in the loop all have same priority, there’s some contention in selecting root bridge. If you set priority on switches to different values, the bridge with lowest value wins root bridge election. Note that allowed values are 16-bits and have to be multiple of 4096 which translates into 0x1000 … so allowed values are 0x0000, 0x1000, 0x2000, … , 0x8000, …, 0xe000 and 0xf000.