Disabled STP is not fully transparent to RSTP (maybe)

Hi,

We have a fresh link made on RB333 with 3.0RC13 which should serve as a redundant link to another (made on 2.9.x MT). There are cisco switches on both sides and we use RTSP all worked fine until we replaced one old redundant link with the RB333 one. After the new link was connected a nice packet storm occured. It looks like the cisco switches didn’t receive RSTP PDUs through the new link so they didn’t break the bridge loop. I enabled RSTP on the MTs and it works now - but I would prefer to have the link fully transparent and leave the ciscos to decide which link to stop (less amount of devices to care about when configuring the STP and I am not sure I can easily detect the link state via SNMP on MT)

The setting is simple - EoIP tunnel made on the wlan interfaces and ethernet bridged with the tunnel. The same settings we use on 2.9.x in many times without problems with RSTP. Is this a known problem (a bug in ROS).

Hi,

I did another test with 3.0rc13:

  1. let's have a cisco switch with RTSP enabled
  2. RB333 ether2 connected to a cisco switch's port 2
  3. RB333 ether3 connected to the same cisco switch but port 3
  4. put the RB333 ether2 and ether3 to the same bridge (STP/RSTP not enabled - left in default mode)
  5. create a vlan2000 on cisco
  6. switch the ports on cisco to access mode and put them into vlan2000
  7. see what happens:

the switch doesn't recognize the loop so the 3.0rc13 is definitely eating the STP PDUs sent by cisco ports

#sh span vlan 2000
...
Interface Role Sts Cost Prio.Nbr Type


Fa0/2 Desg FWD 19 128.2 P2p
Fa0/3 Desg FWD 19 128.3 P2p

  • i.e. both switch ports are forwarding (one should have in backup mode = not firwarding)

#sh int summ

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

  • FastEthernet0/2 0 0 0 0 1626000 1922 2681000 3150 0
  • FastEthernet0/3 0 0 0 0 2681000 3147 1636000 1932 0
  • i.e 3000+pkt/s (and the number is rising) circulating through the loop


    Regards
    D. Toman

Hi,

FYI: I have just received a notice from Mikrotik support that the problem will be solved in next ROS release.

Regards
D. Toman