vCloud Director 1.0.1: Networking Samples

This is a repost from Massimo’s personal blog, IT 2.0– Next Generation IT Infrastructures.

My old vCloud Director Networking for Dummies post is still going strong according to my blog statistics. I believe  this is an indicator that people are looking for more information about  this topic so I thought I’d give it a little bit more color and create a  few real life examples on how this theory works in practice. I suggest  you read the Networking for Dummies post linked above before you dive  into this one.

Note  also that the other post as well as this one are based on vCloud  Director 1.0.1, which is the latest release available as of June 2011.  Things may change in the future so, if the vCD release you are using at  the time you read this is above 1.0.1, chances are that things could be  slightly different. I can’t really say more than that at this point.

Last  but not least, everything I will be doing below can be done as a cloud  consumer in self-service mode. As a matter of fact I will be doing  everything as an Org Admin.

Introduction

To walk through an actual implementation of the networking stack I’ll use my IT20 organization hosted in the Stratogen cloud.  This discussion starts with the description of the networking plumbing  in my vCloud organization. From the vCD UI it looks like this:

From a logical perspective it looks like this:

My Org has four public Internet addresses that Stratogen associated to my “Routed Network” when they created the tenant. For security reasons I am not going to widely advertise them in this post.

You can see these assigned addresses if you right-click on the Routed Network and select “Configure Services“:

The  last piece of the puzzle is three vApps I have created in this Org and  that we are going to connect to the various networks you have seen  above. This is supposed to give you a practical idea on how things can  be configured. The names of the vApps should be self-explanatory.

Direct Internet Connection

Let’s  start with the most simple of the networking scenarios. Note there is a  vApp called “Turnkey_Internet” which is comprised of a single VM. That  VM is connected to the “Direct Internet” connection available  in my Org. I have only one comment for this example: scaring! Never do  this because you are in fact plugging your VM directly into the Internet  without any level of protection (other than what you could have inside  the Guest OS of course).

This is how my VM is configured:

And this is how the VM fits into the logical network view:

The way this works is pretty straightforward and, if you read the vCloud Director Networking for Dummies post, it should be explained there. Basically the cloud administrator  has configured a pool of available IP addresses for this “External Network”  (since this is a vSphere PortGroup with native Internet connectivity  this pool will contain native Internet IP addresses). Since the Direct Internet connection in my Org is nothing more than a pointer to this vCD External Network which in turns is a pointer (with metadata) to the PortGroup backing  it, the result is that the vNIC of my VM gets connected directly to this  PortGroup. vCD assigns the (vNIC) an IP in the pool.

I  am glad Stratogen configured this network for me – as it is handy if  you are experimenting with vCD networking – but in a real life scenario  you would never want to connect VMs to a connection like this (directly  connected to the Internet). However this may become pretty interesting  if you, as an Enterprise, are using virtual data centers hosted in a  cloud where the Service Provider has configured an MPLS connectivity  back to your headquarter. Something like this:

It goes without saying that, in doing so, you are effectively dedicating an External Network (and in turn a PortGroup) to the IT20 Org. If for any reason you give access to another Org to the same External Network (either <Direct> or <Routed> – see next section) you are  essentially giving the other Org access to the IT20 MPLS network.

Routed Network – single-tier vApp

This  is where things start to become more interesting, slightly more  difficult to explain and accomplish at the same time. I have another  vApp that is called “Turnkey-Routed”. It contains a single VM that is  connected to the Routed Network available in the IT20  organization. You can imagine this Routed Network as a dedicated layer 2  segment protected by a firewall device (vShield Edge). For more  information on how this work from a vSphere perspective read the vCloud Director Networking for Dummies post. Essentially the VM in this vApp gets assigned an IP address  available in the pool defined for this layer 2 segment. This is how vCD  shows the details of the Hardware Properties for this virtual machine:

And this is how it logically fits into our diagram:

