Barton Spring, Austin, Texas: It’s open air pool which I swam in 2001. It’s relevance to this article is zero. But i was looking for image about pools. Just loads of photos of peoples pools attached to their house. So I remember the open air pool in Austin. One of the highlights of my 3 month trip around the US in 2001….
Over the last couple of weeks I’ve been working through the requirements, configuration and management of network pools. So far I’ve largely focused on the technical requirements of each method, without really reflecting on the implications for the cloud or for adoption of the software-defined datacenter. You know you can sometimes get so down in the weeds with the technical aspects, that you loose sight of the wider goal. I thought this post would give me chance to step back a little. With that said I think I will find it personally useful to review all the options – together with what I perceive as their advantages and disadvantages. As I do that want to talk more generally about networking, and the way we do it now, and some of the barriers to adopting new methods. That’s because these network pools and different ways of setting them up lie at the heart of the software-defined networking project. It strikes me that ANY method used within vCloud Director could be reacted to negatively by your network teams. That’s because at the heart of each method lies a request for them to do something differently or enable a feature/setting they may never have configured before. In my view the politics is inevitable – because all change is political. So you either compromise and take the ‘least line of resistance” approach, or else you stick to your guns and go for the method you perceive as being the most desirable.
VLAN Backed Network Pools:
In this model you create a whole series of VLANs on the physical switch, ready for them to be consumed by the vSphere Distributed vSwitch. For me the VLAN pool approach is no different to setting up a DHCP server to issue IP address. If you think about it the principles are the same. You create a range of resources (VLANs or IP address) to easy the configuration and setup of either new networks or new clients on the network. No one appears to have any problem with using DHCP to do this, and I’ve come across a number of customers who use DHCP as method of IPing not just clients but servers as well – with client reservations to a MAC address. It means you end up with an automated, almost fool-proof way of configuring TCP-IP which is becomes so endemic that you almost forget that it is there. I would find it weird to find a company still statically assigning addresses to client devices in our modern multiple device world. You define range of VLAN IDs behind the pools – which are then consumed dynamically as when they are needed. That means blocks of VLANs being assigned to the physical switch upfront, to be used and re-used at some other point in time.
In my short experience the network teams are somewhat nervous about this VLAN pooling because they perceive (wrongly in my view) VLANs as a “security boundary”. Thus having people plug into what they like, when they like – seems to undermine the network teams confidence because fundamentally their control seems threatened. The funny about this idea that VLANs represent a security boundary to me seems pretty bogus. Remember that VLANs are a software construct (albeit defined in the firmware of a physical switch – something I’ve started calling hardware-defined software!) and their originally intention was to allow the segmentation of the network to reduce broadcast traffic – rather than having to physical separate the environment. The use of VLANs has appeared to have evolved out of this concept – you could say that corporate networks have created a VLAN-sprawl. I was talking with customers the other week where this came up as an issue. Both seemed to indicate that the volume of VLANs they had were becoming a headache. However, they seemed unwilling to entertain another approach (say vCD-NI or VXLAN) as this was regarded as “insecure”. Yes, that’s right despite the debate we looped back again to the VLANs as security view of the world. With that said in some IT shops some may might take the view that the need for new networks is relatively small, and the existing process needed to setup a new VLAN is perfectly serviceable.
I think there’s a couple of arguments you can make in favour of this approach in an effort to make it more palatable. Firstly, provisioning of anything be it VLANs or LUNs is boring, mundane task. If your networking or storage person there’s stuff you can do that’s infinitely more interesting. I can imagine nothing can be more tiresome to network or storage person to be constantly harassed by virtualization folks like me for new resources. So….. why not create these resources upfront. Put the controls in place in once – and let us get on with it? It frees the network team to do proper value-add work, the alternative is like being an Active Directory Admin and doing password resets/unlocks all day. Secondly, there’s probably a very good chance that that the requirements need to make VLAN-backed network pools work are already in place in your virtual world – VLAN Tagging. So for me if you taking the “least line of resistance” approach to bring in a more pooled/on-demand/dynamic networking this might be the way to go. The nice thing about it is once the VLANs are in place – your free to create Organization and vApp networks of your own design without automatically needing to refer to the network team. It lies within your scope of management. Oh, and whilst you asking them to create pools of VLANs, ask them to increase the MTU to 9000 bytes – that way you can use vCD-NI without telling them. [Joke! Or is it? Remember those case where people gave application owners VMs without telling them?]
Portgroup-Backed Pools:
This method uses the Standard vSwitch and is handy if you don’t have access to the Enterprise+ Distributed vSwitch. Personally, I think vCloud Director without Enterprise+ is like having Ferrari with a Fiat 500 engine. Not to be recommended. Where this approach becomes interesting is where the business has decided to use the Cisco Nexus 1000V in preference to the Distributed vSwitch – and they have a highly-automated method of creating portgroups on the Nexus in the virtual world, and VLAN on their Cisco (Nexus?) switches in the virtual world. There’s element of self-service here, but just like the VLAN backed method a whole lot of pre-provisioning has to be done upfront before the tenant can consume the resource. The configuration of this is likely to reside outside of the virtualization/cloud admins privileges in a lot of cases. So your giving the network team MORE not less say in how networks are provisioned up to tenants in their Organization.
vCD-NI Backed Pools:
Network Isolation backed network pools need at least one network or VLAN, and the MTU to be increased to 1524 bytes or higher. I think in these cases where an MTU increase is required you may as well config to the maximum that the switch supports in most case 9000 bytes. This another request to the network team beyond the normal VLAN tagging and creating VLANs. What is great about vCD-NI pools is they allow for many networks to co-exist with the same VLAN, and allows for vApps to be segmented in their own networks – say in a Test/Dev environment without needing to create a VLAN for each every thing you do. In large environments it help prevent exhausting the total number of VLANs needed, and stop development folks having to re-IP all their applications to aviod conflicts. If your looking for analogy for vCD-NI I would compare it to a NAT. You could buy a valid Internet IP address very every device on your network that needs internet access. I’ve been to sites in the 90’s & 00’s where this happened. Usually, some Big Corporate with an entire ClassA range at its disposal. The sane amongst us buy a small amount Internet IPs and use them against firewalls/proxies/NAT that allows many clients with ordinary 10/172/192 ranges access to the Internet. With network overlay you able to have many networks using just one network or VLAN. You keep your VLAN footprint to a minimum, whilst allowing vApp users within the Organization the ability to have their own network.
The only challenge I perceive of vCD-NI is only an ESX host knows how to handle the mac-in-mac encapsulation. So if you don’t plan your networking carefully, and vCD-NI “tagged” packet hits generic Ethernet device like a firewall or router it won’t know what to do with the frame. The chances of that happening I think are slim. Although you can take an Organization in vCD and directly connect it to your network backbone if you wish – you’d need a very large IP space to contain all the Organizations doing this – and they would be able to see each others traffic. Thus breaking Isaac Newton’s First Law of Multi-tenancy. If we don’t allow this sort of comms to happen then its not a problem.
The real “challenge” I see with vCD-NI is it might be regarded as “voodoo networking” to the network teams. Just like our application owners thought “virtual machines” were voodoo technologies. Loads of VMs running on the same server under a “hypervisor”, surely they said that’s insecure or will deliver poor performance. Right? Wrong! This goes back to the VLAN as security view of the world again. Remember the VLAN is as “software defined” as vCD-NI is. As for security, I know this going back some years but I recall there was exploit called “VLAN Flooding” which could undo all the security. Of course all that’s a thing of the past fixed with firmware updates. That’s is something that pleases me.
I used to get asked when I was freelance/independent instructor “How secure is VMware?”. I used to answer with two facetious responses a.) very or b.) as secure as tomorrows security patch. My point being measuring how secure something is qualitative judgement, its probably better to ask how well configured it is – given that most security loop holes come not from badly written software, but security configuration principles not being followed [OK. I admit there are lot of security software bugs in our industry]. I used to say that given most security bugs reside in multi-purpose OSes (Windows, Linux, Solaris, Novell) we install in VM that is probably this layer where you security should focus. After all attackers go for the weaker sister. That doesn’t mean you can be complacent with hypervisor security – but really your virtualization vendor should take care of the bulk of that where possible [Yes, I know there is a vSphere hardening guide!]. But putting that aside I’ve always felt security isn’t absolute. It’s game of cat and mouse. Where we play role of the cat and the bad guys play the role of the mice. They are always trying to stay one step ahead of them, but their are more mice than cats. So they statistically they likely to gain win on us every so often. It’s a bit like terrorism and national security. We have have be vigilant ALL the time, the terrorist only needs to be lucky once. If they find a loop hole we have to move quickly and efficiently to close of the mouse hole. So it will always be with these debates around new networking mechanisms. Are they secure? Yes, as secure as your firewall configuration and your VLAN configuration that allows them to operate. You could take the view that an exploit of vCD-NI network takes place, its likely some other much large breach has taken place elsewhere. Whilst the cats away, the mice play – as the saying goes.
VXLAN Backed Network Pools:
VXLAN Pools require a Distributed vSwitch, an MTU of 1600 or greater and support for multi-cast between the VLANS that may use VXLAN for network communications or network overlay. In many respects I see VXLAN as another form of network overlay within vCD. So in vCloud Director you now have two methods of segmenting the network. In short while there will be a Nicera method as well. VXLAN supports 16m network IDs within a single VXLAN enabled VLAN/network. So there’s bags of scalability, plus its a method which is likely to get wide support from industry vendors. I suspect it won’t be long before have VXLAN offloading on physical NICs and VXLAN enablement on physical switches. That’s important not just for performance reasons, but also for wider adoption. If your the network team’s main network provier is talking VXLAN support then I would hope that when the discussion is had its not some feature/function that is some shockingly new shinny toy. Plus if the message about VXLAN is coming from their demographic (the network vendor) rather than from our side the fence, they maybe somewhat more receptive to it. For me the work on VXLAN is similiar to the work done with the storage vendors on API’s like VAAI/VASA. It’s about making these layers of abstraction aware enough of each other – just enough to drive performance or management that returns benefits – whilst still maintaining separation in the stack itself.
Some Nebulous Thinking: (Hey, that sounds better than “Cloud Thinking”)
Anyway, that’s round up of requirements both technically and politically it leads me to thinking about software-defined networking. Firstly, its not really as “new” as perhaps we all think. VLANs have been around for sometime, and they are defined in the software of the physical switch. The trouble is that this type of software-defined networking has only, can only take the datacenter so far. If were going to be living in this more on-demand/self-service environment with oodles of flexibility, its certainly isn’t going to come from layer in the stack that requires a change request and endless beard fondling. Secondly, the scalability of the VLAN isn’t going to stack it against these mega-datacenters that are being built in the world of the public cloud. If you attended the VMworld events and did a hands-on-lab, you were using VXLAN. According to folks I spoke too, one of the issues we’ve had is running out of VLANs in the HoL. vCD-NI and VXLAN have been recruited to address this issue. Thirdly, I don’t think going to be just one “software-defined” networking – but a range of different standards with different requirements. The question will be – which will make cut and become the dominant method (the no-one got fired for using X software-defined networking straitjacket-mentally that pervades and dogs our industry). I see it as more competitive situation as opposed to the more cosy-cuddley “providing choice for customers” view of things. Although I think if that does happen then it will mean customers will need to trade of the technical requirements against the politics of making the change.
Although there’s always room for choice in our industry, things progress as much through competition as anything else. So in that spirit there’s couple of points to be made about what VMware is doing re network overly/virtualization that sets us apart. That involves scrolling up this blogpost where I talked about how whilst vCD-NI is great technology, and it’s frames are only understood by the vSphere host. So how does that work with the wider network? The answer is via the vCNS Edge Gateway (aka vShield Edge). It might surprise you that whilst other vendors may offer network virtualization, they are often dependent on support from their 3rd party partners to the manage the traffic beyond the perimeter of the virtual network. That’s quite important because it is one thing to be able to do network virtualization, but quite another if it can only be used for internal traffic only – and to use it externally you need specific hardware support/firmware support to make it work. That’s quite different from working closely with network vendors accelerate and optimize network overlay, rather than just getting it out of the box and working.
It’s an often trite statement that folks trot out about SDN and SDS (software-defined networking/software-defined storage) that “were going to do the network what VMware Virtualization did for servers”. I guess this phrase is a kind of useful short-hand to get a simple message across. But it rather belies the complexity and nuance of the realities that lie below. Server Virtualization and ESX/vSphere became the dominant platform because is saved people money – because it drove levels of efficiencies in terms of hardware utilization that could not have been available in the bad old days of physicalization. To some degree (although its early days yet) I think the SDN model is trying to do the same way, but in concert with other developments at the physical world namely network IO or network consolidation. I think if you bring network consolidation and SDN together the two technologies serve to amply each others benefits. Network consolidation collapses the physical backplane into a much simpler model for both networking & storage. So network virtualization is nothing like server virtualization. Is not as if there is rack upon rack of underultized physical switches, like there was servers. But I do believe the sort of multi-tenancy model envisioned by the cloud is not deliverable with tin, and if we did try to deliver software-defined networking with physical equipment then there would be lot more physical switches, routers, firewalls to manage… So perhaps the way forward is letting the hardware deal with the presentation of the “hardware” – with things like HP’s Virtual Connect and Cisco UCS’s CNA – being able to dice-N-slice the pipe into many “virtual nics”, but perhaps the “partitioning” of the network from logical perspective is best done in close proximity to where the consumers are – in the cloud.