STP (pvst+/rapid pvst+) configuration between Cisco and Riverstone 3100

[alexserkin]

Hi,

Could anybody point me to proper configuration between Cisco (3750) and Riverstone 3100 switch?

I'm interested in compatible stp configs between pvst+/rapid-pvst+ on 3750 and stp/rapid-stp on Riverstone if it's possible.

Currently we have two dot1.q trunks connecting 3750 with rs3100. There is rapid pvst on catalyst and rapid stp configured on rs3100.

One of this two ports goes to forwarding state and another to blocking on cat 3750. If i disconnect forwarding interface, nothing happens with stp - another port remains in blocking state.

At the same time rs3100 considers itself as a root bridge for two vlans living on trunk, and cat3750 tells it's root too :-).

[Aaron Harrison]

I've never heard of a Riverstone, but here's my ten pence:

I guess what's happening here is that the numbers that Cisco and Riverstone use to determine who gets to be root are not compatible... in Cisco-land, the lowest 'priority' number set is the root, I have no idea what the Riverstone uses to determine it... you will need to find that out to solve the problem.

As both switches think they are the root, no ports will go into 'blocking' as all ports on the root bridge are 'forwarding' by definition.

Regards

Aaron

Please rate helpful posts...

[Francois Tallet · Accepted solution]

Don't know how riverstone works either, but I'll assume this is an IEEE standard RSTP, i.e. not something like our proprietary Rapid-PVST+;-)

In that case, the Cisco switch will run RSTP with the riverstone on vlan 1 only. The other vlans instances on the Cisco will see the riverstone as a hub. As a result, the non-1 vlans on the Cisco will block as backup ports, which will lead to a slow reconvergence in case of failure. That's the only explanation that I can give to your port staying blocking after the forwarding link goes down. If it is not going forwarding after 36 seconds (with default timers), then I don't know what the problem is. A port can only block if it keeps receiving better BPDUs and it is not the root port. Check this condition on the Cisco bridge. If the riverstone is running an IEEE standard RSTP, only vlan 1 should receive BPDUs, the other vlans will not!

If by any chance the riverstone is running its own version of PVST, then unexpect results may occur.

I would recommend you switch your cisco to MST mode. That will be equivalent to running standard RSTP and should help. The only problem is that you won't be able to do vlan load-balancing, unless riverstone is able to run MST also.

Hope this helps,

Francois

[alexserkin]

And if BPDUs are sent only on vlan 1 and on my trunk only vlans 302,303 are allowed, then catalyst does not see BPDUs at all?

[Francois Tallet]

The catalyst will see its own BPDUs, flooded through the riverstone back to it. There will be no interaction at all between the 2 STPs! Both side will think they are the root.

You will have slow reconvergence in case of link failure (I expect 36 seconds: 6 second to age out information + 30 seconds through the listening/learning stages before a backup port can move to designated forwarding).

Regards,

Francois

[alexserkin]

Thank you, Francois. The explanation's helped me understand things.

There was "spanning-tree loopguard default" on catalyst which prevents unblocking of backup port

[Francois Tallet]

Oh, right! I did not think about that. Indeed, you cannot use loopguard in this configuration. Loopguard assumes that the link is point to point to a neighboring switch. If you don't receive BPDUs from your neighbor, you consider the p2p link as failed and block it (loopguard inconsistent). But here, you expect backup connectivity through this link. It is thus more than a p2p connection to the designated neighbor.

Regards,

Francois

[Francois Tallet]

BTW, you can still run MST on the Cisco to be able to interact with the riverstone RSTP. This should give fast convergence time (again, with no load balancing, ie both your vlans will block on the same port).

F/

[alexserkin]

Well, i need some advice on moving from rapid pvst+ to mst in my environment.

We have about 130 vlans with different purposes - local lan, services, customers.

And i need an upgrade plan wich does not take much time to move from pvst to mst.

The frst thing which comes to my mind - just create an mst instance including all my vlans and change spaning-tree mode to mst.

But if we move to mst we should have some reasonable configuration which will effectively use the mst advantages.

Is there any recommendations on provisioning the mst regions, instances on a service provider network transport? Yes i've read the "Configuring MST" in 3750's user's guide.

[Francois Tallet]

Hi,

Unfortunately, I don't have any step by step miracle plan;-) Indeed, just converting to mst with no specific mst configuration should work. MST is also "plug-n-play". Of course, while you are migrating, if you plan to keep MST and PVST toghether, you have to pay attention to their interaction. Check http://www.cisco.com/warp/public/473/147.html for a brief explanation. Else, again, a full MST network with no config should be working if you are in a hurry.

The main problem with MST is its lack of flexibility in the way it indentifies regions. MST Instances only run within MST regions, and MST regions are defined as a group of MST switches having the same MST configuration (here, by configuration I mean vlan to instance mapping, name and revision number). As a result, if you want to change this configuration, you have to do it on each and every switches in the network, which is kind of painful (you should not lose connectivity for a long time while you're doing it, but you may lose the benefit of load balancing, i.e. the possibility of having traffic following different instances) while transitioning from one config to another. So the main advice I would give if you are planning to migrate to MST is to pre-provision your MST configuration for several vlans and several instances, even if you don't use them right away. As a simple example, you could map group of 50 to 100 vlans to different MSTIs.

Vlan 1-100 -> mapped to mst instance 0

vlan 101-200 -> mapped to mst instance 1

etc...

Again, this does not mean that the vlans have to be created or that the instances have to run (an MSTI only runs if it has some active vlans mapped to it). But with that kind of configuration, you can always start using one vlan or one instance, without having to reconfigure the whole network, just because of have lots of vlans and instances available in your config.

Hope this helps,

Francois

In the vlan to instance mapping