Cisco NEXUS 1000v on VMWARE?

[knatesan]

Hi,

Currently we have esx3.5 u3 and VC2.5 infrastructure.

let me know more abt Nexus 1000v and can i use with the current infrastructure(ie)3.5u3+VC2.5?

Which ESX ver will start support nexus1000v ?

what are the infrastructure change i have to do to use Nexus 1000v?

[roberbur]

VMware already does have a great deal of features - but what they do best is OS virtualization not switching. There's no point in VMware trying to re-invent the wheel when almost all entperprise networks are heavily invested in one of the Networking & Security leaders such as Foundry, Brocade, 3Com and Cisco. The Nexus 1000v was created through a partnership between Cisco and VMware. Allowing Cisco utilize their proven technology from within the virtualization space, allows VMware to focus efforts on what they do best. That being said we can expect other such integrations from other vendors to follow. VMware is not completely closed source application. They do have an extensive API which allows any vendor to right code for virtual appliances. VMware is typically managed by the server admins, and the Nexus 1000v will assist with maintaining the separatation between server & network admins, using a switching OS network admins are already accustomed to.

[Texiwill]

Hello,

However the basic switching functionality is still the VMware vSwitch, the Cisco Nexus 1000v is NOT a replacement, it is built on top of the vSwitch and has to live within the boundaries of the VMware vSwitch.....

But yes, this does allow for better network/server administrative split. I think others are waiting on how well the Cisco vSwitch does and how admins work with it. There will still need to be quite a bit of communication between admin types as deploying a vSwitch is still within the virtualization admins realm. While management of it is not.

But that still does not answer the question of 'what is missing from the Layer 2 VMware vSwitch?'

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[roberbur]

But that still does not answer the question of 'what is missing from the Layer 2 VMware vSwitch?'

vSwtiches are still unable to:

- implement ACLs

- implement finely tuned QoS

- leverage access control on the swtich using RADIUS, TACACS etc

- track network usage & patterns per VM in the same manner as the rest of the network devices leveraging utilities such as NetFlow

- SPAN a VM's virtual port, port group or VLAN for that matter for packet capturing

If you need more reasons I can provide them, assuming the ones above haven't already convinced you

[Texiwill]

Hello,

Yes those features do not exist, but those are all features of a managed switch, remember the vSwitch is NOT a managed Layer 2 switch and provides all the necessary functionality to perform proper switching + a bit more but unmanaged.

Hopefully the Nexus 1000V will provide some of these.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears and SearchVMware Pro Blogs: http://www.astroarch.com/wiki/index.php/Blog_Roll

Top Virtualization Security Links: http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links

[roberbur]

I would disagree. I would definately not refer to the vSwtich as an "unmanaged switch". Unmanaged switches are plug n play in a sense and have no configurable options. Wtih the vSwitch there are various bits that need to be configured in order for them to operate in the desired manner. An unmanaged switch does not allow configuring of VLANs, Fail-over, load balancing, traffic shaping etc - all of which the VMware vSwitch does offer. Just like Managed switches from different vendors the features are the only thing that differ. Just as an HP ProCurve switch will have a different set of features than a Foundary switch. The Nexus 1000v is a managed Layer 2 switch that offers nearly all the same featuers of any of Cisco's other Layer 2 switches.

[pfazzone]

Hi Edward,

One point of clarification on the following comment:

However the basic switching functionality is still the VMware vSwitch, the Cisco Nexus 1000v is NOT a replacement, it is built on top of the vSwitch and has to live within the boundaries of the VMware vSwitch.....

