5.6 Deploying & Configuring the VCF Network Gateway
Key Takeaways
The gateway layer that joins a VCF private cloud to the physical network is built on the NSX Tier-0 gateway and its Tier-0 VRF instances, hosted on the services router component of Edge transport nodes.
A provider gateway in VCF Automation leverages a Tier-0 or Tier-0 VRF gateway and associates it with addresses drawn from IP spaces, which is how a provider hands external connectivity to an organization.
VCF 9.0 adds a simplified network connectivity workflow with guided Edge deployment, so establishing external connectivity no longer requires building Edge clusters and routing by hand first.
A Tier-0 VRF gives each tenant an isolated routing table on shared Edge hardware, which is the standard way to separate tenants without dedicating an Edge cluster to each.
A Distributed Transit Gateway removes the Edge requirement entirely for suitable VLAN-backed topologies, so gateway deployment is a design decision rather than an automatic prerequisite.
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:
- 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.
- The Tier-0 gateway — the north-facing router that peers with the physical fabric, typically over BGP, and owns the uplinks.
- 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.
| Dedicated Tier-0 per tenant | Tier-0 VRF per tenant | |
|---|---|---|
| Routing isolation | Full | Full |
| Edge cluster required | One per tenant | One shared |
| Uplink configuration | Independent | Inherited from parent Tier-0 |
| Typical use | Strict physical separation mandates | Standard provider multi-tenancy |
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.
A provider must give three organizations independent routing tables and separate BGP advertisement policies for external connectivity, while reusing a single NSX Edge cluster. Which construct meets the requirement?
Three Tier-1 gateways, each with its own route advertisement configuration
A Tier-0 VRF for each organization, carved from a shared parent Tier-0 gateway
Three separate Tier-0 gateways, each requiring its own dedicated Edge cluster
A single Tier-0 gateway with three uplink interfaces, one per organization
In VCF Automation, what does a provider gateway represent, and who is responsible for creating it?
A tenant-created object that maps an organization's VPC subnets to a Tier-1 gateway, created by the organization administrator
A physical top-of-rack switch configuration profile pushed by VCF Operations, created automatically at bring-up
A provider-created object that leverages a Tier-0 or Tier-0 VRF gateway and associates it with addresses from IP spaces, created by the provider administrator
A per-virtual-machine NAT rule set applied at the distributed firewall, created by the application team
A design requires a Tier-0 gateway to provide both maximum north-south throughput across multiple Edge nodes and stateful Source NAT for outbound tenant traffic. What should the architect conclude?
Both requirements can be met simultaneously by enabling active-active mode with ECMP and stateful NAT synchronisation
The requirements conflict, because stateful services such as NAT require active-standby mode with a single connection-tracking owner
Stateful NAT should be relocated to the Tier-1 gateway so the Tier-0 can remain active-active with full statefulness preserved at Tier-0
Throughput and statefulness are unrelated, so the high availability mode has no bearing on the design
How did VCF 9.0 change the process of establishing external network connectivity compared with VCF 5.x?
External connectivity now requires a dedicated bare-metal Edge cluster, replacing the VM-based Edge option
External connectivity is configured exclusively through the SDDC Manager UI rather than through NSX
External connectivity must be defined in the deployment parameter workbook before bring-up and cannot be changed afterwards
A simplified workflow establishes external connectivity and can install Edge nodes and Edge clusters as part of the guided flow
Sections you finish are checked off in the contents.