- Federation is optional and adds one Global Manager console over two or more NSX Local Managers.
- Deploy Global Manager nodes as a three node cluster, Large form factor, in the management domain of each instance you make active or standby.
- SDDC Manager does not manage Global Manager lifecycle, so you deploy, back up, and upgrade those nodes by hand.
- Make one Global Manager cluster active, add a standby, then add each location and import its Local Manager once.
- For stretched gateways and segments, configure an RTEP on the Edge nodes in every location.
- Keep round trip latency at 150 ms or less for stretched networks, 500 ms or less otherwise.
NSX Federation gives you a single Global Manager pane over the NSX Local Managers that already run inside each VCF 9.1 instance. From that Global Manager you create tier 0 and tier 1 gateways, segments, and firewall policy once, and it synchronizes each object to only the locations you assign. Each existing NSX Manager becomes a Local Manager after you import it, and it keeps running the daily networking for its own instance.
Because VCF 9.1 builds each instance with its own vCenter, SDDC Manager, and NSX Manager, federation sits on top of the automated build rather than inside it. You deploy and operate the Global Manager nodes yourself, and you keep separate backups for them. This part shows the click by click sequence to stand up federation, import both Local Managers, enable stretched networking, and verify that synchronization works. For how VCF Operations and SDDC Manager divide ownership across the fleet, see the Day-2 operations overview.
Prerequisites
Confirm each item below before you touch federation. Missing routing or version drift between instances is the usual cause of a stalled import.
| Item | Requirement | Where to check |
|---|---|---|
| Two VCF 9.1 instances | Each fully deployed with its own vCenter, SDDC Manager, and NSX Manager on 9.1 | SDDC Manager, VCF Operations |
| NSX version parity | Both Local Managers on the same NSX version shipped with VCF 9.1 | NSX Manager, Appliances page |
| Global Manager capacity | Compute and storage for three Global Manager nodes per active and standby cluster | Management domain vCenter |
| Site to site routing | Reachability between manager networks and between Edge RTEP networks | Physical network, firewall |
| Admin credentials | admin and enterprise admin on each NSX Manager and the Global Manager | Credential store, Part 6 |
Latency and port requirements
Confirm the values below against the NSX Federation requirements before you add locations.
| Requirement | Value | Notes |
|---|---|---|
| Round trip latency, stretched networks | 150 ms or less | Between the Global Manager and each location |
| Round trip latency, non stretched | 500 ms or less | Management plane sync only |
| Manager to manager control | TCP 1235 open | Global Manager to Local Manager, both directions |
| RTEP tunnels | UDP 6081 open | Geneve traffic between Edge RTEP networks |
| NSX version | Identical across instances | Import fails on version drift |
Step 1, Deploy the Global Manager nodes
You deploy the Global Manager as a three node cluster in the management domain of the instance that hosts the active cluster. Use the NSX unified appliance OVF and select the Global Manager role. This step uses vCenter.
- Log in to the management domain vCenter for the instance that will host the active Global Manager.
- Right click the target cluster and select Deploy OVF Template.
- Point the wizard at the NSX unified appliance OVA that matches your VCF 9.1 NSX version, then click Next.
- On the configuration screen, set the deployment size to Large and set Rolename to NSX Global Manager.
- Enter the management IPv4 address, netmask, default gateway, DNS server list, and NTP server list for the first node.
- Set the System Root, CLI admin, and Audit passwords, then click Next.
- Review the specification, click Finish, and power on the node.
- Repeat to deploy two more Global Manager nodes so the cluster has three members.
Step 2, Make the Global Manager cluster active
After the three nodes form a cluster, you set a cluster virtual IP and mark the cluster active. This step uses the NSX Global Manager interface.
- Open a browser to the first Global Manager node and sign in as admin.
- Go to System, then Appliances, and confirm all three nodes show a stable cluster.
- Set the cluster Virtual IP so you reach the Global Manager on one address.
- Go to System, then Location Manager.
- Click Make Active and enter a name for this Global Manager, for example gm-primary.
- Click Save and wait for the status to read Active.
Step 3, Add a standby Global Manager
A standby cluster in the second instance keeps the global configuration available if the active site is lost. This step is optional but recommended for two site designs, and it uses the NSX Global Manager interface.
- Deploy a second three node Global Manager cluster in the other instance using Step 1.
- On the active Global Manager, go to System, then Location Manager.
- Click Add Standby.
- Enter the standby cluster FQDN or VIP, its admin credentials, and the node certificate thumbprint.
- Click Save and confirm the standby reports a Synced state.
Step 4, Add each location and import the Local Manager
Each existing NSX Manager joins federation as a Local Manager. Import copies its objects into the Global Manager one time, so plan the order and content of each import. This step uses the NSX Global Manager interface.
- On the active Global Manager, go to System, then Location Manager.
- Click Add Location.
- In the Add New Location dialog, enter a location name, the Local Manager FQDN or VIP, and its admin credentials.
- Confirm the certificate thumbprint and click Save.
- When prompted, choose Import to bring the Local Manager objects into the Global Manager, then confirm.
- Repeat for the Local Manager in the second instance.
- Watch each location tile until it reports a green, synchronized status.
Step 5, Configure RTEP on Edge nodes for stretched networking
Stretched gateways and segments send cross location traffic over remote tunnel endpoints. You configure an RTEP on the Edge nodes in each location. This step uses the NSX Local Manager interface.
- Sign in to the Local Manager for the first location.
- Go to System, then Get Started.
- Click Configure Remote Tunnel Endpoint.
- Select the Edge Cluster and the Edge nodes that will carry cross location traffic.
- Enter the RTEP VLAN and select or create an IP Pool for the RTEP interfaces.
- Click Save and wait for the tunnels to come up.
- Repeat on the Local Manager in the second location.
You can also reach this from the active Global Manager under System, then Location Manager, then the Networking panel for the location, where Configure on the RTEP row opens the same settings.
Step 6, Create stretched gateways and segments from the Global Manager
With locations added and RTEP up, you build objects once on the Global Manager and assign them to the locations that need them. This step uses the NSX Global Manager interface.
- On the active Global Manager, go to Networking, then Tier-0 Gateways.
- Click Add Gateway and select Tier-0.
- In Locations, add both locations, then set one primary and one secondary for failover.
- Save the gateway, then add a Tier-1 Gateway and connect it where needed.
- Go to Networking, then Segments, and click Add Segment.
- Attach the segment to the stretched gateway, set its Span to both locations, and click Save.
Which console owns each task
Federation spreads work across several consoles, and each one keeps a clear job. Use this mapping so you open the right console for every change and avoid duplicate edits on a Local Manager that the Global Manager already owns.
| Task | Console | Notes |
|---|---|---|
| Deploy Global Manager nodes | vCenter | OVF deploy in the management domain |
| Make active, add standby, add locations | NSX Global Manager | Location Manager panel |
| Import Local Manager objects | NSX Global Manager | One time per location |
| Configure RTEP for stretched traffic | NSX Local Manager | Also reachable from the Location Manager networking panel |
| Create stretched gateways and segments | NSX Global Manager | Assign span per object |
| Add hosts or clusters to a domain | SDDC Manager | Domain operations stay unchanged by federation |
| Fleet health and lifecycle | VCF Operations | Owns upgrades and health across both instances |
Verify the federation is working
Check synchronization from the console first, then confirm state through the API.
- On the active Global Manager, open System, then Location Manager, and confirm every location tile is green with no pending sync.
- Open the NSX Federation monitoring dashboard and confirm no unresolved alarms for any location.
- From a Local Manager, confirm the imported gateways and segments appear with a Global Manager origin.
- In VCF Operations, confirm both instances still report healthy after the change.
Query realized state alarms on the Global Manager, then on each Local Manager. An empty results list means no realization errors.
GET https://gm-primary.example.com/global-manager/api/v1/global-infra/realized-state/alarms GET https://lm-a.example.com/policy/api/v1/infra/realized-state/alarms
For continuous alerting on both instances after federation is live, wire the health checks in Part 18. Because SDDC Manager does not back up the Global Manager, add its nodes to your manual NSX backup routine described in Part 9.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Import fails or hangs | Version drift, or a centralized transit gateway on the Local Manager | Match NSX versions across instances, remove the centralized transit gateway, then retry the import |
| Location tile red, control plane down | TCP 1235 blocked between Global Manager and Local Manager | Open the federation ports on the site to site path and confirm routing both ways |
| Stretched segment carries no cross location traffic | RTEP not configured, or Geneve UDP 6081 blocked between Edge networks | Configure RTEP on Edge nodes in both locations, open UDP 6081, and verify tunnels are up |
| Standby will not sync | Certificate thumbprint mismatch, or latency above the limit | Re-enter the correct thumbprint and confirm round trip latency stays within the requirement |
Common questions
Does SDDC Manager configure NSX Federation for me?
No. Federation is a manual, optional overlay. SDDC Manager and VCF Operations keep managing each instance, while you deploy and operate the Global Manager nodes yourself.
Do I need a standby Global Manager?
Not to start. One active cluster runs federation. A standby cluster in the second instance protects the global configuration if the active site is lost, so most two site designs add one.
Can I stretch a network without RTEP?
No. Cross location segments need remote tunnel endpoints on the Edge nodes in each location. Without RTEP you can still manage both locations from one console, but traffic will not stretch.
How do backups change under federation?
Add the Global Manager to your manual NSX backup routine. See Part 9 for backing up NSX Manager, and remember that SDDC Manager does not cover the Global Manager nodes.
References
- Getting Started with NSX Federation, VCF 9 Administration Guide
- Add a Location to the Global Manager
- Upgrading NSX Global Manager Nodes in a Federated Environment, VCF 9.1
- Understanding NSX Federation
About The Author
