5.6 Deploying & Configuring the VCF Network Gateway

5.6 Deploying & Configuring the VCF Network Gateway

Exam Focus: The blueprint objective reads "describe the deployment of and configure a VMware Cloud Foundation (VCF) Network Gateway". In the product itself this gateway layer is delivered by NSX Tier-0 gateways and Tier-0 VRFs, surfaced to tenants as provider gateways in VCF Automation. This section teaches that layer under the names you will see in the products and in Broadcom documentation.

---

What the Gateway Layer Does

Everything inside the private cloud is overlay. At some point that overlay has to meet the physical network — to peer with datacenter routers, to translate addresses, and to enforce a controlled perimeter. The gateway layer is that meeting point.

It is built from three cooperating pieces:

1. Edge transport nodes — VM or bare-metal appliances running a DPDK-accelerated fast path. They are the only place the services router (SR) component can live, which is why any centralised stateful service requires them.
2. The Tier-0 gateway — the north-facing router that peers with the physical fabric, typically over BGP, and owns the uplinks.
3. Tier-0 VRFs — virtual routing and forwarding instances carved from a parent Tier-0, each with an isolated routing table.

---

Tier-0 VRFs: Tenant Separation Without Dedicated Hardware

A VRF is the mechanism that makes multi-tenancy affordable. Rather than deploying a separate Edge cluster per tenant, one physical Edge cluster hosts a parent Tier-0, and each tenant receives a Tier-0 VRF with:

• Its own routing table, so overlapping or independent address plans do not collide.
• Its own BGP peering and route advertisement policy.
• Shared underlying Edge capacity, inherited from the parent Tier-0's uplinks.

---

Provider Gateways: Handing Connectivity to a Tenant

In VCF Automation, the provider administrator does not hand a tenant a raw Tier-0. They create a provider gateway, which leverages a VCF networking Tier-0 or Tier-0 VRF gateway and associates it with IP addresses from IP spaces that can be advertised from that gateway.

Two constructs matter here:

• The provider gateway is the tenant-facing representation of external connectivity. Organizations attach to it to reach anything outside the private cloud.
• IP spaces are the managed address pools the gateway advertises. Associating a space with a gateway is what makes those addresses externally reachable, and it is what allows the provider to enforce quotas so one organization cannot exhaust the pool.

This is the division of responsibility to remember: the provider owns the Tier-0, the VRFs, the Edge clusters, the IP spaces, and the provider gateways. The organization consumes them.

---

The VCF 9.0 Simplified Connectivity Workflow

In VCF 5.x, establishing external connectivity was a sequence of manual steps: build an Edge cluster, configure uplink profiles and transport zones, create the Tier-0, configure BGP, then attach Tier-1 gateways.

Starting with VCF 9.0 a simplified workflow sets up network connectivity and performs network configuration, improving operational efficiency in VPC environments by providing a straightforward way to establish external connectivity and install Edge nodes and Edge clusters as part of that guided flow. The administrator expresses the connectivity intent and the platform provisions the Edge infrastructure needed to deliver it, rather than requiring that infrastructure to exist first.

---

When a Gateway Deployment Is Not Required at All

The most important design nuance in VCF 9.0 is that Edge deployment is conditional.

• A Centralized Transit Gateway (CTGW) routes through an NSX Edge cluster via the Tier-0. Edge nodes are required, and the gateway layer described above is fully in play.
• A Distributed Transit Gateway (DTGW) uses distributed routing in the vSphere hypervisor and requires no Edge nodes at all. Hosts connect directly to the fabric, which removes hops, raises throughput, and aligns the physical and virtual topologies for troubleshooting.

So the correct answer to "how do I give these workloads external connectivity" begins with a design question, not a deployment step.

---

Configuration Elements to Know

When a centralized gateway is deployed, these are the settings that carry exam weight:

• Uplink interfaces and VLANs connecting Edge nodes to the top-of-rack switches.
• BGP configuration — local and remote ASN, neighbour addresses, timers, and route redistribution.
• ECMP across multiple uplinks and Edge nodes for active-active north-south throughput.
• High availability mode — active-active for stateless forwarding throughput, or active-standby where stateful services such as NAT and the gateway firewall are required.
• Route advertisement and filtering, controlling which internal prefixes are exposed.

[!WARNING] Stateful services force active-standby. A common scenario offers active-active for maximum throughput while also requiring stateful NAT or gateway firewalling. Those requirements conflict, because stateful services need a single connection-tracking owner.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Provider versus organization. Creating a provider gateway, defining IP spaces, and deploying Edge clusters are provider administrator tasks. An organization administrator consumes the resulting connectivity and cannot create it.

[!TIP] VRF is the answer to "isolate tenants without more Edges". When a scenario demands separate routing tables and independent BGP policy per tenant while reusing one Edge cluster, the construct is a Tier-0 VRF.