Our other alternative is to add uplinks to the blade chassis and use the HP Virtual Connect profiles to assign the NICs to the access port uplinks during provisioning and move them to the trunked uplinks afterwards. Annoying for operations, but at least the management can all be accomplished remotely.

Cheers,

So, yes, at first glance it would seem that these recommendations are at adds. However, you’ll note that in the article on the native VLAN I recommended setting the native VLAN to that of the Service Console ONLY if you needed automated builds to work. Otherwise, there is no need to set the native VLAN to that of the Service Console.

In addition, note that there are many instances in which you must bend the “best practices” in order to fit the customer’s business requirements. If the customer absolutely must have automated/scripted ESX builds, then you’ll need to set the native VLAN accordingly, and the customer will just need to be aware of the (potential) security risk. If the customer has security as the highest priority, then they won’t be able to use automated/scripted builds.

As for your situation, the only suggestion I can make is to set the native VLAN during installation, then change it after installation to a configuration that is more conducive to protecting VMotion traffic. Otherwise, these two goals are mutually exclusive.

Hope this helps!

http://blog.scottlowe.org/2007/11/13/esx-server-and-the-native-vlan/

Doesn’t that conflict with your advice in this column about setting the Native VLAN to one that is not used anywhere else in the network?

I’m trying to figure out how to deploy ESX via the network without exposing the network to additional vulnerabilities. Any guidance would be appreciated.

Thanks,

It highlights how a seemingly simple mechanism like VLANs to provide isolation for your migration traffic is not always so simple, which can result in people not following the best practices for security due to factors like configuration and deployment complexity. Guides like this will certainly help alleviate that problem.

Regards,
Jon Oberheide

Using the “switchport mode access” command will turn off VLAN trunking altogether. If you don’t need VLAN trunking to the ESX Server, then you certainly could do that, and it would help prevent VLAN hopping.

See also my follow-up posting:

http://blog.scottlowe.org/2008/03/07/configuration-for-protecting-vmotion/

Thanks!

Couldn’t you also setup an empty native vlan, that way you don’t have to worry about vlan hopping, ever?

like this:

no switchport native vlan
switchport mode acces
switchport access vlan ###

I’m by no means a Cisco IOS expert, but that’s what’s in our build doc for isolating particular switchports in an IBM BladeCenter.

Good point, and certainly a great way to isolate VMotion traffic for two-node clusters.

In Vmware two-node clusters I recommend keeping the vmkernel/vmotion network completely off of a physical switch whether on/off of production nets. Rather use cross-over cables between nodes, which will completely isolate the packet flows.