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.

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.

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.

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

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.

Thank you for the clarification Paul

Tom Howarth
VMware Communities User Moderator
Blog: www.planetvm.net

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