vCloud Director 1.0.1: Networking Samples

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 that 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 this 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.


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, 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 very reach at the same time. I have another vApp that is called “Turnkey-Routed”. It contains a single VM which 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. As easy as it is.

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):


Let’s now try to put all these piece together and look 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 others.

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


13 comments to vCloud Director 1.0.1: Networking Samples

  • Glenn Grabowski

    AWESOME! Very helpful.

  • networking for dummies indeed …

    i find it impossible to understand why someone would want to use a device like vshield-edge to build his VDC.
    device that supports only 2 interfaces (in and out) and only do NAT, this 2-tier topology is embarrassing when you think about how simple it is to do with common networking devices , why moving into VM-based needs to be so lame ?

    tech details here :

    • Massimo

      Thanks Koren for the feedbacks.

      We owe you a beer for spending so much time on our products and providing valuable feedbacks to make them better.


  • Lee

    Hey Massimo, really appreciate these guides.

    Question – if you were a service provider wanting to provision public cloud for the masses (ie high volumes of low cost VMs) – would you not simply connect your VMs direct to your external network? Your comment “you would never want to connect VMs to a connection like this (directly connected to the Internet).” suggests its very bad practice but whats the alternative? A vShield Edge for every single customer (who probably only has 1 vApp/VM) ? Surely not. I don’t see how you can build customer/VM segregation without wasting IPs (layer3) or having a vShield per customer or coming up with your own NAT/firewall method.

    TIA !

    • Massimo

      Thanks Lee.

      Good point. The problem is that if you connect all those VMs to a shared segment (i.e. directly to the same External Network) you have no mechanism (at least today, at least from an infrastructure perspective) for protecting those VMs. This statement is true for both east-west traffic (i.e. tenant1 VM to tenant2 VM) as well as for south-north traffic (i.e. internet to tenant VM and viceversa). You can always protect them using Guest OS based firewall products but the whole idea is to simplify the OS configuration (we could start a religion battle on this I am sure). Selling one VM to each tenant may indeed end up not being an optimal solution because you have to give the vShield Edge a public address + another public address to do NATting. So 1 VM = 2 IPs needed.
      If you had more VMs behind the Edge it may end up being better since you can multiplex that single additional public address via port forwarding (hence VMs > IPs needed). For contrast your direct mapping solution requires a proportional number of public IPs to cope with a growing number of VMs.

      All this if we stick on the self-service aspect of the vCloud Director cloud. You may be able to protect those single tenants’ VM for east-west and south-north traffic with vShield App but (today) we do not expose that configuration option to the tenant (i.e. self service) but this rather needs to be a “managed service” that the SP provide.

      Does this help?


  • Juan

    Hi Massimo, great post. I am trying to connect a vCloud director environment that I am renting from company X, which is in fact an organization vDC to my internal network at home. I was reading that vShield can provide a VPN service to do that, but I haven’t found official documentation about how to set it up.

    What would be the best way to create this VPN?, upload a VPN server OVF template and deploy it inside the vApp I want to connect, and then pair it with a node running at home (enabling NAT from the external IP to the port the cloud VPN server is listening)?, or is there any simpler way to do this and connect the whole organization vDC to my internal network at home.


    • Massimo

      Hi Juan.

      In vCD 1.0 we didn’t expose as a self service property the Edge VPN configuration. You have to contact your SP and have it configured for you (you need to give them the required information to establish the VPN including your IP end-point etc.)

      In vCD 1.5 we exposed this property in the consumer UI so when you configure your network other than “DHCP”, “Firewall”, “NAT” you will also see “VPN” where you can enter yourself the info I mentioned above.

      I don’t know which software stack your provider is running but if you don’t see that entry they are at 1.0 probably.



  • Juan

    Thanks for the information Massimo.

    You are right, my SP is using vCD 1.0.

  • koren

    Here is some constructive suggestions:

    1. make vshield edge into a real router/gateway (with routing protocols etc) , not just a NAT device.
    2. make vshield edge HA capable (pair of vshield-edge devices running something like VRRP).
    3. make vshield edge multiple interface device , so it support more then just a single network.

    before providing the above capabilities don’t sell the product as part of VCD, don’t suggest customers to build the listed topologies in a way the suits the shortcomings of the product, don’t suggest it for real production VDC construction.

    • Massimo

      I am glad we are now moving the discussion to a more constructive tone (vs religiously bashing). I somewhat agree with what you are saying here. As a matter of fact we are not positioning (yet) vCD as a platform on which you can move your production ERP on (although there are customers that may be doing this if they want to). I have no problem saying this and I have also published my point of view on this last year:

      Things are getting (a lot) better but the positioning hasn’t (yet) changed dramatically.

      Having this said not all workloads are equal and there is an infinite number of nuances when it comes to the infrastructure requirements.

      Your points #1, #2 and #3 are well taken.


  • koren

    Got it , so it seams you guys will come up with a solution to the points #1-3 above inside the vshield VM.
    Once you have that, it can finally be compared to common routing/FW solutions, the conversation can move
    on to BW consumption per host (that have many of those ‘gateways’), cost per ‘virtual instance’ (like 8,000 VRF on ASR hardware compared to N x ESX hosts running software-based forwarding) , packet-per-second figures, sessions-per-seconds and how is x86 handling small (common) packets vs ASIC-based routing/FW platforms.
    In my experience, there is a big gap here, was proven many times in the past (products handling packets in software) even if you would compare cisco vIOS running on VM to typical router hardware you will see why the hardware is needed, just look at all common networking products staying away from processing packets ‘in CPU modules’ and reverting to ‘Line-rate hardware modules’ only. IMO this is far from a repeat of the ‘server visualization history’ as in Router/FW ‘alternatives’ for cloud it is all about the scale – this one is a packet processing and forwarding device for many other VMs, looking deeper into the way it is done in hardware today (nexus 7k , juniper SRX, Fortinet etc etc) will show the gap (well known and highly investigated issue).
    So IMO the orchestration of hardware-based and software-based DC services is the one that introduce the necessary scale.
    vCD data model should/could start to support it if it want to be ‘the cloud’.

    • Massimo

      Koren, I believe the jury is still out on this. There are many people that says ASIC-based hw will go away (in the long run) and other people that think this will not be the case. Time will tell.

  • […] is a repost from Massimo’s personal blog, IT 2.0 – Next Generation IT […]

Leave a Reply