anchor.diff:  
   In vCloud and vCloud Air deployments the various components of Cloud Foundry are installed on a private network, where each component does not have a publicly routable IP address. Instead, when internal VMs need to access public IP addresses we use source NAT (SNAT) to map these multiple internal addresses to a public address (just like your home WiFi router).
   
  -Similarly, when an external machine tries to connect to Cloud Foundry, it will connect to a public IP address. This needs to then connect to the private IP address of the Cloud Foundry instance, specifically the HA Proxy VM.
  +Similarly, when an external machine tries to connect to Cloud Foundry, it will connect to a public IP address. This needs to then connect to the private IP address of the Cloud Foundry instance, specifically the HAProxy VM.
   
  -The obvious solution to this is to use destination NAT (DNAT) to connect the Cloud Foundry public IP address to the HA Proxy private address. However, we have found some issues with that approach. When the internal components of Cloud Foundry talk to each other over https (e.g. login server to the UAA) they use the wildcard domain described above to resolve host names to IPs. For example, when `login.mycf.com` wants to connect to `uaa.mycf.com` and does a DNS lookup, it will receive the public IP address of the Cloud Foundry instance. When it connects to this it should be SNATed to an external address and then DNATed to the HA Proxy private IP address. We have found that, because of the way iptables rules are processed, this repeated NAT conversion from an internal IP to a public IP and back to internal does not happen correctly.
  +The obvious solution to this is to use destination NAT (DNAT) to connect the Cloud Foundry public IP address to the HAProxy private address. However, we have found some issues with that approach. When the internal components of Cloud Foundry talk to each other over https (e.g. login server to the UAA) they use the wildcard domain described above to resolve host names to IPs. For example, when `login.mycf.com` wants to connect to `uaa.mycf.com` and does a DNS lookup, it will receive the public IP address of the Cloud Foundry instance. When it connects to this it should be SNATed to an external address and then DNATed to the HAProxy private IP address. We have found that, because of the way iptables rules are processed, this repeated NAT conversion from an internal IP to a public IP and back to internal does not happen correctly.
   
   We have found two ways to work around this:
   
  -1. Use the vShield Edge Load Balancer to connect the Cloud Foundry public IP to the HA Proxy private IP
  -2. Use split-brain DNS, with an internal DNS server resolving the wildcard domain for internal VMs to the private IP of HA Proxy
  +1. Use the vShield Edge Load Balancer to connect the Cloud Foundry public IP to the HAProxy private IP
  +2. Use split-brain DNS, with an internal DNS server resolving the wildcard domain for internal VMs to the private IP of HAProxy
   
   The vShield Edge Load Balancer is the simpler of the two to set up and so the following sections detail the steps used to set up the network environment using that approach.
   
  
positive.code: 
  ### vCloud Air ###
  To get started with Cloud Foundry on **vCloud Air Service** you will need a
  **vCloud Air account** and a **virtual datacenter** (vDC) with at least 60GB 
  memory, 120GB disk, and 28 vCPU cores.
  You will need at least two public IP addresses: one to connect to the jump box
  VM and one for Cloud Foundry.
  
negative.code: 
  ![vShield Edge Load Balancer Configure Service](/vcloud_images/load_bal_config_health_check.png)
  
  Finally configure the members of the pool. There is only one member - the internal IP for the HAProxy VM, assigned above:
  
  ![vShield Edge Load Balancer Configure Service](/vcloud_images/load_bal_config_service.png)
  
  