MST instance change shutting down SVIs

[jhenkenhaf]

Hi everyone, (hopefully not a double post, first upload seemed to fail)

maybe someone can help me understand a little better how MST works. Following scenario:

• Network set up in a star topology
• Core-Switch is STP root, acces switches connected via static portchannels
• MST is running in a single region with identical revision/name through the network
• MST is running in multiple instances (0: empty, 1: mgmt-VLAN, 2: all other VLANs, 3 and 4: testing purpose)

What startles me is, that whenever I move a VLAN from one instnace to another, ALL SVIs that are configured on this switch go down and up for a split second. This happens even when VLANs are interchanged between instances that don't even have SVIs configured. I could understand if the VLAN interface of the VLAN I am changing shows this behaviour, but all of them? (see output below)

What I do understand is, that BPDUs are sent in single BPDU for all instances (with differen MRecords for instances). But even so, I get the debug output that nothing needs to be changed, and still SVIs go down/up. This of course cause a short disruption in the network and leads to connectivity losses (1 to 2 pings).

Is this the usual / designed behaviour of MST, or specific to Cisco implementation / switch software?

Any input appreciated.

Kind regards,

Jochen

LAB#show spanning-tree mst configuration
Name      [mst-2]
Revision  2     Instances configured 5

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         none
1         10
2         1-9,11-249,251-299,301-399,401-4094
3         300
4         250,400
-------------------------------------------------------------------------------
LAB#

-> change of one VLAN to another instance

LAB(config)#spanning-tree mst configuration
LAB(config-mst)#instance 3 vlan 250
LAB(config-mst)#exit
LAB(config)#
*Mar  2 01:31:57.422: STP SW: Po1 new blocking req for 0 vlans
*Mar  2 01:31:57.439: STP SW: Po1 new forwarding req for 0 vlans
*Mar  2 01:31:57.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar  2 01:31:57.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to down
*Mar  2 01:31:57.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan100, changed state to down
*Mar  2 01:31:57.515: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
*Mar  2 01:31:57.515: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
*Mar  2 01:31:57.515: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan100, changed state to up
LAB(config)#

-> SVIs configured

LAB#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  10.0.1.1        YES manual up                    up
Vlan10                 10.0.10.1       YES manual up                    up
Vlan100                10.0.100.1      YES manual up                    up

[Peter Paluch · Accepted solution]

Hi Jochen,

I would need to test this in a lab. However, this is what I suspect is happening:

Each time you move a VLAN from one instance to another, you change the configuration of your MST region. Until and unless this change is done at precisely the same instant on all switches in your region, your region fragments into multiple MST regions, some with the old VLAN-to-instance mappings, some other with the new mappings. As a result of this fragmentation into several regions, the newly created boundary ports between these regions need to negotiate their roles and states, and until they do, it is possible they are put into Discarding state. This would explain why your Vlan interfaces flap momentarily - because all access and trunk ports in these VLANs appear to drop to Discarding state and come back to Forwarding, and during their placement in Discarding state and the MST Proposal/Agreement procedure taking place, the associated Vlan interfaces need to go down.

Moving a VLAN between MST instances is quite disruptive to MST operation. Usually, VLANs are pre-mapped into instances before they are even created precisely to avoid operational issues related to the change of MST region configuration that occurs whenever the mapping is changed.

Best regards,
Peter

[jhenkenhaf]

Hi Peter,

thanks for the feedback, that explanation seems plausible. Do you know about some debugging that can be done to follow this process?

I did another debug myself (debug pm vp, see output below) but I guess this is working as designed then. It would be awesome if you (or someone else who can verify this) can give some final input that verifies the above statement, then I could mark  this question as answered.

Thanks for the support :)

