NSX Load Balancer Status Shows as "Unknown" when Using source=realtime API Query
search cancel

NSX Load Balancer Status Shows as "Unknown" when Using source=realtime API Query

book

Article ID: 448588

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • The NSX Manager UI or API displays a status of "Unknown" for Load Balancer services, virtual servers, or pools.
  • API queries using the parameter source=realtime take significantly longer to respond (e.g., >20 seconds).
  • The issue specifically affects XL Load Balancer configurations.
  • API queries without the source=realtime parameter (or using source=cached) return status correctly (e.g., "UP" or "Success").

Cause

The issue is caused by a timeout during the real-time status collection process. When the source=realtime parameter is used, the NSX Manager must actively poll the Edge transport nodes for the current state of all Load Balancer components.

For XL Load Balancer services or those with a high volume of virtual servers, the processing time to aggregate this data can exceed the internal communication timeout (often 20 seconds). If the NSX Manager does not receive a response from the Edge within this window, it records the status as "Unknown". This can be exacerbated by external automation or scripts (e.g., Python aiohttp clients) that frequently poll the API with the real-time flag.

Resolution

To resolve this issue, adjust the method of status retrieval to reduce the load on the management plane and Edge transport nodes:

  1. Use Cached Status: Modify API calls to use source=cached instead of source=realtime.
    • Example Query: GET /policy/api/v1/infra/lb-services/<lb-service-id>/detailed-status?source=cached
    • This retrieves the last known status from the NSX database, which is populated by the management plane's background refresh cycle, avoiding the 20-second real-time polling delay.
  2. Optimize Automation: If using external monitoring scripts, ensure they are not polling the real-time API at high frequencies. For large-scale environments, increase the polling interval or rely on the cached source.
  3. Cleanup Inactive Objects: Remove or deactivate "Down" or unused virtual servers and pool members to reduce the metadata payload processed during status checks