Virtual Networking is more than VMs and VLAN duct tape
VMware has a fantastic-looking cloud provisioning tool – vCloud director. It allows cloud tenants to deploy their VMs and create new virtual networks with a click of a mouse (the underlying network has to provide a range of VLANs, or you could use VXLAN or vCDNI to implement the virtual segments).
Needless to say, when engineers not familiar with the networking intricacies create point-and-click application stacks without firewalls and load balancers, you get some interesting designs.
The following one seems to be particularly popular. Assuming your application stack has three layers (web servers, app servers and database servers), this is how you are supposed to connect the VMs:
When I’d heard about this “design” being discussed in VMware training I politely smiled (and one of our CCIEs attending that particular class totally wrecked it). When I saw the same design on a slide with Cisco’s logo on it, my brains wanted to explode.
Let’s see if we can list all things that are wrong with this design:
It’s a security joke. Anyone penetrating your web servers gets a free and unlimited pass to try and hack the app servers. Repeat recursively through the whole application stack.
How will you manage the servers? Usually we’d use SSH to access the servers. How will you manage the app servers that are totally isolated from the rest of the network? Virtual console? Fine with me.
How will you update your application code? Effectively this is the same question as above without the virtual console “Get out Of Jail” card.
How will you download operating system patches? Pretty interesting one if you happen to download them from the Internet. Will the database servers go through the app servers and through the web servers to access the Internet? Will you configure proxy web servers on every layer?
IP routing in vShield Edge (that you're supposed to be using as the firewall, router and load balancer) is another joke. It supports static routes only. Even if you decide to go through multiple layers of VMs to get to the outside world, trying to get the return packet forwarding to work will fry your brains.
How will you access common services? Let’s say you use company-wide LDAP services. How will the isolated VMs access them? Will you create yet another segment and connect all VMs to it ... exposing your crown jewels to the first intruder that manages to penetrate the web servers? How about database mirroring or log shipping?
I’m positive I’ve forgotten at least a few issues, please feel free to point them out in the comments.
Summary
Just because you can design your virtual application stack with a mouse doesn’t mean that you can forget the basic network design principles.
It doesn’t matter if you use VLANs or some other virtual networking technology. It doesn’t matter if you use physical firewalls and load balancers or virtual appliances – if you want to build a proper application stack, you need the same functional components you’d use in the physical world, wired in approximately the same topology.
More information
If you need to know more about data centers, network virtualization, and cloud computing networking:
- Start with Introduction to Virtualized Networking;
- Discover generic data center technologies and designs in Data Center 3.0 for Networking Engineer, data center fabric technologies in Data Center Fabric Architectures, and the large-scale designs in Clos Fabrics Explained webinar.
- Learn more about the technologies you can use to build a private or public cloud infrastructure in the Cloud Computing Networking webinar.
- Dive deep into the mysteries of VMware’s vSwitch and other VMware-related networking solutions with the VMware Networking Deep Dive.
And don’t forget: you get access to all these webinars (and numerous others) if you buy the yearly subscription. Finally, you can always ask me to review your design.
BTW I'm not sure I'm using correct network types; hopefully Massimo chimes in and sets the record straight. ;)
And, with all due respect, I think the security issues you bring up follow more from us winning the battle (stateful firewalls!) and losing the war (oh, all the exploits come inside straight HTTP, or SQL, oops). Also, in a modern server environment, it's not necessarily a good assumption that applications are deployed or updates are applied to live VMs; some of us design applications to allow us to throw away and replace VMs rather than update/fix them in place.