In VMware NSX environments integrated with VMware Aria Operations for Networks (vRNI/AON), Distributed Firewall (DFW) flows may fail to appear in the vRNI user interface.
Live packet captures and kernel table queries (vsipioctl getflows) on the ESXi host confirm that allow/drop rules are triggering correctly and that traffic is being captured locally. However, the corresponding IPFIX flow records are not exported to the vRNI collector.
Additionally, attempts to manually delete a conflicting duplicate IPFIX profile through standard workflows may fail due to existing Group Profile Binding Maps associated with the profile.
VMware NSX: 4.2.2.1.0
VMware Aria Operations for Networks (vRNI/AON): 6.14.0
The issue is caused by a case-sensitivity discrepancy between integration API requests and the backend realization logic in NSX, combined with how the ESXi kernel handles conflicting system-wide IPFIX profiles.
An external integration (vRNI) creates a global profile using a lowercase identifier:
/infra/ipfix-dfw-profiles/globalLater, an administrator or third-party tool (for example, a Cisco collector integration) creates another profile using an uppercase identifier:
/infra/ipfix-dfw-profiles/GlobalequalsIgnoreCase) when validating global definitions. As a result, both distinct database entries (IpfixDfwConfig) are marked with apply_all=true ("Apply to all segments/VMs").apply_all=true simultaneously. In the observed scenario:Global profile was assigned Priority 1.global profile was assigned Priority 0.Global profile fails because it contains manually created Group Profile Binding Maps that must first be unmapped or reassigned.To restore DFW flow visibility in vRNI, remove or deactivate the unused duplicate global IPFIX profile.
If deletion of the duplicate profile fails due to existing Group Profile Binding Maps, open a Service Request (SR) with Broadcom Technical Support for assistance.