Yeah, I agree with the switched access layer when deploying VMWare. I think thats especially true when the client has VSS in their core and the ability  to stack at the access layer, too.This mitigates the possibility of a layer 2 loop tremendously because of the virtualization and the creation of virtual chassis at all layers. That being the case, deploying a routed access layer no longer has the same value or necessity.

But in this scenario, do you think it is still a good idea to deploy STP in both the access and core? I think its a good idea to do it. You lose nothing and can only gain. For example in the event of a hardware or software failure. or if someone plugs a switch into the chassis....

What do you think....?

lamav wrote:
Yeah, I agree with the switched access layer when deploying VMWare. I think thats especially true when the client has VSS in their core and the ability  to stack at the access layer, too.This mitigates the possibility of a layer 2 loop tremendously because of the virtualization and the creation of virtual chassis at all layers. That being the case, deploying a routed access layer no longer has the same value or necessity.
But in this scenario, do you think it is still a good idea to deploy STP in both the access and core? I think its a good idea to do it. You lose nothing and can only gain. For example in the event of a hardware or software failure. or if someone plugs a switch into the chassis....
What do you think....?

Victor

I would always deploy STP on all switches where possible although my understanding is that vswitches do not run STP as it is almost impossible to create an STP loop oin a vswitch.

But the point about using STP is valid because although with VSS/VPCs STP is no longer actively involved in forming a loop free path because there is no loop with dual uplink from access to a VSS pair, it should still be run in the background just in case. It costs you very little to run it and is a useful backup to have.

Jon

Jon, yes, you are right, I belive. vSwitches in, say, VMWare do not have the possibility for loops bevcause they dont trunk to other switches. I mean, it can happenb, but you would have to go out of your way to configure a VM vNIC in a certain way to make that happen.

My question was about deploying STP in an environmen that has access switches with stacking capability and core switches (no distro) running VSS.

I have a lot of questions regarding how the uplinks are treated in that kind of environment, which I will ask later. But for now, let me understand what youre saying. You are saying that with VSS and stacking in the access, you should still be running STP. Correct?

lamav wrote:
I have a lot of questions regarding how the uplinks are treated in that kind of environment, which I will ask later. But for now, let me understand what youre saying. You are saying that with VSS and stacking in the access, you should still be running STP. Correct?

Personally i would because it costs you nothing except for the exchange of BPDUs and it can protect against link failures or misconfigurations. Whether you run STP or not should not affect failover if one of your VSS pair fails.

I haven't come across any recommendations saying you should turn off STP because it gives you a specific advantage to do so.

Jon

Jon/Giuseppe, imagine a looped triangle topology. Two access switches dual homed to distro switches...the usual crap.

Now with VSS in the distro, the 2 distros look like 1 switch to the access layer, correct? So, that would mean that the 1 virtual distro would see itself as having two connections to each access layer switch, correct?

Now, lets say the access layer is stacked/virtualized (lets say its 2 3750s with a stacking cable between them. Now, you would have one distro [virtual] switch and 1 [virtual] access switch, correct? So, that would mean that each [virtual] switch would see itself as having 4 connections to the other [virtual] switch. Correct?

Thanks

lamav wrote:
Jon/Giuseppe, imagine a looped triangle topology. Two access switches dual homed to distro switches...the usual ****.
Now with VSS in the distro, the 2 distros look like 1 switch to the access layer, correct? So, that would mean that the 1 virtual distro would see itself as having two connections to each access layer switch, correct?
Now, lets say the access layer is stacked/virtualized (lets say its 2 3750s with a stacking cable between them. Now, you would have one distro [virtual] switch and 1 [virtual] access switch, correct? So, that would mean that each [virtual] switch would see itself as having 4 connections to the other [virtual] switch. Correct?
Thanks

Victor

Not sure it works like this. VSS represents 2 physical switches as a virtual switch to other switches. But each physical switch still runs it's own supervisor and modules so i don't think each chassis sees itself as a virtual switch. From the 6500s perspective they are still 2 physical switches with just the addition of a VSL + the VSL related protocols that are need to run VSS.

Jon

"Victor

Not  sure it works like this. VSS represents 2 physical switches as a  virtual switch to other

switches"

Jon, thats precisely what I am suggesting:

"Now with VSS in the distro, the 2 distros look like 1 switch to the  access layer, correct?"

I also think that each of the VSS'd distro switches will see the other as an extension of their chassis. So, the links between them will be viewed as within the system chassis. In other words, D1 will not send STP BPDUs to D2 because they dont see the other as being outside their system. At least this is how I interpret it....

If this is all correct, then what you would get is something that looks like a triangle... if each Access switch is dual homed to the physical distros, then you should picture 2 links going from the virtual distro to each of the access switches, as drawn.

                             Disto-virtual VSS Switch

                                 ||                    ||

                                 ||                    ||

                                 ||                    ||

                         ACCESS 1           ACCESS 2

Hello Victor,

I agree with Jon.

VSS and C3750 stacks allow you to use all uplinks with cross stack and Multi chassis etherchannels but STP may be of very great help in dealing with transitions caused for example by one switch failing in the VSS or stack.

The stack has a master and the master can fail, a new master needs to be elected for example (yes, there is MAC address persistency for the stack and so on.)

It is better to stay on the safe side and to use STP.

I need to learn something about these Vswitches.

Hope to help

Giuseppe

Jon...

Giuseppe....

Come back! Where did you go? I havent finished torturing you yet!

All kidding aside, I think this is a great discussion....

I would like your input on my last post...

Giuseppe:

I agree with you and Jon 100% regarding STP. It can only help, as I see it...

Check out my last question with my silly drawing....

Imagine that the access layer is NOT stacked but the distro is VSS'd...

Thanks

Victor,

In order for VSS to work correctly and loop free in the distro, the access layer devices must be capable of doing Multichassis EtherChannel (MEC).

All access layer devices would need to connect to the disto using Etherchannel.  Besides the chassis based switches ie 6500, 4500, the only small access layer device that is capable if doing MEC is 3750s stacked.  So for example you could not use 2 separate 3560s and uplink each one to a VSS set as they are not cable of doing MEC.

HTH

Reza

Reza, this is interesting. Do you know this because you have deployed it or is it through reading about it?

So, the topology I drew below can indeed be achieved -- or better stated, would be the result -- but only if I used 6500s on the access layer, or some other non-stackable chassis switch. that supports MEC. Correct?

Follow-up question:

Which Cisco platforms support MEC? Which of them are non-stackable but do support MEC?

Thanks

Victor,

I have deployed it and have a done lots of testing with VSS using 6500 at the access and VSS (6500) at the distro

The access layer could be a 6500 with dual sup-720-vs running SSO.  In this scenario you uplink one 10Gig port from the primary sup to the VSS distro and one 10Gig port from the secondary sup to the same VSS distro using Etherchannel.  The nice thing about this scenario is that even though the secondary sup is on stand-by if the primary sup goes bad or the port gets disconnected the secondary sup starts forwarding traffic without interruption.

non-stackable but do support MEC?>

Only 3750 series support MEC and that is because they can be stacked and logically become one switch. So if for example you have 2 3750s in a stack, you uplink one 10Gig from one 3750 and one 10Gig from the other 3750 and form an etherchannel

HTH

Reza