Switch#
*Mar  1 02:27:57.495: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 02:27:58.519: STP SW: Po1 new blocking req for 0 vlans
*Mar  1 02:27:58.527:     pm_vp 2/1(1): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(1): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(10): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(10): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(100): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(100): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(101): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(101): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(102): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(102): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(103): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(103): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(104): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(104): forwarding -> notforwarding
*Mar  1 02:27:58.527:     pm_vp 2/1(105): during state forwarding, got event 15(notfwd_notnotify)
*Mar  1 02:27:58.527: @@@ pm_vp 2/1(105): forwarding -> notforwarding
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(1)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(10)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(100)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(101)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(102)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(103)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(104)
*Mar  1 02:27:58.527: *** vp_list_fwdchange: notfwd: 2/1(105)
*Mar  1 02:27:58.536: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar  1 02:27:58.536: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to down
*Mar  1 02:27:58.536: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan100, changed state to down
*Mar  1 02:27:58.544: STP SW: Po1 new forwarding req for 0 vlans
*Mar  1 02:27:58.561:     pm_vp 2/1(1): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(1): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(10): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(10): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(100): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(100): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(101): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(101): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(102): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(102): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(103): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(103): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(104): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(104): notforwarding -> forwarding
*Mar  1 02:27:58.561:     pm_vp 2/1(105): during state notforwarding, got event 14(forward_notnotify)
*Mar  1 02:27:58.561: @@@ pm_vp 2/1(105): notforwarding -> forwarding
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(1)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(10)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(100)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(101)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(102)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(103)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(104)
*Mar  1 02:27:58.561: *** vp_list_fwdchange: forward: 2/1(105)
*Mar  1 02:27:58.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
*Mar  1 02:27:58.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
*Mar  1 02:27:58.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan100, changed state to up
Switch#

[Peter Paluch]

Hi Jochen,

To debug this, I would suggest the following two:

debug spanning-tree events
debug spanning-tree general

Best regards,
Peter

[jhenkenhaf]

Hi Peter,

thanks for leading me onto the right tracks here. It looks indeed like things happen as you posted in the first answer, I'll mark that one as Correct Answer.

Here is some additional Information that I could gather during testing:

• The switch puts MST instances into the following states: forwarding -> disabled -> blocking -> forwarding
• This happens for ALL instances in which there are active VLANs on the switch (not necessary L3 interfaces as first suspected)
• Instances without active VLANs are not affected

Output below is the debugging that helped me: Same configuration as above, but I only realised later, that VLANs in instances 3 and 4 were not active. As soon as I configured ports with those VLANs, the respective Instances appeared in the debugging aswell.

Thanks for helping me understand what happens in this scenario.

Best regards,

Jochen

LAB#debug spanning-tree mstp state
LAB#
LAB#
*Mar  3 00:14:26.536: %SYS-5-CONFIG_I: Configured from console by console
*Mar  3 00:14:26.553: MST[2]: Po1 state change forwarding -> disabled
*Mar  3 00:14:26.553: MST[1]: Po1 state change forwarding -> disabled
*Mar  3 00:14:26.553: MST[0]: Po1 state change forwarding -> disabled
*Mar  3 00:14:27.559: MST[0]: Po1 state change disabled -> blocking
*Mar  3 00:14:27.559: MST[2]: Po1 state change disabled -> blocking
*Mar  3 00:14:27.559: MST[1]: Po1 state change disabled -> blocking
*Mar  3 00:14:27.576: MST[0]: Po1 state change blocking -> forwarding
*Mar  3 00:14:27.576: MST[1]: Po1 state change blocking -> forwarding
*Mar  3 00:14:27.576: MST[2]: Po1 state change blocking -> forwarding

[Peter Paluch]

Hi Jochen,

Thank you for sharing your experiment results!

The switch puts MST instances into the following states: forwarding -> disabled -> blocking -> forwarding

The "disabled" state in fact suggests that the corresponding MST instance was essentially reset and started from scratch. That is logical, considering that the change of MST region configuration that impacts a particular instance basically requires that the instance is reinitialized.

Best regards,
Peter