NSX Distributed Load balancer service reported as degraded in the NSX manager and an alarm is triggered in the UI as follows
Alarm level: Medium
Description:The load balancer service clusterip-domain-c8717xxxxxxxxxxxxxx is degraded.
Recommended Action:
For centralized load balancer: On standby Edge node, check load balancer status by invoking the NSX CLI command get load-balancer status . If the LB-State of load balancer service is not_ready or there is no output, make the Edge node enter maintenance mode, then exit maintenance mode. For distributed load balancer: 1. Get detailed status by invoking NSX-T API GET /policy/api/v1/infra/lb-services//detailed-status?source=realtime 2. From API output, find ESXi host reporting a non-zero instance_number with status NOT_READY or CONFLICT. 3. On ESXi host node, invoke the NSX CLI command get load-balancer status . If ''Conflict LSP''is reported, please check whether this LSP is attached to other load balancer service. Please check whether this conflict is acceptable. If ''Not Ready LSP'' is reported, please check the status of this LSP by invoking NSX CLI command get logical-switch-port status .
VMware NSX
Issue is caused due to the presence of a stale port in the NSX manager Corfu DB.
Check the NSX manager logs for entries similar to the following
2025-12-29T04:01:36.954Z INFO http-nio-127.0.0.1-7440-exec-56 AggSvcLbServiceImpl 5568 LOAD-BALANCER [nsx@6876 comp="nsx-manager" level="INFO" reqId="f03b4882-####-4a53-####-############" subcomp="manager" username="admin"] Set load balancer service 7172ba2f-####-4a2a-####-############ status as NODATA for transport node 9a5ff1e5-####-4cf4-####-############.
If the log entries match the line pasted above, open a support request with Broadcom Support: Creating and managing Broadcom support request (SR) cases