VMware NSX-T KB — Phase 7: VCF & Federation

GM/LM Connectivity Loss

Global Manager loses connectivity to Local Manager — federation sync breaks, configuration drift occurs

CriticalFederationGMLM

⚠Impact: Configuration changes on GM cannot propagate to the affected site. Stretched segments may not update. Local operations continue independently but drift from central policy.

Resolution

Verify GM to LM connectivity and repair

# On Global Manager — check site status:
GET https://<gm>/global-manager/api/v1/global-infra/sites

# Check connectivity to specific LM:
GET https://<gm>/global-manager/api/v1/global-infra/sites/<site-id>/status

# Common causes:
# 1. Certificate expired between GM and LM
# 2. Network connectivity issue (firewall, routing)
# 3. LM cluster unhealthy (all 3 nodes must be up)
# 4. DNS resolution failure

# Verify network connectivity:
# From GM: ping <lm-vip>
# Test API connectivity: curl -k https://<lm-vip>/api/v1/cluster/status

# If certificate issue:
# Re-register the site from GM:
POST https://<gm>/global-manager/api/v1/global-infra/sites/<site-id>?action=reregister

# Check GM-LM sync queue:
GET https://<gm>/global-manager/api/v1/global-infra/sites/<site-id>/sync-status

Stretched Segments Configuration

Configure and troubleshoot stretched segments in NSX Federation for cross-site L2 connectivity

HighStretchedSegmentFederation

Resolution

Configure and verify stretched segment

# On Global Manager:
# 1. Create stretched Transport Zone (spans all sites):
PUT https://<gm>/global-manager/api/v1/global-infra/sites/default/enforcement-points/default/transport-zones/Stretched-TZ
{
  "display_name": "Stretched-Overlay-TZ",
  "transport_type": "OVERLAY",
  "is_default": false
}

# 2. Create segment on stretched TZ:
PUT https://<gm>/global-manager/api/v1/global-infra/segments/Stretched-Web
{
  "display_name": "Stretched-Web-Segment",
  "transport_zone_path": "/global-infra/sites/default/enforcement-points/default/transport-zones/Stretched-TZ",
  "subnets": [{"gateway_address": "10.50.1.1/24"}]
}

# 3. Verify RTEP connectivity (Edge-to-Edge between sites):
# On Edge at Site-A:
get interfaces | grep rtep
ping <site-b-edge-rtep-ip>

# 4. Verify segment is realized at both sites:
GET https://<gm>/global-manager/api/v1/global-infra/segments/Stretched-Web/state

VCF NSX Upgrade Procedure

Upgrade NSX-T within VCF environment using SDDC Manager lifecycle management

CriticalVCFUpgradeSDDC Manager

⚠Critical: In VCF, NSX upgrades MUST go through SDDC Manager. Direct NSX Manager upgrades will break VCF lifecycle management and support.

Resolution

VCF NSX upgrade workflow

# Step 1: Upload bundle to SDDC Manager
# SDDC Manager → Lifecycle Management → Bundle Management
# Download and stage the NSX upgrade bundle

# Step 2: Run pre-check:
# SDDC Manager → Lifecycle Management → Upgrades
# Select NSX component → Run Pre-check
# Resolve any compatibility warnings

# Step 3: Upgrade order (automatic via SDDC Manager):
# 1. NSX Manager cluster (one node at a time)
# 2. Edge clusters (one Edge at a time with HA failover)
# 3. Host transport node clusters (one host at a time, VMs vMotion)

# Step 4: Verify health after each component:
GET https://<nsx-manager>/api/v1/cluster/status
GET https://<nsx-manager>/api/v1/edge-clusters/<id>/status
GET https://<nsx-manager>/api/v1/transport-nodes/status

# NEVER upgrade NSX directly — always use SDDC Manager
# This ensures BOM compatibility and proper sequencing

VCF BOM Compliance Verification

Verify NSX-T version compliance with VMware Cloud Foundation Bill of Materials

HighVCFBOMCompliance

Resolution

Check VCF BOM and component versions

# SDDC Manager API — Get current BOM:
GET https://<sddc-manager>/v1/system/prechecks/connectivity

# Check inventory versions:
GET https://<sddc-manager>/v1/nsxt-clusters

# Verify current NSX version:
GET https://<nsx-manager>/api/v1/node/version

# VCF BOM compatibility:
# VCF 4.5 → NSX-T 3.2.x
# VCF 5.0 → NSX-T 4.1.x  
# VCF 5.1 → NSX-T 4.1.2+

# Check interoperability:
# https://interopmatrix.vmware.com
# Verify ESXi ↔ NSX-T ↔ vCenter versions are compatible

# If out of BOM — plan upgrade via SDDC Manager lifecycle
# Do NOT manually patch NSX to a version not in the VCF BOM

Global Manager Failover

GM Active/Standby failover procedure — promoting standby GM when primary fails

CriticalFederationGM FailoverDR

⚠Impact: Without GM, no cross-site configuration changes possible. Stretched segments and cross-site policies cannot be modified. Local operations continue unaffected.

Resolution

Promote standby GM to active

# Check current GM role:
GET https://<standby-gm>/global-manager/api/v1/global-infra/global-manager-config

# Promote standby to active:
PUT https://<standby-gm>/global-manager/api/v1/global-infra/global-manager-config
{
  "mode": "ACTIVE"
}

