Cisco Pushing More vNetwork into Hardware

In the first Virtualization Security Podcast of 2011, we had Brad Hedlund with us once again. Not to talk about the Cisco Virtualization Security Gateway (VSG), but about the security of what I call physical-virtual devices that provide network virtualization within the hardware. Or what Brad Called Network Interface Virtualization (NIV). Cisco has taken its VN-Link technology to extend the networking of a VM directly into the core switch when using vSphere.Brad Hedlund is a Solutions Architect at Cisco Systems and a proponent of using physical hardware to solve virtual networking issues. This is also what Cisco wants to happen. The more virtual functionality they can move out of the hypervisor, the more physical devices they will sell. This makes complete sense, but was not the thrust of the conversation on the podcast. The thrust was, is this really a secure mechanism or approach. That is using Physical-Virtual devices and the security of such devices. In our discussion we concentrated on two classes of devices: The ones provided by Cisco UCS and the ones provided by HP. Each of these devices behave differently. In my article “Blade Physical-Virtual Networking and Virtualization Security” I displayed an image of an HP blade enclosure. The big difference between Cisco UCS and HP Flex technology is that Cisco uses a fabric extender instead of of a layer-2 switch within the chassis. This fabric extender pushes layer-2 decisions through a Cisco Nexus 5000 to a Cisco core switch such as Cisco Nexus 7000.  It does this using its VN-Link technology which allows a switch to be authoritative about what VMs are connected to it.
Whether you use the Cisco UCS physical-virtual NICs connected a fabric extender or you use the HP physical-virtual NICs connected to a physical-virtual layer-2 switch, your virtual network ends up within the physical switch hardware at some point. Brad’s argument was that having a single Cisco Nexus 5000/7000 to maintain is much simper than maintaining per chassis layer-2 switches. It is, but as Iben Rodriguez, one of the other podcast panelists, some form of automated tool should be used to maintain switch configurations through out the environment. Such a tools is RANCID which allows you to see differences from the set configuration of your Cisco switches.
At the moment, however, while the physical-virtual hardware is in use, we cannot ignore the virtual switches in use as their configuration also comes into play. If you use the Nexus 1000V then RANCID will also work with it. The network path is currently still from vNIC to Portgroup to vSwitch to physical-virtual NIC to fabric extender/physical-virtual layer-2 switch and then a layer-2 switch. However, Cisco is working with VMware to change this so that you can go from VMware’s VMXNET3 device direct to the fabric extender. Thereby bypassing the vNetwork components completely. This once more flattens and moves all networking to the hardware layer. Which implies that all network security would move out the virtual network and back into the physical network.
We discussed if there is a real need for increased security when using physical-virtual devices and there may not be as they are all uplink technolgies requiring you to uplink to another switch entirely and never to a host except on the virtual side of the device so any MiTM attacks would have to come from the virtual side of these interfaces and not the physical side. This implies improved security but once more flattens your network. Which in itself may not be a good approach due to the need for multiple security zones specifically within the cloud. Yet, use of Cisco VN-Link technology allows the switching fabric to be authoritative about the VMs connected to it, which will improve over all security. Will this become the next networking standard adopted by all switch companies? Will the flat network work in a cloud environment?