When Eight May Not Be Enough for Virtualization
Eight Is Enough was an American comedy / drama that ran from 1977 – 1981. See http://en.wikipedia.org/wiki/Eight_Is_Enough if you are oddly curious. You may not share my vintage or decided to be productive during those years, but the metaphor relates to interface requirements for VMware hypervisor implementations.
The foundation for private or public clouds is virtualization. This blog entry focuses on the network interfaces used to build a topology for VMware. Specifically, VMware has the concept of port groups and vswitches ( http://www.vmware.com/technical-resources/virtual-networking/ [url reference if you want more detail]). There are many reasons and combinations to choose from relative to this implementation. I will comment on some of them next.
Security and VLAN hopping. VLAN hopping is a mechanism where a hacker creates a double-tagged packet and has access to a trunk port – as many VMware implementations will if you use VST mode. The key has to do with a compatibility requirement for 802.1Q where there must also be a native VLAN on the port (i.e. A mechanism to transmit untagged packets). The switch removes the first tag and forwards the traffic along, but it leaves the second tag in tact. The next hop allows the packet to transfer to the hacker’s destination VLAN.
Many VMware blogs and experts say the only way around this is to create separate vswitches to isolate traffic. By the way, this is an old attack and there are simple ways to avoid this situation. Please take a look at the following url for more information:
Physical interfaces must be dedicated to a single vswitch. This keeps traffic isolated in a physical manner. This physical configuration requires additional cabling, adapters, possibly larger servers, and certainly more cabling and network ports. The other thing to remember is that each vswitch is going to attach to an upstream switch that uses VLAN’s for isolation, so there is potential exposure regardless of the hypervisor configuration.
Please look at the Cisco Systems Nexus 1000v url (http://www.cisco.com/en/US/products/ps9902/index.html), if you want a complete look at how this can be deployed in a product that works with any VMware qualified server.
Still not convinced you say; I must have separate vswitches; Where is the link to this articles title? The purists and dare I say zealots may still hold the belief that the VLAN techniques are inadequate for security (I am certainly not suggesting that the url above is complete security, but merely comparing it to vswitch isolation) and demand separate vswitches with physical interfaces dedicated to each vswitch. Let’s play this out further.
Many servers will be delivered with two ports of 10GE and then you need to create your IO pipe to the network from the hypervisor. Some implementations support up to 8 logical interfaces in a blade server, carved up into 4 interfaces per IO bay, and only using two physical ports. So is eight enough?
Assume the following redundant vswitch configuration:
IP storage (separate from vmk)
This configuration, if redundant, would require 10 IO paths and 5 vswitches. In this case, eight is not enough for virtualization. That could be fixed by purchasing more mezzanine cards, more IO modules, and more physical infrastructure, but maybe unnecessary and most likely not a requirement based on performance – just due to physical and logical constraints. Interesting to me is that these topologies never speak to separating or isolating production traffic. In a multi-tenant environment this would be an important consideration, but that is a topic for another blog entry.
Can we get both – absolutely. The Cisco Systems Unified Computing System M81KR Virtual Interface Card (http://www.cisco.com/en/US/prod/collateral/ps10265/ps10276/solution_overview_c22-555987_ps10280_Product_Solution_Overview.html) supports 128 virtual interfaces per adapter and they can be Ethernet or FC. This technology allows many redundant vswitch paths from a single ESX instance and it does not require additional hardware to support the environment described here.
Either topology discussed will work with the Cisco Unified Computing System and / or the Cisco Nexus 1000v, so the choice is yours and you can answer the question – Is Eight Enough for Virtualization?