VMware Cloud Community
knatesan
Contributor
Contributor

Cisco NEXUS 1000v on VMWARE?

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?

Reply
0 Kudos
31 Replies
TomHowarth
Leadership
Leadership

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?

You can not use the Nexus with the ESX 3.5 version, it is only for the next genteration ESX version 4.0 currently in Beta

Which ESX ver will start support nexus1000v ?

See above answer

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

When ESX4 comes out, you will need to use the DVS (distrubuted Virtual Switch( Not A Beta spoiler as this is public knowledge))

That is as much as you will get, as the rest is subject to NDA

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Texiwill
Leadership
Leadership

Hello,

The VMworld presentation on the Nexus stated you do not need to use the Distributed Virtual Switch, that you can use it, plus normal virtual switches. This depends on the vNetwork switching fabric more than anything else.


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.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Rodos
Expert
Expert

You will also need to purchase it. From whom, how and how much are all open to speculation.

Rodos

Considering awarding points if this is of use

Rodos {size:10px}{color:gray}Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/{color}{size}
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

In talking to the Cisco folks at VMworld, you would need to purchase it from them.


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 Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
Rodos
Expert
Expert

That was my information to. I just could not remember if I heard it under VMware or Cisco NDA so if you heard it on the floor then its public, not that its to hard to figure out. But you neve know VMware may be making a strong case that they may sell more if they are allowed to add it to their own price book too.

Whats going to be really interesting is the integration piece. To what advantage will their be having some physical Nexus boxes behind this .... um I am dreaming of that Nexus 5000 getting powered on in the lab.

Considering awarding points if this is of use

Rodos {size:10px}{color:gray}Consider the use of the helpful or correct buttons to award points. Blog: http://rodos.haywood.org/{color}{size}
Reply
0 Kudos
RBurns-WIS
Enthusiast
Enthusiast

There is no infrastructure change to use the Nexus 1000v. It will be installed onto each ESX host and will operate just as any other Cisco switch. It's not indended to replace vSwitches, but rather to compliment them. You'll still use vSwitches for your Service Console etc.

As stated, the first release of the Nexus 1000v will be with ESX 4.0 & ESXi 4.0 due to release in May 2009.

Reply
0 Kudos
RBurns-WIS
Enthusiast
Enthusiast

You'll still want your Nexus 5K series behind your ESX hosts to support 10Ge or FCoE. There will be a huge move in the upcoming year for companies to adopt FCoE especially when ESX servers are support 3+ networks and up to 6-8 NICs per host. The cabling consolodation and power savings will also be a big push for FCoE.

There's no better product than the Nexus 5K for accomplishing both these objectives.

Reply
0 Kudos
TomHowarth
Leadership
Leadership

The jury is still out on network convergance and consollidation in my opinion, VLAN's just do not cut it form a security point of view. there are currently at least 5 know VLAN vunerabilities. and now you want to add your FC on to the same cables

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Reply
0 Kudos
RBurns-WIS
Enthusiast
Enthusiast

Convergence & Consolodation using FCoE has nothing to do with VLANs. We're talking about Fiber Channel, and Ethernet using the same medium. From the host side they're still on separate adapters (logically) though they flow threw one (or two) physcial CNA adapters. The vulnerabilities are going to exist amoung each protocol regardless of which physical cable it flows through. Priority flow control which is handled by the switches will handle storage and IPC traffic with little/no latency.

I will agree with you that many people are skepticle about the concept of FCoE, but its not far off from the advent of using VLANs and trunks to carry multiple logically separated LAN traffic. Just like any other switch you can implement all your ACLs and security measures so not much has changed at the end of the day.

Reply
0 Kudos
TomHowarth
Leadership
Leadership

other than moving one more set of highly important data the other side of the wire.

Tom Howarth

VMware Communities User Moderator

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Reply
0 Kudos
RBurns-WIS
Enthusiast
Enthusiast

Well being the VMware Group moderator I can only assume you put enough faith in technology to put multiple "highly important" servers on the same ESX host..... ? Smiley Happy

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I will agree with you that many people are skepticle about the concept of FCoE, but its not far off from the advent of using VLANs and trunks to carry multiple logically separated LAN traffic. Just like any other switch you can implement all your ACLs and security measures so not much has changed at the end of the day.

FCoE is not a bad thing in itself, however VLANs do not provide security, they provide a way to tag data to ensure delivery to the proper port within a switch without collisions and possible data loss.

