Cloud Director networking enables the provider and tenants to create and consume networking constructs from a vSphere or NSX environment. Hence, tenants can create network segments and configure network services including DHCP, NAT firewalling, and load-balancer integrations.
This section describes how the vSphere and NSX networking constructs can be created and consumed within Cloud Director. The general networking concepts of vSphere or NSX are not covered.
Network Pools
A network pool is a group of networks available for an organization VDC to create routed networks and certain types of organization VDC networks. VMware Cloud Director uses network pools to create NAT-routed and internal organization VDC networks and vApp networks. Network traffic on each network in a pool is isolated from all other networks at Layer 2.
Each organization VDC in VMware Cloud Director can have one network pool. Multiple organization VDCs can share a network pool. The network pool for an organization VDC provides the networks to satisfy the network quota for an organization VDC.
Every provider VDC that is backed by NSX includes a Geneve network pool. When you create an NSX-backed provider VDC, you can associate that provider VDC with an existing Geneve network pool or create a new Geneve network pool for the provider VDC.
VMware Cloud Director Geneve networks have various benefits:
Logical networks spanning Layer 3 boundaries
Logical networks spanning multiple racks on a single Layer 2
Broadcast containment
High performance
Increased scaling (up to 16 million network addresses)
If NSX is not in use, a VLAN-backed network pool can also be leveraged. When using a VLAN-backed network pool, the provider specifies the VLAN ranges that can be consumed by the pool. When an OrgVDC network is created, a port group is created on the vSwitch with the next available VLAN from the network pool.
External Networks
A Cloud Director external network provides an uplink interface that connects networks and VMs in the system to a network outside of the system. For example, a VPN, a corporate intranet, or the public Internet.
External networks are provider-level configurations and they are not created at the tenant level. When creating an External Network in Cloud Director, the vSphere or NSX Adminstrator must provision the network segment first so Cloud Director can consume them.
The range of IP addresses defined for the external network are allocated either to an edge gateway or to the VMs that are directly connected to the network. Hence, the IP addresses must not be used outside of VMware Cloud Director.
An external network can be backed by an NSX tier-0 logical router. You can also create an external network that is backed by a VRF-lite tier-0 gateway in NSX. A VRF gateway is created from a parent tier-0 gateway. It has its own routing tables. Multiple VRFs can exist within the parent tier-0 gateway. This allows VDCs to have their own external network without deploying multiple tier-0 gateways.
Organizational VDC Networks
OrgVDC networks can be created within the tenant space of Cloud Director, so that tenant workloads can have both internal and external connectivity. OrgVDC networks are typically used for internal traffic, however an OrgVDC network can be connected directly to external networks to create different networking topologies.
The following OrgVDC network types are used for workload traffic:
Direct Networks: The direct network allows an exit from within the Organization VDC to an external network. The direct network is connected directly to a vSphere port group that hosts the network configuration.
Note:When using NSX (without N-VDS), the NSX segments show up as port groups in the vSphere vSwitch. You can also create an NSX overlay segment as an external network and then create a direct network that is backed by this network.
This approach allows direct VM to T0 communication and avoids the T1 construct created within the Cloud Director tenant.
Internal Networks: The internal network is created within an organization and is not connected to any constructs. It is neither backed by an external network nor connected to a tenant edge. The internal network is not routed, so all VMs that need to communicate must have an attachment to this network.
Routed Network: The routed network is a network segment that is connected to an NSX Edge. The routed network is attached to a tenant edge gateway and can be configured as routable through the external connection provided by the provider gateway configuration.
The following figure illustrates a single Organization within which a vApp with a router network is connected to an NSX Tier-1 gateway (deployed through Cloud Director) and an isolated network that is not connected outside of the organization.
Depending on the use case, networking constructs within Cloud Director can be shared across multiple OrgVDCs within an organization, allowing networks to span beyond the OrgVDC construct.
Cloud Director - NSX Networking
An NSX edge gateway provides a routed organization VDC network or a data center group network with connectivity to external networks and IP management properties. It can also provide services such as firewall, NAT, IPSec VPN, DNS forwarding, and DHCP, which is enabled by default.
Provider Gateways: The provider gateway brings an NSX Tier-0 or Tier-0 VRF construct into Cloud Director. The provider gateway is created at the provider level.
When building a provider gateway, the administrator selects the NSX manager and the T0 construct to bring into Cloud Director and the user also specifies an IP Block.
When creating a provider gateway, nothing new is created on NSX. Tenant edges that are connected to the provider gateway create an instantiation of a Tier-1 Gateway within NSX.
Mixed-mode Provider Gateways are not supported. For example, you cannot have a Provider Gateway that is using T0-VRFs and also the same parent T0.
Edge Gateways: The edge gateway represents the instantiation of a Tier-1 gateway within an Organizational VDC. The edge gateway connects to the Provider Gateway created by the administrator. The edge gateway belongs to a single OrgVDC.
When creating the edge gateway, the specified provider gateway can be marked as dedicated. This enables some additional configuration options within Cloud Director such as Route Advertisement control and BGP routing configuration. Any BGP configuration is applied at the provider gateway as the edge gateway (as a Tier-1 Gateway) does not support BGP.
By using route advertisement, you can create a fully-routed network environment in an OrgVDC. You can decide which network subnets that are attached to the NSX edge gateway can be advertised to the dedicated external network. If a subnet is not added to the advertisement filter, the route to it is not advertised to the external network and the subnet remains private. Route advertisement is automatically configured on the NSX edge gateway.
VMware Cloud Director supports automatic route redistribution when you use route advertisement on an NSX edge gateway. Route redistribution is automatically configured on the tier-0 logical router that represents the dedicated external network. You can configure an external or internal Border Gateway Protocol (eBGP or iBGP) connection between an NSX edge gateway that has a dedicated external network and a router in your physical infrastructure.
In an edge gateway that is connected to an external network backed by a VRF gateway, the local BGP AS number and graceful restart settings are inherited from the parent Tier-0 gateway and they cannot be changed at the VRF level.
You can also attach external networks directly to the Tier-1 Gateway, by selecting the external networks. The port-group is connected to the Tier-1 Gateway as a service port that exists on the service node where the Tier-1 is deployed.
Cloud Director Recommendations
Design Recommendation |
Design Justification |
Design Implication |
|---|---|---|
Create a Geneve Network pool. |
Required to create NSX-T backed network resources. |
None |
Create a dedicated external network per Organization. |
Allows the use of a fully routed network topology. |
None |
Create a VRF per Organization. |
Allows all Organizations to share a single parent Tier-0 gateway, while maintaining isolation between Organizations. Sharing a single parent gateway reduces the number of NSX Edges required in the deployment. |
VRFs inherit the local AS and graceful restart configuration of the parent Tier-0, such that each VRF has the same local AS. |
Create one or more Edge Gateways (Tier-1 gateways) per Organization VDC. |
Enables networking services for the Organization VDC. |
None |
Create DC Groups, if there is a need to have OrgvDC networks spanning multiple OrgVDCs in an organization. |
Simplifies cross-OrgVDC connectivity |
Requires the creation of DC groups within the Cloud Director tenant. |
Use Legacy IP Block addressing instead of the IP Spaces feature. |
Note: The delivery of the complete IP Spaces feature spans multiple releases. You can use IP Spaces if your required use cases are fully covered in a specific VMware Cloud Director release. |
None |
