As noted in Section 5, IP Address Management and Routing, addresses used within tenant Org VDCs can be managed by either the provider or the customer. In the majority of deployments, whoever manages the addresses will do so from the “private” address ranges provided by RFC1918. Even if their usage can be controlled within the provider environment, it is likely that within the customers’ WAN environments, addresses will overlap between customers. For this reason, even when the provider makes sure that addresses within the data center are unique, the need to uniquely route traffic to and from non-unique WAN addresses means that separate routing tables must be maintained for each tenant.

One case where this is not required is when the provider uses registered, public internet addresses in the external network NAT layer, which hides tenant Org VDC network addresses completely and only provides external access through the public Internet. In this case, both the tenant (NAT) addresses and the remote connection addresses are globally unique, and a single routing and forwarding table can be shared across all customers using the same mechanisms described in the previous section.

Overlapping customer addresses are separated by the Org VDC networks whose VXLAN backing creates the same Layer 2 separation as traditional VLAN-backed networks. The only places at which the overlapping addresses could therefore clash is if the separated networks were then connected to shared routing devices. In the examples used throughout this document, each tenant’s Org VDC has a dedicated Edge Services Gateway, and is connected to the respective customer WAN over a discrete vCloud Director external network. This VLAN-backed network typically terminates on a dedicated, per-tenant WAN CE router or a shared multi-tenant PE router in which the each VLAN is internally mapped to per-tenant VRF (as described in Section 4.2, vCloud Director Multitenant Data Center Networking in vSphere). The Edge Services Gateway, CE router, or PE VRF maintain independent routing tables, allowing each customer to use identical addresses within their tenant Organizations without affecting other tenants.

 

This figure shows the peering between each tenant Org VDC Edge Gateway and that customer’s WAN access router. The Edge Services Gateway will advertise the Org VDC networks to which it is directly connected, to the WAN access router, and from there to the rest of the customer’s WAN. Any new Org VDC networks that are created by the service provider or the customer and which are connected to their respective Edge Services Gateway will also be advertised to their WAN. Because the Edge Services Gateway will typically default route towards the internet, it must learn the address ranges in use on the WAN to reach those destinations. This is carried out over the same routing protocol as that used to advertise the Org VDC networks to the WAN, except in the opposite direction.

The Edge Services Gateway supports both OSPF and BGP routing protocols, either of which can be used to peer with a WAN access router.