# Wait for promotion to complete (2-5 minutes)
# Verify new active GM:
GET https://<new-active-gm>/global-manager/api/v1/global-infra/sites

# Update DNS/LB to point GM FQDN to new active
# All LMs will automatically reconnect to new active GM

# When old GM recovers — set it as STANDBY:
PUT https://<recovered-gm>/global-manager/api/v1/global-infra/global-manager-config
{
  "mode": "STANDBY",
  "active_global_manager": "https://<new-active-gm>"
}

VCF Workload Domain Network Isolation

Configure proper network isolation between VCF workload domains using NSX-T

HighVCFWorkload DomainIsolation

Resolution

Workload domain isolation architecture

# VCF Workload Domains each get their own:
# 1. NSX-T instance (or shared NSX with separate T0)
# 2. vCenter Server
# 3. Edge cluster

# Isolation pattern:
# Management Domain: Shared NSX Manager cluster
# Workload Domain A: Own T0 → own Edge Cluster → own segments
# Workload Domain B: Own T0 → own Edge Cluster → own segments

# Network isolation achieved by:
# 1. Separate T0 gateways (no route leaking)
# 2. Separate transport zones per workload domain
# 3. DFW emergency policy blocking inter-domain traffic

# Verify isolation:
# From VM in Domain A:
# Should NOT be able to reach VMs in Domain B
# Unless explicit inter-domain routing is configured

# SDDC Manager handles this automatically during WLD creation

Edge Cluster Sizing in VCF

Proper Edge cluster sizing and deployment for VCF workload domains

HighVCFEdgeSizing

Resolution

Edge sizing guidelines for VCF

# VCF Edge form factors:
# Small:   2 vCPU, 4GB RAM   — Lab/PoC only
# Medium:  4 vCPU, 8GB RAM   — Small workload domains (< 100 VMs)
# Large:   8 vCPU, 32GB RAM  — Production (recommended minimum)
# Bare Metal: Physical Edge   — High-throughput requirements

# VCF deployment via SDDC Manager:
# Lifecycle → Workload Domain → Add Edge Cluster
# Select form factor based on:
# 1. Number of T1 gateways
# 2. Expected N-S throughput
# 3. Number of VPN tunnels
# 4. NAT session count
# 5. Load balancer connections

# Best practices:
# - Minimum 2 Edge nodes per cluster (HA)
# - Large form factor for production
# - Dedicated Edge cluster per workload domain
# - Anti-affinity rules for Edge VMs
# - Resource reservation (CPU + Memory)

Certificate Sync in Federation

Certificate trust issues between GM and LM preventing federation sync and configuration push

HighFederationCertificateSync

Resolution

Repair certificate trust between GM and LM

# Check certificate expiration:
GET https://<gm>/api/v1/trust-management/certificates
# Look for expired or soon-to-expire certificates

# Check GM-to-LM trust:
GET https://<gm>/global-manager/api/v1/trust-management/principal-identities

# If cert expired — regenerate and re-establish trust:
# On LM — get current certificate:
GET https://<lm>/api/v1/cluster/api-certificate

# On GM — update the site's LM certificate:
POST https://<gm>/global-manager/api/v1/trust-management/certificates?action=import
# Import the new LM cert

# Re-register site if trust completely broken:
POST https://<gm>/global-manager/api/v1/global-infra/sites/<site-id>?action=reregister
{
  "site_connection_info": {
    "fqdn": "<lm-fqdn>",
    "username": "admin",
    "password": "<password>",
    "thumbprint": "<new-cert-thumbprint>"
  }
}

Transport Zone Mapping in Federation

Map transport zones across federation sites for consistent segment spanning

MediumTransport ZoneMappingFederation

Resolution

Configure transport zone spanning

# In Federation — Global TZ maps to Local TZs at each site:
# Global Overlay TZ → Site-A Local Overlay TZ + Site-B Local Overlay TZ

# On Global Manager — view TZ mapping:
GET https://<gm>/global-manager/api/v1/global-infra/sites/<site-id>/enforcement-points/default/transport-zones

# Create a stretched TZ mapping (done during site registration):
# GM automatically discovers and maps LM transport zones

# If mapping is incorrect — fix manually:
# Re-register site with correct TZ mapping
# Or create new GM transport zone and map to correct LM TZs

# Verify which segments can span which sites:
# Segment on stretched TZ → available at all mapped sites
# Segment on site-local TZ → only at that site

Federation Security Policy Span

Configure security policies that span multiple federation sites from Global Manager

HighFederationSecurityPolicy Span

Resolution

Create cross-site security policy on GM

# On Global Manager — create security policy:
PUT https://<gm>/global-manager/api/v1/global-infra/domains/default/security-policies/Cross-Site-Block
{
  "display_name": "Cross-Site-Quarantine",
  "category": "Emergency",
  "rules": [{
    "display_name": "Block-Compromised",
    "source_groups": ["/global-infra/domains/default/groups/Quarantine"],
    "destination_groups": ["ANY"],
    "action": "DROP",
    "scope": ["/global-infra/domains/default/groups/All-VMs"]
  }]
}

# This policy is pushed to ALL sites automatically
# Groups defined on GM are resolved at each site independently

# Verify policy realization at each site:
GET https://<gm>/global-manager/api/v1/global-infra/domains/default/security-policies/Cross-Site-Block/state

# Policy span options:
# "All Locations" — push to every LM
# "Specific Sites" — push only to selected sites