MST adding a vlan with no impact

[jabouaf]

MST adding a vlan with no impact

Hello,

on a customer network (more than 50 switches), with MST (3 instances: 0, 1, 2) and VTP v2 (client/server, old switches), i'm requested
to define/add a new vlan (16) not yet defined in  MST-instance-1 neither MST-instance-2.

spanning-tree mst configuration
name xxxxxxxxxx
revision 1
instance 1 vlan 1, 3, 5, 7, 13, 15
instance 2 vlan 2, 4, 6, 8, 10, 14

From some reading I understand that adding a new vlan (16) on the VTP server will propagate it to all switches (VTP client).
From the MST point, the new vlan should be added to MST-0.

I would like to know:

  - just adding the vlan on the VTP server, should I get a STP recalculation for only MST-instance 0 ?

- As the VTP server will be the STP root for this vlan, will I get a MST recalculation for all 3 instances (0, 1 and 2) or only for instance 0 ?

Changing the MST configuration on the VTP server switch to add the new vlan to instance-2 would put this switch in a new region with MST recalculation and some new STP topology. This recalculation should take longuer than RSTP.
As the VTP server will still be the STP root for this vlan, will I get some STP port state changing to not forwarding state (it is the root but in a new region) for any or some instances ?

As the MST instance definition is not yet define for some futur vlans, how should I process to add the new vlan 16 and associate it to MST-instance 2 with no impact
(should be done without any maintenance window if possible) ?
    - first modifying the MST configuration (instance 1 to add this new vlan) on the VTP server, then adding the new vlan  (and so on the all VTP clients) ?
    - first adding the new vlan on the VTP server (and so on the all VTP clients), then later (weeks/days) on a planed maintenance window modifying the MST configuration (instance 1 to add this new vlan) only for the VTP server, and some days later on the about 50 remaining switches) ?
    - any suggestion ? (VTP v3 not yet available, there is some old cat2950).

Regards,

[Peter Paluch · Accepted solution]

Hello,

  - just adding the vlan on the VTP server, should I get a STP recalculation for only MST-instance 0 ?

No, you should get no STP recalculation at all. The newly added VLAN will be assigned to MSTI 0 and will immediately begin sharing the topology of MSTI 0 without requiring it to recalculate. From the viewpoint of MST, creating or deleting a VLAN that is already mapped to a particular stabilized instance does not constitute a topology change. In your case, the MSTI 0 already contains the VLAN 16, even if it is not yet created. Creating it makes no difference to the MST, as it is already mapped.

- As the VTP server will be the STP root for this vlan, will I get a MST  recalculation for all 3 instances (0, 1 and 2) or only for instance 0 ?

Just as described before, you should get no MST recalculation at all. The VTP server is the STP root for MST instances, not for individual VLANs, and if the instances do not change, the MST has no reason to recalculate. Creating a VLAN that is already assigned to a particular instance is not considered an instance change.

Changing the MST configuration on the VTP server switch to add the new  vlan to instance-2 would put this switch in a new region with MST  recalculation and some new STP topology. This recalculation should take  longuer than RSTP. 

This is true for the most part. However, the recalculation should be roughly in the timeframe of a pure RSTP, or longer in terms of tens/hundreds of milliseconds, not more.

As the VTP server will still be the STP root for this vlan, will I get  some STP port state changing to not forwarding state (it is the root but  in a new region) for any or some instances ?

In general, this is difficult to say without knowing your exact topology, however, even if the network consists of several MST regions, it should still remain fully connected and the reachability should not be impaired. Having several MST regions does not mean that they are isolated from each other. The Cisco's PVST Simulation mode performed on MSTP Boundary ports may complicate things but assuming your entire network runs MSTP exclusively, this should not be a problem (I'll verify that in a lab in a few hours or days).

As the MST instance definition is not yet define for some futur vlans,  how should I process to add the new vlan 16 and associate it to  MST-instance 2 with no impact (should be done without any maintenance window if possible) ?

My suggestion:

1. The VLAN 16 can be added at any time without causing an MSTP recalculation. No maintenance window is needed for this.
2. Later, during the maintenance window, modify the MSTP configuration on all switches, starting from the root switch. I also strongly suggest planning for future and adding new VLANs to the MST instances in advance so that in future, you won't need to reconfigure the MSTP region config anymore. For example, add all odd VLANs up to the VLAN 63 to the instance 1, and add all even VLANs up to the VLAN 64 to the instance 2.

