CTGW External Connectivity in VCF 9.1

A five-part series on multi-connection Centralized Transit Gateways in VCF 9.1: architecture, four steady-state designs, and how to operate them.

CTGW External Connectivity in VCF 9.1

In VCF 9.1 a Centralized Transit Gateway (CTGW) can attach to more than one External Connection: a private link to the tenant's enterprise network, a link to a provider services network, and the default route to the Internet, all on one gateway. Two provider-side controls on the External Connection, Provider Outbound SNAT and Private-TGW IP block advertisement, decide what source address a tenant packet carries when it leaves through each connection.

This five-part series builds the objects in order, shows where every IP block field gets its value, and then walks four complete steady-state designs packet by packet, ending with the procedures and governance needed to run them. Read it in order; each part builds on the one before.

Start here — Intro: Tenant Topology for Cloud Providers running VCF9.1
A five-minute read on what the series is trying to do: one standard tenant network topology for a multi-tenant VCF 9.1 cloud, the four designs it covers, the components involved, and why it matters if you are planning a migration from VMware Cloud Director.

The five parts

  1. 1. Architecture and Foundations
    The six objects behind a multi-connection CTGW, where each IP block comes from, the four rules that decide a packet's source address, and the reference environment (tenants Cairo and Alex).
  2. 2. Use-Case A Private-VPC Connectivity to External Networks (Translated)
    Use case A: Cairo's Private-VPC workloads, an enterprise that accepts only provider-owned addresses, and Provider Outbound SNAT on the enterprise connection.
  3. 3. Use-Case B&C Private-TGW Connectivity to External Networks (Routed or Translated)
    Use cases B and C: Alex's Private-TGW workloads advertised to the enterprise with no NAT on the path, then the Provider SNAT alternative for the same tenant.
  4. 4. Use-Case D One Tenant, Three Exits
    Use case D: Riyadh with three External Connections (enterprise DC, shared services, Internet), workloads on all three subnet types, and all nine source-and-exit combinations.
  5. 5. Operating the Designs
    The four designs side by side, the constraints that apply to all of them, lifecycle procedures that do not strand traffic, a verification checklist, and who owns which setting.

How the series is organised

Every object in the series follows one naming convention, <Owner>-<purpose>-<object>: projects Tenant-Cairo, Tenant-Alex and Tenant-Riyadh; connections such as Cairo-wan-conn and Shared-services-conn; blocks such as Cairo-wan-block_10.100.10.0/24; gateways Cairo-wan-vrf, Internet-T0 and Shared-services-T0. Parts 2 and 3 share one reference environment; Part 4 has its own topology. The Introduction and all five parts carry the tag Series: CTGW External Connectivity, every post carries the full series index at the top and bottom, and the series listing shows all six posts in reading order.

Read the Introduction →  ·  Start with Part 1 →