Community discussions

MikroTik App
 
User avatar
MWComms
just joined
Topic Author
Posts: 14
Joined: Thu Nov 30, 2017 1:35 am
Location: Australia

MSTP root port discarding when edge port status changes

Fri Oct 30, 2020 4:58 am

We have quite a few CRS devices deployed in the field and have found some odd behaviour only when using MSTP.

Whenever an edge/designated port changes status, either due to up/down or admin disable/enable, the root port (uplink to the root bridge) enters discarding mode for MSTI 0 (and any other configured instances). Then quickly transitions back into learning, then forwarding.

This results in interruptions on any frames traversing the switch.

Switching Infrastructure is as follows;

Root Bridge;
1 x Dell S4128F-ON (Priority 4096 // 0x1000)
1 x Dell S4128F-ON (Priority 8192 // 0x2000)

Member Bridges;
1 x HP Procurve 2848 (Priority 40960 / 0xA000)
4 x MikroTik CRS354 (Priority 28672 / 0x7000)

oct/29 20:14:06 interface,info ether17 link down
oct/29 20:14:06 bridge,stp sfp-sfpplus2:0 discarding
oct/29 20:14:06 bridge,stp sfp-sfpplus2:1 discarding
oct/29 20:14:08 bridge,stp sfp-sfpplus2:0 learning
oct/29 20:14:08 bridge,stp sfp-sfpplus2:0 forwarding
oct/29 20:14:08 bridge,stp sfp-sfpplus2:1 learning
oct/29 20:14:08 bridge,stp sfp-sfpplus2:1 forwarding


..
[admin@xxx-xxx-sw01] > interface bridge monitor br0 
state: enabled
current-mac-address: C4:AD:34:C4:DE:BA
root-bridge: no
root-bridge-id: 0x1000.68:4F:64:57:50:15
regional-root-bridge-id: 0x1000.68:4F:64:57:50:15
root-path-cost: 0
root-port: sfp-sfpplus2
port-count: 60
designated-port-count: 20
mst-config-digest: c4073f30b644e468297a52c7af83ee4a
fast-forward: no
..
[admin@xxx-xxx-sw01] > interface bridge msti monitor 0 
state: enabled
identifier: 1
current-mac-address: C4:AD:34:C4:DE:BA
root-bridge: no
root-bridge-id: 0.00:00:00:00:00:00
regional-root-bridge-id: 0x1001.68:4F:64:57:50:15
root-path-cost: 0
root-port: sfp-sfpplus2
port-count: 60
designated-port-count: 20
..

Configuration is as follows
/interface bridge
	add auto-mac=no comment=defconf name=br0 priority=0x7000 protocol-mode=mstp region-name=Xxxx vlan-filtering=yes

/interface bridge msti
	add bridge=br0 identifier=1 priority=0x7000 vlan-mapping=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
..

The following Firmware has been tested.

6.47.4
6.46.1
7.1 Beta 2 (wanted to check on a newer kernel)

We have replicated this behaviour on a single switch.

This behaviour is also exhibited regardless of whether the port is up or down and is disabled / enabled.

This seems to happen regardless of Edge port configuration, BPDU guard on 'designated' ports.

This is not expected behaviour.

Is this something to do with the switch chipset or the bridge implementation?
 
User avatar
merlinthemagic7
newbie
Posts: 47
Joined: Fri Sep 16, 2016 8:49 pm

Re: MSTP root port discarding when edge port status changes

Thu Jul 28, 2022 11:08 am

Hi,

See the same thing on CRS328-24P-4S+ running v7.4.

Its not just the local MSTP instance that suffers, the events are propagated downstrem as well, but only if the switch has more than one path. Disable your alternate paths and the edge propagations go away.

Local instance still bounces each time. I have an open ticket on the issue.
 
emunt6
Frequent Visitor
Frequent Visitor
Posts: 88
Joined: Fri Feb 02, 2018 7:00 pm

Re: MSTP root port discarding when edge port status changes

Sat Jul 30, 2022 7:44 pm

Hi!
MSTI 0 ( instance 0 ) only need vlan "1" - so you need to separate - this is for interoperability.
Other instances you can map as you want, other switches priority doesn't need to change from default value ( priority 32768 ).

Example:
instance 0 vlan: 1
instance 1 vlan: 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

Root Bridge;
1 x Dell S4128F-ON ( instance 0 priority 0; instance 1 priority 0 )
1 x Dell S4128F-ON ( instance 0 priority 4096; instance 1 priority 4096 )

Member Bridges;
1 x HP Procurve 2848 ( instance 0 priority 32768; instance 1 priority 32768 )
4 x MikroTik CRS354 ( instance 0 priority 32768; instance 1 priority 32768 )
 
dekiel
just joined
Posts: 2
Joined: Sat Dec 21, 2013 2:19 am

Re: MSTP root port discarding when edge port status changes

Wed Aug 03, 2022 2:04 am

Hi,

We see the same on our CRS326-24G-2S+ and CRS354-48G-4S+2Q+. Just after edge port state change all MSTI instances root ports are going through discarding, learning and forwarding states. We think this cause Tx Drops on root port interfaces. On weekend we are going to disable MSTP to check if Tx Drops disappear.

In our case it's only about Mikrotik devices. We have no other network devices vendors.

If we confirm Tx Drops are caused by MSTP we will open a support ticket too. @merlinthemagic7 did you get any information on your ticket?
 
User avatar
merlinthemagic7
newbie
Posts: 47
Joined: Fri Sep 16, 2016 8:49 pm

Re: MSTP root port discarding when edge port status changes

Wed Aug 03, 2022 10:44 pm

@dekiel Yes MSTP is an open issue (no specific confirmation on edge propagation).

Here is another post: viewtopic.php?p=948438#p948438

Recommended work around is using RSTP for the time being.
 
patana
just joined
Posts: 3
Joined: Mon Jun 14, 2021 11:47 am

Re: MSTP root port discarding when edge port status changes

Fri Oct 07, 2022 10:21 am

Update: still the same error :-/

From the Support:
Hello,
Thank you for the report!
We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now.
Sadly there is no workaround available, other than running RSTP.
Best regards,
 
rogerlie
just joined
Posts: 5
Joined: Fri Sep 25, 2020 10:14 am

Re: MSTP root port discarding when edge port status changes

Tue Dec 13, 2022 1:47 am

Hi,

I'm seeing a similar issue with ports oscillating with the learning, forwarding, discarding state. I have a ring of CRS317 switches running MSTP and this issue occurs on one particular link between 2 x CRS317, let's call it Link Z. This link configures as a backup/alternate port on startup which is expected based on the topology and path costs.

The strange thing is that when I break the ring, the ports on Link Z do not forward traffic at all and 2 switches in that ring go offline, seems there's nothing I can do to restore traffic on that single, directly connected path.

My setup is using Cisco EVPN single-flow-active as a backhaul transport network along with Cisco MSTAG such that a pair of Cisco PE's emulate a switch and send programmed MSTP BPDU's to the CRS317 switched network advertising the Cisco PE as the root bridge.

This approach works fine when there are no internal loops in the switched network.

I've also tried Cisco MSTP MSTAG with Mikrotik RSTP but the Cisco root bridge is not advertised by the first switch to other switches in the ring so Mikrotik RSTP-MSTP interoperability is not working.

So, please Mikrotik have a look at this MSTP learning/discarding issue and resolve soonest, we're running 6.47.9 and 6.47.10.

Regards,
Roger

Who is online

Users browsing this forum: Bing [Bot], GoogleOther [Bot] and 79 guests