NSX load balancer backup pool member(s) do not automatically revert to backup pool member status once activated

Products

• VMware NSX

Issue/Introduction

• The Native NSX-T load balancer is configured for L4 TCP.
• Pool members are configured and there is a standby pool member.
• If an active pool member fails, the standby pool member takes over.
• When the failed member comes back online, it will be included in the pool again as active.
• The previously standby pool member will remain active.

Environment

VMware NSX

 

Cause

This is as per design, the standby pool member will remain active once activated.

Resolution

When the failed pool member is restored, edit the pool and make the desired pool member standby again.

You can consider the following options to manage the failover:

1. Custom Backup Pool Member Configuration

   • Add the primary server as the main pool member.
   • Add secondary servers as backup members.
   • Configure health monitoring for all members to ensure failover works when the primary fails.
   • Key Limitation: NSX does not automatically deactivate backup members when the primary recovers, requiring manual intervention or external automation to disable backups.

2. Weighted Member Priority (Manual Adjustment)

   • Use weight-based traffic distribution:
     • Assign the primary server the highest weight (e.g., 100).
     • Set backup servers to a weight of 0 or very low (e.g., 1).
   • This mimics active-passive behavior by ensuring the primary is always selected when available.
   • Challenge: The failback behavior is not strict, as all healthy members with non-zero weights could still receive traffic.

While these are workarounds, they do not strictly enforce the behavior outlined above, where the backup is disabled when the primary is restored.

Additional Information

For further insights on load balancer configurations, you can review the LB encyclopedia