NSX IP Pool Usage Very High Alarm persists when usage is below 90% threshold
search cancel

NSX IP Pool Usage Very High Alarm persists when usage is below 90% threshold

book

Article ID: 429887

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

  • NSX Manager UI displays "IP Pool Usage Very High" alarm.
  • The alarm persists after deleting IP allocations.
  • Manual verification of the pool indicates usage is below 90%.

Environment

VMware NSX 9.x

Cause

The issue is caused by a default 2-minute release delay.

  1. When an IP is deleted, NSX does not immediately reflect the release in the total count (2-minute delay).
  2. If a new IP allocation (Create) occurs within this 2-minute window, the alarm logic fetches the pool usage.
  3. The stale (pre-delete) count is returned.
  4. The alarm logic perceives the threshold as breached and raises/maintains the alarm, despite the actual number of active allocations being lower.

Resolution

This is a known issue impacting VMware NSX 9.x. There is currently no resolution.

The following steps can be used to workaround this issue:

  1. Navigate to Home > Alarms.
  2. Locate the affected IP Pool alarm.
  3. Click the three dots (ellipsis) next to the alarm.
  4. Select Acknowledge.
    This prevents the monitoring sync from reopening the alarm while usage remains below the threshold.

Additional Information

Verification Steps:
To confirm this specific behavior, analyze the NSX logs:

  1. Search for the specific pool policy path to find the reported allocated count:

    zgrep "Checking poolusage of pool" /var/log/proton/nsxapi* | grep '<poolPolicyPath>'

    e.g:   zgrep "Checking poolusage of pool" nsx_manager_*/var/log/proton/nsxapi* | grep '/orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default'

    Results should look similar to the following:

    /var/log/proton/nsxapi.5.log.gz:2026-01-22T20:57:20.316Z INFO com.vmware.nsx.management.policy.ipam.service.IPAMRealizationUtils-1-1 IPAMRealizationUtils 79415 POLICY [nsx@4413 comp="nsx-manager" level="INFO" subcomp="manager"] Checking poolusage of pool /orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default with allocated ids 11 and total ids 12

    Note: This output indicates 11 out of 12 IPs were in use, above the 90% threshold.

  2. Identify Alarm Generation:

    zgrep "Generating alarm for IpPool" /var/log/proton/nsxapi*

    Results should look similar to the following:

    /var/log/proton/nsxapi.5.log.gz:2026-01-22T20:57:20.316Z INFO com.vmware.nsx.management.policy.ipam.service.IPAMRealizationUtils-1-1 IPAMRealizationUtils 79415 POLICY [nsx@4413 comp="nsx-manager" level="INFO" subcomp="manager"] Generating alarm for IpPool 0eeb21c0-####-####-####-e83101d489ce

  3. Look for alarm generation logs gathered from Step 2 which were generated around the timestamp noted in Step 1.
    Make a note of the timestamp.

  4. Check for Release (Delete) Operations:
    Verify if IPs were released just before the alarm:

    zgrep "is released into pool" nsx_manager_*/var/log/proton/nsxapi* | grep '<poolPolicyPath>/ip-allocations'

    e.g   zgrep  "is released into pool" nsx_manager_*/var/log/proton/nsxapi*  | grep '/orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default/ip-allocations'

    Results should look similar to the following:

    /var/log/proton/nsxapi.5.log.gz:2026-01-22T20:57:13.396Z INFO providerTaskExecutor-1-6 IpAddressAllocationServiceImpl 79415 POLICY [nsx@4413 comp="nsx-manager" level="INFO" subcomp="manager"] Allocated id /orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default/ip-allocations/0e33ecec-####-####-####-eadc4ffe147e is released into pool.

    Make a note of the timestamp.

  5. Check for Create Operations:
    Look for new allocations within 2 minutes of the release:

    zgrep "does not exist, creating" nsx_manager_*/var/log/proton/nsxapi* | grep '<poolPolicyPath>/ip-allocations'

    e.g   zgrep  "does not exist, creating" /var/log/proton/nsxapi*  | grep '/orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default/ip-allocations'

    Results should look similar to the following:

    /var/log/proton/nsxapi.6.log.gz:2026-01-20T20:23:27.159Z  INFO providerTaskExecutor-1-85 PolicyServiceImpl 79415 POLICY [nsx@4413 comp="nsx-manager" level="INFO" subcomp="manager"] Entity /orgs/default/projects/default/vpcs/vmware-system-supervisor-services-vpc_ce431bc4-####-####-####-3039fdb1ebfd/subnets/pod-default_641f788a-####-####-####-70837f82af66_9e385c1e/ip-pools/static-ipv4-default/ip-allocations/3d323968-####-####-####-76ed26690724 does not exist, creating

  6. If a Create operation (Step 5) happens within 2 minutes of a Release (Step 4) and matches the Alarm timestamp (Step 2), the issue is confirmed.
Powered by Wolken Software