Smart Install - vstack startup-vlan vs vstack vlan

[jmandersson]

Hi Experts!

I'm looking into the Smart Install feature and have a question.
Does anybody know the difference in the commands "vstack startup-vlan" and "vstack vlan"?

Thanks,
Johan

Sent from Cisco Technical Support iPad App

[Reza Sharifi]

Hi,

From the command reference guide:

To specify the default VLAN that the director should use for Smart Install management, use the

vstack startup-vlan

global configuration command.

vstack startup-vlan vlan_value

To configure Smart Install VLANs for DHCP snooping, use the vstack vlan global configuration command on the Smart Install director. To remove a Smart Install management VLAN, use the no form of this command.

vstack vlan vlan-range

no vstack vlan vlan-range

Although you can enter this command on any device running a Smart Install image, the configuration does not take effect if the device is not the director. Only configuration commands entered on the director are valid. If the client becomes the director, the entered configurations are then valid.

When Smart Install is enabled on the director, DHCP snooping is automatically enabled on VLAN 1. You can, however, use the vstack startup-vlanglobal configuration command to specify another default VLAN instead of VLAN 1.

There is no limit to the number of Smart Install VLANs that you can configure.

This command does not apply to routers

http://www.cisco.com/en/US/docs/switches/lan/smart_install/configuration/guide/commands.html#wp1009006

HTH

[jmandersson]

Hi Reza,

Yes I've read the command reference. But I also need to understand...

Doesn't both explanations say the same thing, just different words? Both commands enable DHCP Snooping for Smart Install vlan. So what is the difference?

Thanks

Sent from Cisco Technical Support iPad App

[Jon Marshall]

Johan

It's mainly a way to be more specific in terms of which vlans you can deploy clients onto.

"vstack startup vlan"  defines the default vlan that the director switch will perform DHCP snooping on. So lets say you only have one vlan you wanted to deploy the clients on, and it wasn't the current default vlan, it would make sense to use the above command to change the default vlan. That way you could be sure no clients would be deployed except on the vlan of your choice.

"vstack vlan" allows you add to further vlans (in addition to the default) if you want to deploy clients on multiple vlans.

But there might be a setup where you wanted to deploy clients to multiple vlans but you do not want to allow the deployment of switches on the default vlan.  In that case you would have to change the default using the "vstack startup vlan" command and then add the rest with the "vstack vlan" command.

If you just added the new vlans with the "vstack vlan" command then clients could still be deployed on the default vlan which in the scenario described above should not be permitted.

Hope that makes sense.

Jon

[Jon Marshall]

Johan

Apologies for using this thread to talk to Reza, hope you don't mind.

Reza

Just a quick question. With VSS you only need to configure the one switch and it applies to both. So there is no need for things like HSRP.

I always assumed because Nexus switches supported vPC etc. that they were also seen as one logical switch and so the same applied. But a couple of posts i have read recently made me think maybe that is not the case.

Can you clarify ?

Jon

[Reza Sharifi]

Hi Jon,

You are correct.  With VSS, you configure one device and that applies to both switches.  So, no VRRP, HSRP, etc...

VSS has one control plane. Once VSS is configured, the blades/ports merge.  So, when a port was gi1/1 after the merge, it is 1/1/1 and 2/1/1 for the second switch, and you configure everything from the primary switch.

With VPC, you have 2 control planes.  Even though you configure vPC, you still have to configure, VRRP, HSRP, etc... and the ports don't merge.  So, port e1/1 an switch one is different from e1/1 on switch 2.  So, you have to configure everything on both switches.  There is an option called "config sync" and from what I understand it will push the config from one switch to another.  I have never deployed "config sync" before, but from what I have heard it is not very seamless.

Thanks,

Reza

[Jon Marshall]

Hi Reza

Many thanks for clarifying that and now some of the recent posts i have been reading make a bit more sense.

If you don't mind a few follow up questions based on you mentioning that each switch had it's own control plane - 

1) The interconnect between a pair of Nexus switches. Is it seen as just a normal interconnect in the same way an interconnect between a pair of 6500s that were not running VSS would be. Or is it seen more like the VSL that interconnnects a pair of 4500/6500s ?

2) If it is seen more like a VSL then with VSS the recommendation is to keep as much non control traffic off the VSL link as possible so you should connect other network devices with etherchannels that spread over both switches in the pair.

Do the same considerations apply, specifically in terms of keeping data traffic off the interconnect ?

