Migrating PVST to RSTP - Pros n Cons

akhil.abrol · ‎11-10-2009

Dear Experts,

I would like your suggestions to help me Migrating PVST to RSTP. We have 2 core switches (6509 - SUP 720) connected to each other via 2 TenGig links as port-channel. Rest all the Distribution Switches (L2) (4948) are connected to Core switches via 3gbps fiber port-channel and Access switches (L2) (4948) are connected to distribution switches via 2gbps fiber port-channel.

Primary core switch is currently the root bridge and secondary is secondary root bridge. Portfast and bpdufilter is enabled on all the access ports. Total we have around 45 (4948) switches.

We know that RSTP is better in converging but i just need your expert comments since its a Live environment.

Thanks..

Giuseppe Larosa · ‎11-10-2009

Hello Akhil,

>> Portfast and bpdufilter is enabled on all the access ports.

This is very important for Rapid STP because it tells to the protocol that those ports don't take part in synchronization process.

This is important to achieve fast convergence.

if your distribution switches are L2 only STP is extended on the three levels core-distribution-access.

distribution layer is the one that can get the greatest benefits of RSTP.

at access layer STP + uplinkfast could be enough.

you may use STP and backbonefast in all core and distribution switches but you only get that max-age is not used.

if you think of moving to Rapid PVST I see the migration easy and smooth because the protocol is backward compatible with PVST on a per port basis.

Moving to 802.1S could be considered if you many vlans (you have 48 switches) but that is not a smooth transition.

I would do the following:

make one core switch the root bridge for all vlans

change the stp mode to rapid-stp on it.

convert each distribution to Rapid STP

convert each access layer switch

convert the second core switch.

then have odd vlans root bridge core1 and even vlan root bridge core2 to have some load balancing.

Hope to help

Giuseppe

akhil.abrol · ‎11-11-2009

Hello Giuseppe,

Thanks for your reply and suggestion. :)

My plan while implementation was, running the default PVST in switches and later on changing it to Rapid PVST. Now what problem i faced is, There are some HP blade chassis in the Datacenter. And in these chassis, Nortal switches are embedded. Since PVST is cisco proprietary Nortal is not understanding the BPDUs.

So then, RSTP is the only option I'm seeing. But like in PVST we can do load balancing is there any way we can do the same in RSTP? If i run RSTP, there will be only one instance of STP. A single change in the Network will impact the whole traffic of Datacenter. All the Vlans will get affected.

Any suggestions here? :(

Akhil

Giuseppe Larosa · ‎11-11-2009

Hello Akhil,

in multivendor contexts the only way to have an effective interaction with some topology differentiation is MST 802.1s.

Check if your nortel switches support 802.1s MST.

Rapid PVST doesn't solve the issue.

be aware that MST requires a change of mind and approach.

you should provision all Vlans associating them to the MST instances.

making a change on live network can partitition the MST region.

all possible 4094 vlans can be provisioned even before they are created in the vlan database.

in this way when a new vlan is needed you pick up a vlan from the subset of vlans associated to the desired MST instance/topology.

Hope to help

Giuseppe

Mohamed Sobair · ‎11-11-2009

Hi,

You have two options here:

1- running pre-standard MST with HP blade and have the loadbalancing in place.

2- running standard PVST with HP and disable the functionality of loadbalancing.

So, I would choose to go with option 1, if the switches are MST configurable.

HTH

Mohamed

akhil.abrol · ‎11-12-2009

Thanks for the suggestions.

If we talk about RSTP, is it a good idea to migrate from PVST to RSTP if the topology is really big. Why i m saying is because the datacenter is expanding. More switches we have to install. So only one instance of STP means a small change will affect the whole LAN.

MSTP is a good option but like Giuseppe said MST requires a change of mind and approach. Since the downtime will be very limited it will be a little tough to make things work fine. Lets see...

Thanks again for the suggestions...