[

|http://www.astroarch.com/wiki/index.php/Top_Virtualization_Security_Links]

The Cisco Nexus 1000V is actually not built on top of the VMW vSwitch, but is rather a Cisco developed version of the vSwitch that runs in the hypervisor kernel and provides it's own unique feature set. You are correct that the Nexus 1000V has to run within the boundaries of the VMW vNetwork Distributed Switch API for interaction with the ESX host and Virtual Center, but it is not dependant on the vSwitch itself or bound by it's features.

As was pointed out in other posts in this thread, the Nexus 1000V provides a number of networking features that are not available currently in an ESX environment. It also offers management interfaces (CLI, SNMP, XMP API), troubleshooting tools (ERSPAN, detailed interface statistics, Netflow v.5 & v.9 collection) and security features (Port Security, Acces Control Lists, Dynamic Arp Inspection, DHCP Snooping, IP Sourceguard, Private VLANs w/ Isolated, Community and Promiscuous Trunk port options) that many enterprise, service provider, federal and military customers require to seamlessly integrate their virtual machine and physical server networking environments and operate the data center network as 1 consistent system

Thanks,

pf

-

---

Paul Fazzone

Cisco Product Manager

[TomHowarth]

Thank you for the clarification Paul

Tom Howarth

VMware Communities User Moderator

Blog: www.planetvm.net

[mreferre]

I bumped into this thread again (for some reason) and I think there is still a big unanswered question that Ed pointed out here:

ESX has minimally 4 different network security zones. Since they are not at the same level, how is this possible. If you do place them at the same level you may be at risk.

As Ed pointed out there are customers that don't care too much about collapsing everything on a couple of cables (2 x redundancy) and these are usually the small shops (which I doubt are the target for FCoE and converged network designs). Those that care about keeping the zones secured has a number of NICs that ranges from 10 to 20+ ........ and given the fact that, as far as I understand, the Nexus is not going to solve those security concerns... this would only help to have, possibly, FC + 1 of those security zones....... and it turn you would need to configure your server with something like 8->18+ regular NICs as well as 2 x Converged Network Adapters to carry FC traffic + 1 of those network security zones.

Not a real network simplification after all.

Massimo.

[RBurns-WIS]

I'll take a shot at trying to offer an acceptable answer : )

It comes down to a level of paranoia/comfort. You're concerned about collapsing various levels of security over a single FCoE link, however there seems to be a lack of concern about segementing these disparate networks by means of separate network cards? - If you ask me, the risk of having your server compromised is far more likely than having your switch comprosmied. FCoE is targetting the hypervisor host as well and HPC. If your traffic is that high security level then it should even be handled by a ESX server sharing lower security networks. In this case your should have a dedicated ESX host on the other side of your firewall.

I've pointed out the direction this technology is going and a couple points that address it.

1. Cisco's implementation of Datacenter Ethernet/FCoE will make use of TrustSec. This will secure traffic between your host & switch from MITM attacks. As I said before, if you're concerned about collapsing varying security level networks onto a single wire, you should examine if they should even reside on the server.

2. To properly secure ESX we've introduced the Nexus 1000v. A full security feature layer 2 switch. Though its a software switch you can still isolate/separate your higher-level security zones to dedicated uplink adapters if you choose.

FCoE is not the end-all & be-all and it might not suite all topologies or network requirements. However, for the majority of infrastructures its going to offer huge advantages. My hope is that rather than fear this technology continue to examine & scrutinize it, so enhancements and suggestions to make it more appealing to implement & use.

Burnsie

[Ken_Cline]

Burnsie,

Appreciate the input. I think a lot of the concern is wrapped in uncertainty. There are very few people who have actually had the opportunity to lay hands on FCoE, and even fewer who have had a 1000v connected to a CNA using FCoE as a transport medium. There also is very little publicly available documentation to allow people to develop a more thorough understanding of the solution set.

All of these items come together to cause forward-looking people to speculate and anticipate worst case scenarios. Until the technology comes out of "stealth mode" and has been in labs with spectrum analyzers and people have had a chance to "see it, touch it" in their own environments, these questions are largely unanswered.

Thanks - and please give us more food for thought!

Ken Cline

VMware vExpert 2009

VMware Communities User Moderator

[RBurns-WIS]

There will be a book publicly available at the end of March 2009:

"Data Center Networks and Fibre Channel over Ethernet (FCoE)"

ISBN: 978-1-4357-1424-3

Author: Silvano Gai

Published by Lulu.com

I highly recommend this book for those new to FCoE concepts. Though written by a Nuova Systems Engineer (Subsidairy of Cisco) it concentrates on the technology rather than solely promoting Cisco products.

Enjoy!

Rob

[mreferre]

Rob,

thanks.

I am probably personally one of the least paranoid about network security and segmentation (probably because I am not a network expert ). I continue to stress on that point because talking to partners and customers that's the concern I usually hear.

There are 3 scenarios that you could usually bump into as far as I have seen so far:

1- no paranoia: collapse all network zones (COS, VMOTION, VMs) on a single cable and leverage VLANs / PortGroups for everything

2- low paranoia: use dedicated NICs for COS, VMOTION, and VMs. VMs that are on different subnets/networks would use VLANs / PortGroups

3- medium paranoia: use dedicated NICs for COS, VMOTION, and also dedicated NICs for VMs that are on different subnets/networks (NO VLANs / PortGroups).

4- high paranoia: use dedicated ESX servers for hosting VMs that are on different subnets/networks.

The bigger the organization is, the more paranoid they tend to be. So #1 would be for the SMB shops etc etc.

As far as I can say the vast majority of customers with a relatively medium/big VMware deployment are using #2 and #3.

You might argue that, if you are so paranoid than you shouldn't even have, on the same host a mix of COS, VMotion and VMs if you really really need to separate security zones (and I agree that the server itself in this case is a potential security threat as you are bundling into a single physical servers network connections that are supposed to be either completely physically separated or separated by firewalls - I think). However this is not technically possible since each ESX host has to have VMs dedicated NICs, COS NICs, VMotion NICs etc etc.

What it is technically possible and what it is not plays a role as well. The problem of the Converged Network at the moment is that it's technically possible to maintain a certain and higher level of separation (as per #3 and #4) above. There is no doubt that it would be better to have only a couple of wires coming out the server and that's it and we would all be doing that if that was the only choice (I think).

It's a trade-off at this point between the level of paranoid you need to keep and what you could achieve if you relax it a little bit. As Ken stated the fact that this is a brand new technology doesn't help relaxing the requirements.

Is this a good summary?

Massimo.