MST Migration on Catalyst 2950/3550

[scheikhnajib]

Hi There,

I have a L2 switched network that has a mixture of Catalyst 3550 and 2950G currently running Rapid-PVST.

I had an earlier problem in the number of per-VLAN Spanning-Tree instances since the number of my VLANs is increasing rapidly; I figured out that configuring MST would solve my problems where I can group large number of VLANs into a single STP instance.

I have ran some tests in a small simulated lab and it was OK, and now I'm planning to implement this on the live network.

Since this is critical, I'm a little bit worried ... are there any recommendations, suggestions or ideas that you can come up with before I implement this new configuration?

I would really appreciate any comment regarding this issue.

Yours,

Salem.

[pedroquiroga]

Hi, this links gives some information:

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

some suggestion:

- MST is backwards compatible with PVST+, but If you can,make the change all at once during an outage window.

- The first switch to migrate is the root of the vlans (then go migrate the one neraest to it).

I hope it helps...

[Francois Tallet]

-Try to avoid the interaction between MST and PVST if you can (this adds complexity to MST which is quite simple if you can run your whole network with it).

If you must have this interaction, keep the root on the MST side (again, for the sake of simplicity).

-What is the most painful with MST is that changing the configuration is a major event. If you plan to consistently add vlans to your network, the best is that you already provision some groups of vlans mapped to your different instances. The vlans don't need to exist to be mapped to an MST instance. So just spread the 4K vlans accross all your instances. This way, you always have a pool of vlan available for each instance and you never need to change your MST configuration.

Regards,

Francois

[scheikhnajib]

Hi Fracois,

Thanks for your help. My environment requires adding VLANs on weekly basis, and I was planning just what you have recommended, but you triggered another question in my head.

Is there any kind of recommendation on how many VLANs per instance I should be considering? What is the factor(s) that decide(s) how VLANs are spread among the instances?

I've been reading alot, but this needs personal experience such as yours to answer.

Thanks alot in advance,

Salem.

[Francois Tallet · Accepted solution]

Hi Salem,

The number of vlan mapped to a given instance does not matter, that's the beauty of MSTP;-)

You just need to identify how many different topologies you need in your network in order to achieve load balancing across your redundant link. For each of these topologies, create an instance. Then divide your vlans among these instances in the MST config. This way, when you need to create a new vlan, you can just select one assigned to the topology you want.

Aside the load balancing, you might also consider creating several instances to isolate the flush resulting from topology changes. MST operates at the instance level, so when a topology change occurs in an instance, all the vlans mapped to it are affected. Even with the same kind of topology, you may want to segment your network in separate instance to limit the scope of the topology changes. The IEEE is working on the replacement of GVRP, and its successor (MVRP) should hanlde the topology change at the vlan level, removing it from the responsibility of MST. When this occurs, this second will have no reason to be.

Last point about how to group vlans to instances. You are free to associate whichever vlan to whichever instance of course, but for optimized operation, it's better if you use ranges. For instance, mapping vlan 1-1000 to instance X, 1001-2000 to instance Y etc... Mapping all the odd vlans to instance X and all the even ones to instance Y is less efficient.

Regards,

Francois

[scheikhnajib]

Hi Francois,

Thanks for your recommendations; I have carried out the migration and it was successful.

Most Appreciated.

Salem.

[amir rostami]

Hi,

Be careful about 2950, I have serious problems with that in MST.

It is likely to face "Dispute Pre-STD-Rx" on the other hand of 2950 (3750 for example),

I've taken research to solve them, Finally I found that 2950's MST BPDU is not correct even "pre-standard" command on other hand (3750).

According to:

https://supportforums.cisco.com/t5/other-network-infrastructure/not-correct-mstp-bpdu-by-cisco-2950/td-p/621582

Best Regard