Skip to content

Supervisor with "NSX + DTGW/VNA"

This section describes the procedures for Troubleshooting Network Services into the VKS Namespace utilizing an "NSX + DTGW/VNA" architecture inside a vSphere environment.

VDS Architecture

Packet Walk - N/S NAT to External

One or a few VMs have been deployed (see Application Deployment > App Deployment (VMs) > via vCenter UI or Application Deployment > App Deployment (VMs) > via CLI).

View

Logical View

  • Scenario A: VM connected to Private-VPC Subnet
    Logical

  • Scenario B: VM connected to Private-TGW Subnet
    Logical

Physical View

  • Scenario A: VM connected to Private-VPC Subnet
    Physical

  • Scenario B: VM connected to Private-TGW Subnet
    Physical

Packet Walk

  • Step1: VM accesses an External server
    VM1 (Private-IP) => External-IP

    L3 routing is always performed locally on the source ESX host.
    . In case of Private-VPC
    The traffic is routed by the VPC Gateway.
    Because Private-VPC subnet traffic leaving the VPC requires Source NAT (SNAT), it is redirected to the Active VPC-SR on the VNA.
    . In case of Private-TGW
    The traffic is routed by the VPC Gateway, then the DTGW. Because Private-TGW subnet traffic leaving the DTGW requires Source NAT (SNAT), the DTGW forwards the traffic back to the VPC, which directs it to the Active VPC-SR on the VNA.

  • Step2: SNAT accesses the External server
    NAT (10.1.7.131) => External-IP

    . For both cases Private-VPC and Private-TGW
    The Active VPC-SR performs Source NAT on the packet (translating VM-Private-IP to 10.1.7.131).
    The NATed packet is returned to the VPC Gateway / DTGW, which routes it out the external VLAN uplink onto the physical fabric toward the destination.