Note  that in the diagram above we went a couple of steps forward. Not only  we are protecting the VM with the Edge: I have also configured the Edge  to NAT the private IP. To do so I have created a one-to-one mapping rule  to one of the four Internet addresses Stratogen assigned to me. I have  also configured a firewall rule to only allow traffic on port 12320 to  reach the VM (this is because the Turnkey appliance uses particular  ports to get access to SSH and web admin interfaces). How did I do this?  Move onto the Routed Network and right-click on Configure Services. Point to the “External IP Mapping” tab and configure the NAT rule:

You would then point to the “Firewall” tab where you can configure the firewall rule I have described above (as an example).

I have just blocked all traffic coming into this VM except for traffic directed to port 12320. Easy.

Routed Network – multi-tier vApp

The  single-tier vApp is still pretty simple. Let’s now focus on the third  vApp I have mentioned. This is the “2Tiers” vApp, which is comprised of a  front-end Windows VM (Win-Web) and a back-end Linux VM (REHL-DB). The  idea is to provide IT20 customers with access to this application  protected by multiple levels of security. The first step is to connect  the front-end to the Routed Network in the Org and NAT it. This is  similar to what we have already done with the single-tier vApp discussed  above. I am not going to show screenshots of the NAT and Firewall  configurations because the steps are very similar. It goes without  saying that the Win-Web VM has a different private IP and I will be  using another public IP to create the DNAT rule. This is how the logical  layout looks like for this specific vApp. I am opening port 80 for this  example:

As  you can see the back-end VM is not yet connected to any network. As I  said we want to provide an additional level of security for that VM and  we don’t want to connect it “directly” to the Org network. How do we do  this? This is where the so called “vApp Networks” come into place. You can imagine vApp Networks as layer 2 network segments dedicated (and only available) to the specific vApp they have been created for. In other words a vApp Network created for one vApp cannot be used by any other vApp. If you want to know more about this concept please refer again to the vCloud Director Networking for Dummies post.

You can create vApp Networks in multiple ways but the easiest one is to click on the “Add Network”  choice in the drop-down menu for the vNIC connectivity available in the Hardware Properties of the VM:

Selecting  it kicks off a brief wizard that asks you the very basic metadata to  create a new network (Subnet Mask, Default Gateway, IP Pool etc). You  can then select whether you want to protect this dedicated vApp Network with NAT and Firewall functionalities. You can do this in the Networking tab when you “Open” the vApp:

Let’s pause for a second here (too many screenshots to digest).

Don’t be fooled. What we are trying to do is to create a logical layout like the one depicted below:

In a way we are applying to this vApp Network the same NAT and Firewall principles that we applied to the Routed Network at the organization level. Where do you configure these rules for the Edge device that is backing this vApp Network? Easy. Look at the latest screenshots above and click Details. Done.

This  is the tab where you configure the NAT rule so that the DB private IP  gets mapped to the Routed Network in the organization:

Below is the tab where you configure the Firewall rule to allow DB traffic only (this rule is just an example):

Conclusions

Let’s  now try to put all these pieces together and look at how the logical  layout of the workloads running in the organization looks like as a  whole:

As  you can see the self-service networking stack in vCloud Director is  pretty powerful and flexible although there are certainly things that  could (and should) be done better. For example you may argue there is a  lot of NATting going on (and I would have a problem arguing the  opposite). But, as we said, this post is based on the 1.0.1 version of  the product and things may change in the future.

Note that we haven’t covered any example on how to use the “Internal Network”  since it should be pretty straightforward. It’s basically a flat layer 2  network that doesn’t go anywhere and only allows VMs attached to it to  communicate to each other.

I hope you found this post useful. I’d like to get your feedback.

Massimo currently works as at VMware as a Staff Systems Engineer, vCloud  Architect. He works with Service Providers and Outsourcers to help them  shape their Public Cloud services roadmap based on VMware cloud  technologies. Massimo also blogs about Next Generation IT  Infrastructures on his personal blog, IT 2.0.