You also mention 'multiple logically separate' which is exactly what a VLAN does, it is logical not physical. You still have data comingling on the wire and due to this the 'trunk' is always a higher risk location than where there is no data comingling on the wire. Use of VLANs is a trust issue more than anything else. You need to know if your physical switches mitigate the current VLAN attacks or not. If they do, then great go for it. If they do not, then you need to be aware that the target of such attacks is the physical switch and that you need to plan accordingly.

Is FCoE going to be fully encrypted? Is FCoE going to support pre-shared keys? There are lots of little issues to be answered from a security perspective before I decide to comingle any of my management, storage, VMotion, and DMZ data.


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.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
mreferre
Champion
Champion

I suggest we create a couple of groups on Facebook such as "those that hates VLANs and don't trust them at all" and "those that loves VLANs and think that they fit a purpose"......

It would be interesting... Smiley Happy

Massimo.

Massimo Re Ferre' VMware vCloud Architect twitter.com/mreferre www.it20.info
Reply
0 Kudos
TomHowarth
Leadership
Leadership

Massimo

I have no issue with VLANs persay, I do however have issues with lowering a secure network environment for the sake of it Smiley Wink they do have there place and that is in areas for similar secruity standings.

I would argue that a Management LAN has a higher risk of being attacked and as such merits a seperate segement. you would not put your DMZ traffic on the same trunk would you??

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth

VMware Communities User Moderator

Blog: www.planetvm.net

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I have no issues with VLANs either, however the claim that "VLANs provide security" is an issue. They do NOT provide security. No where in the RFC for 802.1q does it state VLANs provide security. They have their uses, and knowing the limitations will help to design safer networks.


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.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
RBurns-WIS
Enthusiast
Enthusiast

When looking at FCoE no one "should" ever suggest trying to throw different security level LANs on the same wire (Corporate LAN, DMZ ect), but I do see a great fit for servers within the same secure subnet such as ESX servers. VLANs are not secure and we're all in agreement there. Are trunks less secure that access ports - No. Are they a higher risk - of course. Discussing the security of Trunks vs. Access ports is a different topic altogether. I would argue that carrying Fiber channel & Ethernet traffic over the same medium is not much greater a risk as them being physically separate on different wires. FCoE switches (at least the Nexus Series) will discard any FC frames that the Fabric doesn't have in its database. All the securities FC has will be present in FCoE.

If your worry is with utilizing Trunks, FCoE will provide no security additional assurances other than those that are/are not present. This may change as the standards mature. Hopefully you're using firewalls, NAC, IPS, IDM, and other security devices/software to keep your networks safe & secure. I don't think the paranoia of being attacked should overshadow the benefits or adoption of new technology. No matter how secure we think we are, malicous attacks will always be present. Show me one enterprise network that has avoided deploying trunks in their network and I'll stand corrected. It hasn't stopped administrators carrying multiple VLANs on the same wire and neither will FCoE...

I appreciate the security comments though. We're trying to get an idea of where people stand on the FCoE issue.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

When looking at FCoE no one "should" ever suggest trying to throw different security level LANs on the same wire (Corporate LAN, DMZ ect), but I do see a great fit for servers within the same secure subnet such as ESX servers.

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.

  • Administrative/Management Network.... Also used for iSCSI CHAP authentication. - Access to this could give access to everything depending on other security constraints.

  • VMotion networks.... A cleartext network of the in use memory image of a the VM. This could give up credentials, SSN, CC#, etc.

  • Storage Network.... Other than iSCSI CHAP, all data flows over this unencrypted in many cases. FCoE would fall into this category

  • Virtual Machine Network.... Well this one encompasses DMZ, Production, QA, Test, etc.

Which one of these is at the 'same security level' within ESX? That is the problem, people consider them to be the same when they really are not. The conscious choice needs to be made on which of these to combine onto one cable. Some combine all, other combine the first 2 and some combine the first 3... Any combinations whether at the vSwitch or the pSwitch add risk. How much depends more on the data than it does on the network.


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.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
virtualesxer
Contributor
Contributor

There is no infrastructure change to use the Nexus 1000v. It will be installed onto each ESX host and will operate just as any other Cisco switch. It's not indended to replace vSwitches, but rather to compliment them. You'll still use vSwitches for your Service Console etc.

And I say it's still a bloody shame that vSwtches currently do everything but actuallly act as a switch! And even more of a shame, that, apparently, in Vmware 4.0, we'll still be dependent on a third party tool to get the job done.

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

The vSwitch provides a Layer 2 Switch. Nexus 1000V builds on that to provide some more functionality, not a lot but some more. Not sure why you claim the vSwitch is not a switch..... It is not a Layer 3 switch, and actually neither is the Nexus 1000V from what I have seen.

What features do you want?


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

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos