RSS .92| RSS 2.0| ATOM 0.3
  • Home
  •  

    VMware vCloud Networking Options

    Having worked with VMware vCloud-based technologies for a few months, I’ve come to the conclusion that networking and the automation glue which is required to make the magic happen, are both the most important pieces of the stack.

    To get started, I’ll list out some terms, and then we’ll build from there.

    • VXLAN
    • External Network(s)
    • Organization Network(s)
    • Network Pools
    • VCDNI/VCNI
    • VLAN-backed
    • vSphere port group-backed
    • vAPP

    Let’s start from the bottom and work our way up.

    vAPP is not a networking technology, but a way to encapsulate an environment.  With it, we can create a three-tier stack, encapsulate it in a vAPP, and then roll out it out N times, all looking exactly the same.  One can also set start-up precedence (database VM starts first, app second, web third).  It’s great stuff.

    vSphere port group-backed networks are what you would traditionally use in a vSphere environment.  Create a Distributed Virtual Switch, and then create a port group.  vCloud Director can use port group-backed in many scenarios.  It is a simple way to get started by using known methods.

    VLAN-backed networks are a fun little way of defining a pool of VLAN’s (something like VLAN IDs 100-200).  Of course, it is necessary that the network team actually configure the VLAN ID’s on the network, and then assign them to the trunks for your ESXi servers.

    vCloud Director Networking Infrastructure (VCDNI) is a method  of creating private networks backed by a single physical [email protected] on your network.  Once you get more involved in vCloud, it is one way to create vAPP sandboxes in your environment.  In short, VCDNI uses MAC-in-MAC encapsulation.  Basically it works by creating private VLAN’s (you will actually see the port groups attached to your vDS) and then stuffing that data inside a packet that can be used on the physical VLAN.  Is the data private and secure?  From my experience, the answer is: sorta.    If your vAPPs are using VCDNI-backed networking, and attached to the same broadcast domain (the org network), the machines can be hit by any host in that broadcast domain (and then with the use of vShield Edge, you can ACL that).  To be clear, the default rule on a vShield Edge device is deny ingress).  If you have vAPPs in different broadcast domains, they are protected from one another (on layer 2).  One kicker, your virtual Distributed Switch must have MTU set to 1524 (if it was set to default of 1500) to allow for the larger header due to encapsulation.

    Is VCDNI good?  Yes.  Is VCDNI bad?  Probably could be argued by networking folks, since they technically do not control the allocation of networks, other than the physical VLAN VCDNI uses.  Is it the future?  Allegedly that is something else called VXLAN.  (update)My opinion:  It is a path to create private networks in a rapid fashion with minimal interaction by the network team.  It works for now, but hopefully VXLAN will be better.

    Now that we have defined methods to transport the data, we will get in to the nomenclature of vCloud.

    Network Pools can either be defined by VLAN-backed, Network isolation-backed (VCDNI) or Port group-backed.  These pools are consumed by virtual datacenters to create vAPP networks.

    Organization Networks are assigned to an Organization virtual DataCenter.  There are multiple ways to define an OrgNetwork:

    • Direct connection:  This network is akin to a traditional port group-backed network in vSphere.  In short, it provides connectivity to LAN, WAN or Internet traffic.  It is tied to an External network and usually sits on internally routable RFC-1918 address space (most likely for private cloud) or Internet-routable address space for providers.
    • NAT-routed connection:  This connection allows for Network Address Translation (NAT) of External IP space to internal private networks.  The NAT-routed OrgNet is typically in RFC-1918 address space, however there are other cases.
    • Internal Organization network: This is strictly an internal network for the vApps to communicate with each other, but have no external network access.

    External Networks are port group-backed networks (defined in vCenter) that provide ingress and egress to the Cloud environment.  They should be routable networks, either RFC-1918 for private, or Internet routable for providers.

    2 responses to “VMware vCloud Networking Options”

    1. Don Park says:

      Good info and summary!! 🙂

    2. philipditzel says:

      Check your firewall on the vApp’s vShield Edge. It is set to deny all inbound by default.

    Leave a Reply

    Your email address will not be published. Required fields are marked *