NSX for vSphere requirements impact both physical and virtual networks.

Physical requirements determine the MTU size for networks that carry VLAN traffic, dynamic routing support, type synchronization through an NTP server, and forward and reverse DNS resolution.



Any network that carries VXLAN traffic must have an MTU size of 1600 or greater.

VXLAN packets cannot be fragmented. The MTU size must be large enough to support extra encapsulation overhead.

This design uses jumbo frames, MTU size of 9000, for VXLAN traffic.

For the hybrid replication mode, Internet Group Management Protocol (IGMP) snooping must be enabled on the Layer 2 switches to which ESXi hosts that participate in VXLAN are attached. IGMP querier must be enabled on the connected router or Layer 3 switch.

IGMP snooping on Layer 2 switches is a requirement of the hybrid replication mode. Hybrid replication mode is the recommended replication mode for broadcast, unknown unicast, and multicast (BUM) traffic when deploying into an environment with large scale-out potential. The traditional requirement for Protocol Independent Multicast (PIM) is removed.

Dynamic routing support on the upstream Layer 3 data center switches must be enabled.

Enable a dynamic routing protocol supported by NSX on the upstream data center switches to establish dynamic routing adjacency with the ESGs.

NTP server must be available.

The NSX Manager requires NTP settings that synchronize it with the rest of the vSphere environment. Drift can cause problems with authentication. The NSX Manager must be in sync with the vCenter Single Sign-On service on the Platform Services Controller.

Forward and reverse DNS resolution for all management VMs must be established.

The NSX Controller nodes do not require DNS entries.

The following table lists the components involved in the NSX for vSphere solution and the requirements for installing and running them. The compute and storage requirements have been taken into account when sizing resources to support the NSX for vSphere solution.


NSX ESG sizing can vary with tenant requirements, so all options are listed.





Quantity per Stack Instance

NSX Manager


16 GB

60 GB


NSX Controller


4 GB

20 GB



1 (Compact)

2 (Large)

4 (Quad Large)

6 (X-Large)

512 MB (Compact)

1 GB (Large)

1 GB (Quad Large)

8 GB (X-Large)

512 MB

512 MB

512 MB

4.5 GB (X-Large)

(+4 GB with swap)

Optional component. Deployment of the NSX ESG varies per use case.

DLR control VM


512 MB

512 MB

Optional component. Varies with use case. Typically 2 per HA pair.

Guest introspection


1 GB

4 GB

Optional component. 1 per ESXi host.

NSX data security


512 MB

6 GB

Optional component.1 per ESXi host.

The Quad Large model is suitable for high performance firewall abilities and the X-Large is suitable for both high performance load balancing and routing.

You can convert between NSX Edge service gateway sizes upon demand using a non-disruptive upgrade process, so the recommendation is to begin with the Large model and scale up if necessary. A Large NSX Edge service gateway is suitable for medium firewall performance but as detailed later, the NSX Edge service gateway does not perform the majority of firewall functions.


Edge service gateway throughput is influenced by the WAN circuit. An adaptable approach, that is, converting as necessary, is recommended.

NSX Edge Service Gateway Sizing Design Decision

Decision ID

Design Decision

Design Justification

Design Implications


Use large size NSX Edge service gateways.

The large size provides all the performance characteristics needed even in the event of a failure.

A larger size would also provide the performance required but at the expense of extra resources that wouldn't be used.