VCF NSX Edge Profile-Based Core Allocation

Products

VMware NSX

Issue/Introduction

VCF NSX administrators have the ability to customize the CPU core allocation of NSX Edge nodes to better align with specific workloads. Traditionally, NSX Edge uses a static even distribution of core allocation between datapath and linux. With Profile-Based Datapath Core Allocation, you can significantly enhance the performance of your deployment by selecting a profile tailored for your specific use case—whether your primary focus is high-throughput packet forwarding, advanced security services, or load balancing.

CRITICAL NOTE: Changing the core allocation profile post-deployment is not dynamic. You must reboot the Edge node for the new core profile configuration to take effect if you are modifying an existing node. If the node is deployed natively with a specific core profile, a reboot is not required.

Environment

VCF 9.1.1 and newer

Cause

NSX Edge nodes use a static core allocation by default, which does not account for workload-specific requirements. Different workloads — such as raw L4 packet forwarding, L7 Load Balancing, or L4 Load Balancing — require different balances of fast-path datapath cores versus Linux cores. Without profile-based allocation, performance could be suboptimal for specialized deployments.

Available core allocation profiles:


L4Forwarding	High-throughput routing, raw Layer 4 packet forwarding, NAT, and Layer 4 Firewall workloads.	75% datapath cores, 25% Linux cores	L7 services (L7 LB, L7 FW, IDS/IPS) are in use	Baremetal Edge
SECURITY	Tailored for Edge nodes dedicated to edge-level advanced security inspection, such as Gateway IDS/IPS, TLS/SSL decryption for security scanning. It provides an expanded Linux footprint to manage security policies while retaining the dedicated service cores necessary to handle intensive deep packet inspection engines.	25% datapath cores, 25% service cores, 50% Linux cores	Max throughput for forwarding/L4 is required	Baremetal Edge XLarge Edge VM

L4Forwarding

High-throughput routing, raw Layer 4 packet forwarding, NAT, and Layer 4 Firewall workloads.

75% datapath cores,

25% Linux cores

L7 services (L7 LB, L7 FW, IDS/IPS) are in use

Baremetal Edge

SECURITY

Tailored for Edge nodes dedicated to edge-level advanced security inspection, such as Gateway IDS/IPS, TLS/SSL decryption for security scanning. It provides an expanded Linux footprint to manage security policies while retaining the dedicated service cores necessary to handle intensive deep packet inspection engines.

25% datapath cores, 25% service cores, 50% Linux cores

Max throughput for forwarding/L4 is required

Baremetal Edge
XLarge Edge VM

Resolution

Step 1 — Configure the profile

Select the desired core allocation profile via NSX Manager UI or REST API when creating or updating an Edge Cluster.

Management Plane (MP) API method (NSX 9.1.1):

Create Edge Cluster (can also be done via NSX UI): POST https://<nsx-manager-FQDN>/api/v1/edge-clusters
Update Edge Cluster: PUT /api/v1/edge-clusters/<edge-cluster-id>Pass the parameter core_allocation_profile in the JSON payload with the desired profile name in this step - the two profile names L4Forwarding and SECURITY are detailed under the Cause section above
Get Edge Cluster Config: GET /api/v1/edge-clusters/<edge-cluster-id>
Get Edge Cluster State: GET /api/v1/edge-clusters/<edge-cluster-id>/state

Sub-steps 3 and 4 above are validation steps to ensure that the selected profile was successfully applied.

Policy API method:

This method will be used when MP API is unavailable:

Create/Update the NSX Edge cluster: PATCH /api/v1/infra/sites/default/enforcement-points/default/edge-clusters/<edge-cluster-id>
Create/Update: PUT /api/v1/infra/sites/default/enforcement-points/default/edge-clusters/<edge-cluster-id>Pass the parameter core_allocation_profile in the JSON payload with the desired profile name in this step - the two profile names L4Forwarding and SECURITY are detailed under the Cause section above
Read Config: GET /api/v1/infra/sites/default/enforcement-points/default/edge-clusters/<edge-cluster-id>
Read State: GET /api/v1/infra/sites/<siteId>/enforcement-points/<edgecluster-id>/state

Sub-steps 3 and 4 above are validation steps to ensure that the selected profile was successfully applied.

Step 2 — Reboot (if updating an existing node)

Manually reboot the affected Edge node in the cluster. An alarm will be raised on the node indicating a profile mismatch is pending reboot; the alarm clears automatically once the node reboots successfully.

Step 3 — Verify

Once the node is back online (or freshly deployed), confirm the new core allocation profile is applied and resources have been redistributed per the selected profile using Edge Cluster API:

GET /api/v1/edge-clusters/<edge-cluster-id>/state
GET /api/v1/infra/sites/<siteId>/enforcement-points/<edgecluster-id>/state