Tier-1 gateway status becomes "Failed" when it is linked to a VRF with the same name that was recreated.

Products

• VMware NSX

Issue/Introduction

• Tier-1 gateway status becomes "Failed" with error:
  "The requested object : LrPort/c52e####-####-####-####-########f985 could not be found. Object identifiers are case sensitive."
  
• A VRF was previously connected to a Tier-0 gateway, with the Tier-1 gateway linked to it.
• The original VRF was deleted, a new VRF with the same name was created, connected it to another Tier-0 gateway, and the Tier-1 gateway was attached to the new VRF.
• This issue does not occur if VRF is created with a different name.
• In the NSX Manager's logging, you will see the ObjectNotFoundException after the IpBlockSubnetAllocatorDeallocator task:

/var/log/proton/nsxapi.log
2025-06-17T06:35:00.383Z  WARN providerTaskExecutor-1-138 TransactionRetryAspect 5016 - [nsx@6876 comp="nsx-manager" level="WARNING" subcomp="manager"] Detected an active transaction retry aspect for Identifier com.vmware.nsx.management.idas.ipam.service.IpBlockServiceImpl._createBlockSubnetWithMarker(Identifier, IpBlockSubnet, String), hence ignoring this.
2025-06-17T06:35:00.383Z  INFO providerTaskExecutor-1-138 IpBlockSubnetAllocatorDeallocator 5016 POOL-MGMT [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Starting Allocation for subnet block with size 2
2025-06-17T06:35:00.384Z  INFO providerTaskExecutor-1-138 IpBlockSubnetAllocatorDeallocator 5016 POOL-MGMT [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Getting low ip address for block IpBlock[100.64.##.##/16] of type ipv4
2025-06-17T06:35:00.384Z  INFO providerTaskExecutor-1-138 IpBlockSubnetAllocatorDeallocator 5016 POOL-MGMT [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Getting high ip address for block IpBlock[100.64.##.##/16] of type ipv4
2025-06-17T06:35:00.384Z  INFO providerTaskExecutor-1-138 IpBlockSubnetAllocatorDeallocator 5016 POOL-MGMT [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Subnet available size 65536 for block id IpBlock/########-####-####-####-########
2025-06-17T06:35:00.385Z  INFO providerTaskExecutor-1-138 IpBlockSubnetAllocatorDeallocator 5016 POOL-MGMT [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Found node IpBlockSubnetNode [size=2, id=IpBlockSubnetNode/########-####-####-####-########, isAllocated=false, startIpInt=########, endIpInt=null, leftSubnetNodeId=none, rightSubnetNodeId=none, parentId=none, isLeft=true]
2025-06-17T06:35:00.388Z ERROR providerTaskExecutor-1-138 PolicyProviderUtil 5016 POLICY [nsx@6876 comp="nsx-manager" errorCode="PM500015" level="ERROR" subcomp="manager"] Unexpected exception received during provider invocation.
com.vmware.nsx.management.common.exceptions.ObjectNotFoundException: null
        at com.vmware.nsx.management.container.dao.IdentifiableProxyObjectDao.findByIdentifier(IdentifiableProxyObjectDao.java:400) ~[?:?]
        at com.vmware.nsx.management.edge.lrouter.ports.dao.LRPortDaoImpl.findLRPortByIdentifier(LRPortDaoImpl.java:162) ~[?:?]
        at com.vmware.nsx.management.edge.lrouter.ports.dao.LRPortDaoImpl.findLRPort(LRPortDaoImpl.java:151) ~[?:?]
        at com.vmware.nsx.management.edge.lrouter.ports.service.LRPortsServiceImpl.getLRPort(LRPortsServiceImpl.java:346) ~[?:?]
        .....

Environment

VMware NSX 4.x

Resolution

This issue is resolved in VMware NSX 4.2.3.2, and in VCF 9.0.2, available at Broadcom downloads.

If you are having difficulty finding and downloading software, please review the Download Broadcom products and software KB.

 

Workaround:

There are two known workarounds for this issue:

1. Using NSX UI, edit the Tier-0 gateway and make a non-configuration changing edit (e.g. add a description), and save the configuration. 
   If this mitigates the issue, the change can then be reverted. 
   
   
2. Recreate the Tier-0 gateway with a different name:
   1. Disconnect the Tier-1 gateway from the affected VRF/Tier-0 gateway.
   2. Delete the VRF/Tier-0 gateway.
   3. Create a new Tier-0 VRF with a temporary unique name (e.g., VRF_Name_Temp).
   4. Rename the new Tier-0 VRF to the original desired name.
   5. Reconnect the Tier-1 Gateway.