Stale Transport Zone Profiles with no association with a Transport Zone fail to delete with a NullPointerException error

Products

• VMware NSX

Issue/Introduction

• It has been identified that NSX upgrade prechecks are failing due to the known issue described in KB NSX Host or Edge Transport Nodes have a status of "Unknown" and Tunnels are "Not Available" or "Validation Errors". The workaround\fix from that KB has been applied but you want to delete the stale Transport Zone Profiles.

• Potential stale Transport Zone profiles not associated with any TransportZone or TransportNodes can be identified in the Management Plane using an API like the following:

GET https://<nsxmanager>/api/v1/transportzone-profiles?include_system_owned=true

• The results from the API above will provide a full list of Transport Zone Profiles configured. If created by vRNI\Aria Operations for Networks, then the potential stale entries will have the text "vRNI-BFD_Profile" in the "display_name" attribute. Otherwise, it could have any "display_name" if the TZP was created manually. The following is an example of one of those TZP's:

{
        "_create_time": 1697561692012,
        "_create_user": "admin",
        "_last_modified_time": 1697561692012,
        "_last_modified_user": "admin",
        "_protection": "NOT_PROTECTED",
        "_revision": 0,
        "_system_owned": false,
        "display_name": "vRNI-BFD_Profile_<#########>",
        "enabled": true,
        "id": "<tz-profile UUID>",
        "latency_enabled": true,
        "probe_interval": 1000,
        "resource_type": "BfdHealthMonitoringProfile",
        "tags": []
      },

• Whether the TZP is actually stale can be confirmed by getting the results of the following GET API command. The results returned will be a list of Transport Zones, which can then be grepped through to confirm if the UUID of the TZP is referenced by any of the Transport Zones:

GET https://<nsx-manager>/policy/api/v1/infra/sites/{site-id}/enforcement-points/{enforcementpoint-id}/transport-zones

• If it is not stale then the UUID of the TZP will be referenced in the "profile_id" attribute of a Transport Zone. Below is an example of those attributes in a Transport Zone config:

{
        "_create_time": 1688732180001,
        "_create_user": "system",
        "_last_modified_time": 1720460255294,
        "_last_modified_user": "admin",
        "_protection": "NOT_PROTECTED",
        "_revision": 13,
        "_schema": "/v1/schema/TransportZone",
        "_system_owned": false,
        "display_name": "nsx-overlay-transportzone",
        "id": "<TZ_UUID>",
        "is_default": false,
        "nested_nsx": false,
        "resource_type": "TransportZone",
        "transport_type": "OVERLAY",
        "transport_zone_profile_ids": [
          {
            "profile_id": "<Transport Zone Profile UUID>",
            "resource_type": "BfdHealthMonitoringProfile"
          }
        ]
      },

• Deletion of the stale Transport Zone profiles returns the following error:

DELETE https://<nsxmanager>/policy/api/v1/transportzone-profiles/<uuid>

Error: 
{ 
    "module_name": "common-services", 
    "error_message": "General error has occurred.", 
    "details": "java.lang.NullPointerException", 
    "error_code": 100
}

• In the NSX Manager logs in /var/log/proton/nsxapi.log the following error and backtrace is returned:

2024-07-17T11:00:47.185Z ERROR http-nio-127.0.0.1-7440-exec-42 NsxBaseRestController 4230 SYSTEM [nsx@6876 comp="nsx-manager" errorCode="MP100" level="ERROR" subcomp="manager"]
java.lang.NullPointerException: null
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_372]
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_372]
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_372]
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_372]
        at java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) ~[?:1.8.0_372]
        at java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677) ~[?:1.8.0_372]
        at java.util.concurrent.ForkJoinTask.join(ForkJoinTask.java:720) ~[?:1.8.0_372]
        at org.corfudb.runtime.collections.Table.scanAndFilterByEntry(Table.java:394) ~[?:?]
        at org.corfudb.runtime.collections.TxnContext.executeQuery(TxnContext.java:565) ~[?:?] 

• You are running VMware NSX 3.2.4 or 4.1.1 and below.

Environment

VMware NSX-T

Cause

There is an issue in the code flow while deleting the stale Transport Zone Profiles. 

 

Resolution

• This issue is resolved in VMware NSX 3.2.4 and 4.1.1, available at Broadcom downloads.
• The fix will allow for the successful deletion of Transport Zone Profiles using the API. In addition, it will allow vRNI\Aria Operations for Networks to successfully delete its TZP's when its being removed as it relies on the same API calls.
• If you believe you have encountered this issue and are unable to upgrade, please open a support case with Broadcom Support NSX-T GSS and refer to this KB article. 
  For more information, see Creating and managing Broadcom support cases.