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:

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.

8 comments:

  1. Dmitri Kalintsev19 April, 2012 12:36

    That is either overly simplified representation of the design, or um, exactly what you're saying. I suspect that what you're describing will probably look more like the diagram in the attached image. Pardon for crappiness (and I didn't include the DB layer), but hopefully it gives an idea.

    BTW I'm not sure I'm using correct network types; hopefully Massimo chimes in and sets the record straight. ;)

    ReplyDelete
  2. I think it's represented exactly as Ivan is saying. *Cough* server guy playing gwith VXLAN. *DONT_KNOW*

    ReplyDelete
  3. Ivan Pepelnjak19 April, 2012 16:51

    http://www.youtube.com/watch?v=l4JCBq1aXKE around 07:00.

    ReplyDelete
  4. I think he brushed you off pretty good! Did they ever stop or go back and acknowledge the flaw you brought up?

    ReplyDelete
  5. I'm with Dmitri that this is likely an overly simplified representation of what a real-world design would contain.

    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.

    ReplyDelete
  6. Dmitri Kalintsev19 April, 2012 22:42

    Notice gray boxes in his diagram? They are vShield Edges, just like in the one I "drew" above.

    ReplyDelete
  7. Ivan Pepelnjak20 April, 2012 09:40

    Great points. Thanks for the feedback. I personally consider firewalls (or preferably packet filters) to be a necessary hygiene like washing your hands. Not using them exposes you to unnecessary risks.

    ReplyDelete
  8. Hey Ivan, Serge here. Another way our customers stand up the multi-zone/multi-tier apps is by placing the members into multiple VXLAN/vCDNI-based networks or VLAN and connect them to the same perimeter firewall/router device (in our case Edge). Edge is no longer limited to a single outside/inside interface pair. Agreed around the static routing comment - all I can say on that front is stay tuned :-)

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.