NSX-T Enterprise Deployment: A Step-by-Step Guide from Our Largest Project
A manufacturing company with 5 factories needed a unified network across all sites. Each factory had its own network team, its own VLAN scheme, and its own firewall rules. When a worker transferred from one factory to another, they lost access to applications for days while the network team configured their access. NSX-T changed that. Here is how we deployed it.
What is NSX-T?
NSX-T is VMware's software-defined networking platform. It creates virtual networks, routers, and firewalls in software. Instead of configuring physical switches and firewalls, you configure everything through a centralized management interface.
NSX-T provides three core capabilities:
**Network Virtualization:** Create logical switches and routers that run on top of your physical network. These virtual networks are independent of the physical infrastructure. You can create, modify, and delete networks in minutes.
**Micro-segmentation:** The distributed firewall runs on every host and enforces security at the VM level. Every VM-to-VM connection is inspected. You can create granular security policies that follow VMs as they move between hosts.
**Automation:** NSX-T provides a complete REST API. Every operation that you can do through the UI can also be done through the API. This enables automation of network provisioning, security policy management, and operational tasks.
Why NSX-T for Multi-Site Enterprises
The manufacturing company's problem was network fragmentation. Five factories, five different networks, five different security policies. Workers transferring between factories lost application access for 2-3 days while network teams configured VLANs, firewall rules, and access controls.
NSX-T solves this through network virtualization and centralized management. Instead of per-site network configurations, you define network and security policies once and apply them across all sites. When a worker transfers, their network access follows them automatically.
The numbers tell the story. After NSX-T deployment, worker transfers went from 2-3 days of network configuration to 15 minutes. Security policy changes that took 1 week across 5 sites now take 10 minutes from a single console. And micro-segmentation reduced the attack surface by 75%.
Our Step-by-Step Deployment
We deployed NSX-T across the manufacturing company's 5 factories in 16 weeks. Here is the step-by-step process.
Step 1: Physical Network Assessment (Week 1-2)
NSX-T runs on top of a physical network. We assessed the physical network at each factory:
- Main factory: 25GbE spine-leaf, 20 ESXi hosts
- Factory 2: 10GbE spine-leaf, 12 ESXi hosts
- Factory 3: 10GbE spine-leaf, 10 ESXi hosts
- Factory 4: 1GbE access switches, 8 ESXi hosts
- Factory 5: 1GbE access switches, 6 ESXi hosts
Factories 1-3 had modern networks suitable for NSX-T overlay. Factories 4-5 needed network upgrades. We upgraded Factory 4-5 to 10GbE before deploying NSX-T.
One lesson learned: NSX-T does not fix a bad physical network. It runs on top of it. If your physical network is unreliable, NSX-T will not help. Invest in the physical network first.
Step 2: NSX-T Manager Deployment (Week 3-4)
We deployed a three-node NSX-T Manager cluster at the main factory. The managers handle API requests, compute overlay mappings, and distribute firewall policies.
NSX-T Manager requirements: 4 vCPUs, 16GB RAM, 200GB storage per node. We placed the managers in a dedicated management cluster separate from production workloads.
For multi-site management, we used NSX-T Federation. The main factory's NSX-T Manager acts as the global manager. Each factory has a local manager that handles site-specific operations. Federation extends logical networking across sites while keeping control plane traffic local.
Step 3: Transport Zone Configuration (Week 5-6)
A transport zone defines the scope of NSX-T networking. We created transport zones per factory. Each factory's hosts participate only in its local transport zone. This keeps overlay traffic local.
For cross-site connectivity, we used NSX-T Logical Router peering through the physical network. Inter-site traffic routes through the physical WAN links. We configured BGP peering between NSX-T Edge nodes at each site.
The transport zone design was critical. We initially planned a single transport zone for all sites. This would have caused all overlay traffic to traverse the WAN. The per-site transport zone design keeps most traffic local.
Step 4: Edge Node Deployment (Week 7-8)
NSX-T Edge nodes provide connectivity between the NSX-T overlay and the physical network. We deployed two Edge nodes per site in an active-active configuration.
Each Edge node runs a Tier-0 (T0) logical router that connects to the physical network via BGP. The T0 router handles north-south traffic (traffic entering or leaving the NSX-T overlay).
We also configured Tier-1 (T1) logical routers for each tenant (factory). T1 routers connect to the T0 router and handle east-west routing between logical switches within a site.
Edge sizing is critical. We sized each Edge node for 3x expected peak traffic. Undersized Edges become bottlenecks. We use dedicated physical servers for Edge nodes to avoid resource contention with production workloads.
Step 5: Logical Switch and Router Configuration (Week 9-10)
We created logical switches for each function: production, guest WiFi, IoT devices, voice VLAN, and management. Each logical switch is an independent broadcast domain.
For routing between logical switches, we deployed distributed logical routers (DLRs). DLRs run on every ESXi host and provide hop-by-hop routing. Traffic between VMs on different logical switches routes through the local DLR without hitting a central router.
The logical network design followed the physical network structure. We mirrored existing VLANs as logical switches. This simplified migration because VMs kept their IP addresses when moving to NSX-T.
Step 6: Distributed Firewall Configuration (Week 11-12)
The distributed firewall is NSX-T's most powerful feature. We created 300+ firewall rules based on identity, not IP address.
Rules reference VM names, tags, and security groups. When a VM moves between hosts, the firewall rules follow it automatically. We created dynamic security groups based on VM attributes: Department=Production, Environment=Factory1, OS=Windows.
The firewall rules were organized by function:
**Intra-factory rules:** Allow production VMs to communicate within their factory. Block guest WiFi from accessing production. Block IoT devices from accessing anything except their management server.
**Inter-factory rules:** Allow specific application traffic between factories (ERP replication, file sharing). Block everything else between factories.
**Internet rules:** Allow outbound HTTPS for all VMs. Block all other outbound traffic. Monitor and log all internet connections.
Step 7: Migration and Testing (Week 13-16)
We migrated VMs to NSX-T logical switches in phases. Each factory migrated independently over one weekend.
Migration was straightforward because we mirrored the existing VLAN scheme. VMs kept their IP addresses and network configurations. The only change was the underlying transport (VLAN to NSX-T overlay).
We tested connectivity, security policies, and performance after each factory migration. Any issues were resolved before migrating the next factory.
The migration took 4 weeks (one factory per weekend). After all factories were on NSX-T, we conducted cross-site connectivity testing.
Best Practices
Based on this deployment and 10 others, here are our top practices.
**Design for your physical network.** NSX-T overlay performance depends on the physical network. Invest in 10GbE minimum, 25GbE preferred. Use leaf-spine architecture for scalability.
**Start with micro-segmentation.** Even without changing your network design, adding distributed firewall rules dramatically improves security. Start with a default-deny rule and add exceptions as needed.
**Use tags and security groups.** Do not hard-code IP addresses in firewall rules. Use VM tags and dynamic security groups. When VMs change, rules update automatically.
**Monitor overlay traffic.** NSX-T overlay traffic is encrypted, which makes troubleshooting harder. Deploy flow monitoring and packet capture for debugging.
**Test failover scenarios.** Edge failover takes 30-60 seconds. Test it under load. Configure BFD for fast failover.
Common Mistakes
**Mistake 1: Single transport zone for all sites.** This causes all traffic to traverse the WAN. Use per-site transport zones and route inter-site traffic through physical links.
**Mistake 2: Undersized Edge nodes.** Edge nodes handle all north-south traffic. Size for 3x peak traffic. Use dedicated physical servers for Edges.
**Mistake 3: Hard-coding IP addresses in firewall rules.** When VMs change, rules break. Use tags and security groups for dynamic rule assignment.
**Mistake 4: Skipping monitoring.** NSX-T overlay traffic is opaque without proper monitoring. Deploy flow monitoring, packet capture, and NSX-T Intelligence from day one.
**Mistake 5: Migrating all at once.** Migrate one factory at a time. Test thoroughly before migrating the next. Phased migration limits blast radius.
Conclusion
NSX-T transforms enterprise networking from fragmented to unified. The manufacturing company went from 5 independent networks to 1 unified platform. Worker transfers went from 2-3 days to 15 minutes. Security policy management went from 5 consoles to 1.
The investment is significant: hardware upgrades, licensing, and professional services. But the return is clear: unified management, improved security, and faster operations. For multi-site enterprises, NSX-T is the right foundation.
Start with physical network assessment. Deploy NSX-T Manager and Edges. Configure logical networking and firewall. Migrate in phases. Test thoroughly. And monitor continuously.
Want to go deeper? Explore [VMware alternatives](/en/vmware-alternative), [Run infrastructure services](/en/products/run), or [platform comparison](/en/compare).
FAQ
**Q: How many Edge nodes do I need per site?**
A: Minimum 2 per site for redundancy. For sites with more than 500 VMs, consider 4 Edges. Size each Edge for 3x expected peak traffic.
**Q: Can NSX-T work with non-VMware hypervisors?**
A: Yes. NSX-T supports KVM hypervisors. For pure VMware environments, NSX-T provides the deepest integration. For mixed environments, NSX-T works with reduced feature set.
**Q: What is the maximum number of logical switches?**
A: NSX-T supports up to 12,000 logical switches. In practice, most enterprises use 50-200. Design your logical switch hierarchy carefully to avoid management complexity.
**Q: How does NSX-T handle cross-site traffic?**
A: Cross-site traffic routes through the physical WAN. NSX-T Edge nodes at each site peer via BGP. Logical routers at each site route traffic to the Edge for WAN traversal.
**Q: Can I use NSX-T for cloud connectivity?**
A: Yes. NSX-T Edge nodes can establish IPsec VPN tunnels to cloud providers (AWS, Azure, GCP). This provides secure connectivity between on-premises NSX-T and cloud VPCs/VNets.