Public VCF as-a-Service - Network concepts and best practices

In this introductory guide, we will explore:

• The different networking concepts within Public VCF as-a-Service.
• Concepts related to optimizing network space, such as IP space, Edge Gateways, and Datacentre Groups.

To ensure a flexible and secure network infrastructure in a versatile cloud environment, Public VCF as-a-Service uses a layered networking architecture that includes four categories of networks:

• External networks
• Organizational vDC networks
• Datacentre group networks
• vApp networks

Most of these networks require additional infrastructure elements, such as "Edge Gateways" and "Network Pools".

the Public VCF as-a-Service control panel has a network banner with 6 sections:

• Network
• Edge Gateways
• Provider Gateways
• IP Spaces
• Data Center Groups
• Security Tags

As well as a network section within each vDC in Data Center Groups > My vDC Name > Networking > Network > Edge Gateway.

Public VCF as-a-Serviceon OVHcloud networking capabilities

Here are the main network features offered with the Public VCF as-a-Service solutions.

Network features

Here is a comparison of the 3 solutions offered by Public VCF as-a-Service.

Here we see that only the advanced networking and security features within Public VCF as-a-Service are available in the Advanced and Premium offers.

Recommendations in network space design and administration

The network within Public VCF as-a-Service (concept)

The types of network supported within an organization’s vDC:

Organizational virtual datacentre (vDC) networks enable vApps/VMs to communicate with each other or with networks external to the organization.

Organization vDC networks provide direct or routed connections to external networks, or can be isolated from external networks and other organization vDC networks. Routed connections require an Edge Gateway and a network pool in the organization vDC.

A recently created organization vDC does not have any available networks.

Network pools (concept)

A network pool is a set of isolated layer 2 network segments that you can use to design vApp networks and various types of vDC networks to suit your requirements.

Network pools must be set up before organization vDC networks and vApp networks. In their absence, the only network option for an organization is to connect directly to an external network.

IP spaces (recommended)

An IP space consists of a set of non-overlapping IP address ranges and small CIDR blocks that are reserved and used when consuming the IP space lifecycle. An IP space can be IPv4 or IPv6, but not both.

Since version 10.4.1, IP spaces have been part of the new features and are recommended for your network space needs.

There are two types of IP spaces that you can use as the Organization Administrator user:

• Public IP space: A public IP space is used by multiple organizations and is controlled by the Service Provider through a quota-based system.
• Private IP space: Private IP spaces are dedicated to a single tenant: a private IP space is used only by an organization specified when the IP space was created. For this organization, the consumption of IP addresses is unlimited.

Via the Public VCF as-a-Service control panel

Configuration:

• General.
• Network Topology.

Allocation:

• Floating IPs.
• IP Prefixes.

IP prefixes (recommended)

You can set an IP prefix for automatic or manual use and prevent Public VCF as-a-Service from randomly assigning it.

If you no longer use an IP prefix that has been allocated to your IP space, you can free it up in the pool.

Network topologies (concept)

You can view the network topology from the Public VCF as-a-Service control panel by clicking on: Networking | IP Spaces | IP space's name | Configuration | Network Topology

Network topologies are used to configure IP spaces to enable north-south traffic.

Default auto-configuration rules:

• Note that the internal and external scope of IP spaces must be configured if the default NAT rules are to be generated automatically. Default rules can be configured automatically on Edge Gateways and Provider Gateways by manually triggering them on them using the "Automatic Configuration" action.

Datacentre groups (recommended)

Datacentre group networks are a type of organizational vDC networks that are shared between one or more vDCs and to which vApps can connect.

When creating a network, you can join your datacentre group, which will then provide connectivity to the vApps/VMs of all participating vDC.

Synchronization (optional)

You can also synchronize them. This synchronization action will check all associated vDC to ensure that they are always realized and correctly configured.

Create or import network into datacenter group (optional)

Edge Gateway (required)

Public VCF as-a-ServiceEdge Gateway allows an organization vDC network to route connectivity to internal networks, network address translation (NAT), firewall, IPsec tunnel mounting,

• Public VCF as-a-Servicesupports: IPv4 and IPv6 Edge Gateways.

DHCP mode (optional)

DHCP automates the assignment of IP addresses to virtual machines connected to the organization's vDC networks.

Three modes are available:

• Network: A new DHCP service directly associated with this network is used to obtain the DHCP IPs. Use network mode if the network is isolated or if you plan to detach the network from the perimeter.
• Relay: DHCP messages are relayed from virtual machines to designated DHCP servers in your physical DHCP infrastructure.
• Gateway: The Edge Gateway DHCP service is used to obtain DHCP IPs.

vApp networks (concept)

vApp networks allow virtual machines to communicate with each other or, by connecting to an organizational vDC network, with virtual machines in other vApps.

From a general point of view, the only limitations you can find within Public VCF as-a-Service are those of a managed service.

A little less granularity when it comes to low-level configuration.

Of course, this can impact advanced networking features, although these features may be included in future phases.

IPsec VPN Limitations

When adding an IPsec tunnel, the parameter of adding a route-based IPsec session (route based IPsec tunnel) is not supported within Public VCF as-a-Service to date (see: docs / VMware NSX / NSX administration guide / Adding an IPSec session based on a route).

Provider gateways limitations

Provider gateways are clearly visible, but cannot be modified (like a managed service).

NSX limitations

You do not have access to the NSX control panel for your Hosted Private Public VCF as-a-Service.

Load Balancer limitations

The features of Load Balancing within Public VCF as-a-Service are not available at the moment.

IAM limitations

IAM is not available within Public VCF as-a-Service at this time.