"triangle" switchs topology

[Alexandre.Pieroux]

Hello,

Here I have some questions about a "basic" topology with 3 switches.

I have 3 switch inter-connected ( two are Catalyst 3550 and a stack of two Catalyst 3750).

Here a little exemple:

( /!\ All of my link are up, in trunk 802.1q mode).

the configuration of the two 3550 are pretty simple:

the links are in switchport mode trunk

trunk encapsulation dot1q

spanning-tree mode rapid-pvst

vtp mode transarent

And the configuration of the 3750 stack:

Also in switchport mode trunk

trunk encapsulation dot1q

spanning-tree mode rapid-pvst

vtp mode transparent

interfaces Gi1/0/1 and Gi2/0/1 are in a port-channel mode active.

(Gi1/0/ to 1-Catalyst 3550 and Gi2/0/1 to 2-Catalyst 3550).

Every switches have their ip address in the same vlan (vlan 150 and not native).

They can ping eatch other.

3 hosts are connected to the switches:

Host1 connected to the 3750 stack

Host2 connected to the 1-Catalyst 3550

Host3 connected to the 2-Catalyst 3550

It seems like when I unplug a fastEthernet link from a 3550 that make the switch take the path of the GigabitEthernet fiber to the other 3550, and that's perfect (It just take less than a second).

But when I unplug or plug that Gi fiber it take 30-50 sec to the switch to recover connection, and that's annoying.

I would like to know how can I make a fully redundant system without losing any data when one of the 3 link fail ?

How can I improve the system performance and avoiding the stp long time of recovery ?

And does my port-channel, on the 3750 stack, is a good or bad practice for having an instant fail-over between the two switches 3550 ?

I'm not expecting any complete response but, at least some links or documentations.

Sorry for my poor english hope you have anderstand what I ask.

Thanks in advance !

[alexander.milyar · Accepted solution]

port-channels should be connected to the same switch.

they should not be connected to different switches.

break port-channel and just use standalone links, you do not need it here.

[Alexandre.Pieroux]

Thanks,

That's what I thought.

I've read some documentation about RSTP and PVST+ where I can have a root switch which can administrate the STP domain and with optimisation can resolve my prolem but I don't know how it really work and how to configur this.

Has I understood that, I could reserve my GigabitEthernet fiber when a link fail. So this link is used as a root link when the other fail.

Can I really have what I expect with this ? A topology fully redundant with fail over and very quick convergence ?

Thanks.

[alexander.milyar · Accepted solution]

You are right, rstp is fast and you can achieve what you want with it.

Consider about using different features around stp in your network, like root gueard and etc.

http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swstpopt.html

[Alexandre.Pieroux]

Thanks I'll try it

[Alexandre.Pieroux]

It work !!!

With the RSTP and PVST+ the network just work has I want

Here what I changed on the 3 switches:

break the port-channel

enabled stp uplinkFast : Switch(config)# spanning-tree uplinkfast

enabled stp backboneFast: Switch(config)# spanning-tree backbonefast

Set a higher priority on the 3750Stack (it become the root switch fort stp)

Switch(config)# spanning-tree vlan 150 priority 0

and the two switche elect a root port and 1-Catalyst3550 show that it block the GigabiteEthernet fiber and place it instantly in farwarding state when the root link fail...and that great

Thanks !

[alexander.milyar]

Nice to read that all works well.

It's not good to set priority 0. Because other switch with priority 0 but lower mac-address may became root switch.

And also if you will need to move to another root switch smoothly after a time - you can't, because you can't set priority lower then 0 at that new switch and it never can be root.

It's better to use root guard and some lower priority like 20000 or even better "spanning-tree vlan 150 root primary" - this will setup automaticly lower priority then you have got in network.

About root guard: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml

And RSTP does not need backbonefast uplinkfast, it's already built-in.

backbonefast uplinkfast are for old STP.

Checkout https://supportforums.cisco.com/thread/2075555

Output from there

The RSTP alone, by itself, has built-in mechanisms that provide a similar functionality to Cisco's proprietary BackboneFast and UplinkFast STP extensions. Therefore, activating the RSTP (or the RPVST/RPVST+) immediately gives you the advantages of BackboneFast and UplinkFast. However, the BackboneFast and UplinkFast themselves are distinct extensions and they are not activated along with RSTP. In fact, even if you configured them together with running RSTP, they would not be active because RSTP already provides their functionality, although by slightly different mechanisms. That fact is confirmed by your output of show span sum

To sum it up, the RSTP already incorporates the functionality of UplinkFast and BackboneFast (although not implemented exactly in the way the UplinkFast and BackboneFast implement it), and when you activate RSTP, you get UplinkFast-like and BackboneFast-like functionality. The UplinkFast and BackboneFast alone, however, are not and will not be activated.

[alexander.milyar]

And rate my first post as right answer too, because it is directly right answer about destroying port-channel and this helped. Other guys that will read this thread will be confused about question and right answer...

[Alexandre.Pieroux]

Thanks for these precisions and for your help.
In fact it work the same way without UplinkFast and BackboneFast

And I've used "spanning-tree vlan 150 root primary" to make a better config.

Thanks.

[Alexandre.Pieroux]

And "Good guy IOS" prevent on using UplinkFast and BackboneFast in RSTP :

Switch is in rapid-pvst mode

UplinkFast                              is enabled but inactive in rapid-pvst mode

BackboneFast                        is enabled but inactive in rapid-pvst mode