3) With VSS you have to use extra links with BFD/fast hello or  PaGP via another switch in case the entire VSL fails to stop both switches going active.

Does the same sort of thing apply to Nexus switches.

Sorry for all the questions, this will be the last lot as i should really have opened a new thread on this as it makes it difficult for other users to find this sort of content.

I keep meaning to get around to reading up on the Nexus switches but there is always something else that comes along first

Jon

[Reza Sharifi]

Hi Jon,

Not a problem at all.  I will be glad to answer any question you have.

1) The interconnect between a pair of Nexus switches. Is it seen as just a normal interconnect in the same way an interconnect between a pair of 6500s that were not running VSS would be. Or is it seen more like the VSL that interconnnects a pair of 4500/6500s ?

It is seen more like a VSL link.  It is call vPC peer-link. Just like the VSL, the vPC peer-link usually is made of 2 10Gig or in a case of 6ks, 2 40Gig interfaces. This vPC is a layer-2 link and if  FEXs are dully attached to the both 5ks or 7ks, traffic should not go over this link.

2) If it is seen more like a VSL then with VSS the recommendation is to keep as much non control traffic off the VSL link as possible so you should connect other network devices with etherchannels that spread over both switches in the pair.

That is correct. It is recomended to keep traffic off the vPC peer-link.

3) With VSS you have to use extra links with BFD/fast hello or PaGP via another switch in case the entire VSL fails to stop both switches going active.

Just link Fast hello/BFD for VSS, for Nexus you also need a similar link.  It is called vPC-keep alive link.  This link usually is a gig link and most people and it is also recommended to use the out of band management port for this link.

The difference is that Fast hello is a layer-2 link, but the vPC-keep alive needs to be a layer-3 link.  In the past, I usually have used a small switch e.g 3750, 3560, etc... to connect the management ports of the 7ks or 5ks together to establish the vPC keep-alive link.

Overall, there are few similaraties between VSS and Nexus with vPC, but as you already know since each tecknology is produed by a different BU (Businees Unit) at Cisco, they come up with different names and each do some things different.

Also, here is a good link on vPC design and best practice.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf

Hope, I was able to make things a little more clear.

Thanks,

Reza

[Jon Marshall]

Reza

Thanks once again and thanks for the link.

Looks like i have got my reading sorted out today then

Jon

[Jon Marshall]

Hi Reza

Don't know whether you will see this but if you do. I was reading an Ask the Expert on VSS and i came across this from a poster -

Hi Anand, I had a question on Layer 3 peering with VSS. As VSS is logically one control plane, so if I dual attach any layer 3 device with the VSS pair, will it see only 1 IGP neighbor (i.e the active switch)? If yes, this is a big advantage over nexus-vpc as you have 2 control planes there and each layer 3 device sees both the nexus as its IGP neighbor (one of them over the vpc peer link)  which leads to 50% of the traffic being dropped over the vpc peer link due to the in-built vpc loop avoidance technique.

I don't follow this. I understand the bit about VSS and i also understand that each Nexus switch runs it's own control plane (thanks to one of your earlier posts) so i can see that the L3 device would see two IGP peers. But i would have thought it would see the IGP peers over it's direct links to each Nexus switch whereas the poster seems to be suggesting it sees two peers but one of them is via the vPC peer link.

Could you perhaps clarify ?

Jon

[Leo Laohoo]

vstack startup-vlan

This command adds further compexity to the Zero Touch SmartInstall.  Without this command, the VStack director will ALWAYS use VLAN 1.  This is because every out-of-the-box client has VLAN 1.  This command was added because some companies use VLAN 1 in production and they want to use a different VLAN (other than VLAN 1) to run SmartInstall.  With this command, you can specify the VLAN which the VStack director will talk to other clients downstream.

When the client boots up, it will talk to the VStack director in VLAN 1.  VStack director will say, "Hey, we're suppose to be using a different VLAN other than VLAN 1.  My config says we should be using VLAN 123.  Can you please create VLAN 123?".

The main question is what VLAN should the VStack director configure the access port?  I am not sure because I haven't used this feature before.  In our network VLAN 1 is always in shutdown and the only place where you'll find something in VLAN 1 is the Zero Touch SmartInstall.

https://supportforums.cisco.com/docs/DOC-25808

[jmandersson]

Okey, I got the difference now!

And Leo, thanks for the link.

/

Johan