I believe that the MSTP configuration should theoretically be modifiable using SNMP, however, I have not tested that yet. It would make the deployment of the MSTP configuration easier, I believe, but I have not tried that myself. VTPv3 is not and will not be available on 2950, as you correctly noted.

Best regards,

Peter

[jabouaf]

Hello Peter,

Thank you very much for those explanation. Those will help me a lot.

Best regards,

Jean-David

[glenn.white · Accepted solution]

Hi, just to add to Peter's already great answer if you haven't already attempted this work:

By 'creating' the layer 2 VLAN (16), you will not experience any STP recalculations but as soon as you attempt to move this VLAN to either of your other instances, your switches will run STP calculations as topology change notifications will be sent which will affect all instances.

By default all VLANs would be a member of MST instance 0 (show spanning-tree mst configuration) and so creating this VLAN does not alter this topology.

When you move this VLAN to another instance on a single switch, this switch is no longer part of the same MST region as the region is partly calculated using the member VLANs:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml#mst_config_region

This will cause disruption to your network as the switch on which you make this change (and potentially all others depending on the switch in question) must now recalculate its view of the network for all MST instances and, if it is in a region of its own as no other switch has been reconfigured, it will declare itself a root bridge. Every time a switch is reconfigured to your new MST topology, it determines if any other switch is within the same region and then determines its forwarding paths from there.

So, to summarise, Peter was absolutely correct to say this work should be completed in a maintenance window as without further knowledge of your LAN state (topology and STP state) it is impossible to say how much disruption this will cause but there will be disruption.

If all of your switches are connected in a hub-and-spoke / star topology and there are no daisy-chained switches, this disruption is minimal.

Should you have a more complicated topology with multiple rings, the potential disruption would increase.

When making MST configuration changes with CWLMS, the impact is the same as if you were making the changes manually, just slightly faster.

I hope this hasn't put you off making the changes, with a fairly simple topology, the impact is minimal and end-users would not be aware of the change.

[jabouaf]

Hello Peter and Glenn,

Thank you for all those information, I do appreciate.

At the moment, I just added a new vlan that is in default-MST (havy no impact at all as you wrote).

On a futur mantenance window, we will move it to an another MST-number.

The topology is not a hub-to-spoke one's, but a more complicated ones with a lot of chained switches. So we need a planned  maintenance windows (thanks to your informations).

Thank you very mutch.

regards,

jean-david

[Peter Paluch]

Hi Jean-David,

Thank you very much for keeping us informed and for your generous ratings! It has been a pleasure.

Best regards,

Peter

[SUMANTH BHASKAR]

Hey Guys,

         I have question after going thru all the above matter, does this means the any newly created vlan will get added to the default MST instance 0 without any necessry configuration ?

[Peter Paluch · Accepted solution]

Hello Sumanth,

Consider the following configuration:

spanning-tree mst configuration
 name ABCD
 revision 1
 instance 1 vlan 5, 11-15, 999

Here, instance 1 is defined and VLANs 5, 11-15 and 999 are mapped to it. There is no mapping for other VLANs defined which means they are implicitly mapped into instance 0 without any additional configuration, as also evidenced by the show spanning-tree mst config output:

SW-Dist1#show spanning-tree mst config
Name      [ABCD]
Revision  1     Instances configured 2
Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-4,6-10,16-998,1000-4094
1         5,11-15,999
-------------------------------------------------------------------------------

So, all VLANs are already assigned to MST instances even if they do not exist. After you create a VLAN, it simply starts sharing the spanning tree of its underlying associated instance. In any case, all VLANs are mapped to MST instance 0 unless explicitly remapped to another instance.

Best regards,

Peter

[ShahIrwan9489]

For example my existing  instance 1 (vlan 1-10). So I plan to create new VLAN 11. So can I create new instance instead add new vlan into instance 1. For example: 
- Instance 1(vlan 1-10),

- Instance 2 (Vlan 11-new vlan)..

So I apply instance 2 to core switch and all access switches. So it will impact recalculate at all my switches or not? 

Thanks