NSX DFW Flows Are Not Reported or Visible in VMware Aria Operations for Networks (vRNI/AON) due to duplicate DFW IPFIX profiles.
search cancel

NSX DFW Flows Are Not Reported or Visible in VMware Aria Operations for Networks (vRNI/AON) due to duplicate DFW IPFIX profiles.

book

Article ID: 443512

calendar_today

Updated On:

Products

VMware vDefend Firewall

Issue/Introduction

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.

Environment

VMware NSX: 4.2.2.1.0

VMware Aria Operations for Networks (vRNI/AON): 6.14.0

Cause

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.

  1. An external integration (vRNI) creates a global profile using a lowercase identifier:

    /infra/ipfix-dfw-profiles/global
  2. Later, an administrator or third-party tool (for example, a Cisco collector integration) creates another profile using an uppercase identifier:

    /infra/ipfix-dfw-profiles/Global
  3. The realization provider logic uses a case-insensitive comparison (equalsIgnoreCase) when validating global definitions. As a result, both distinct database entries (IpfixDfwConfig) are marked with apply_all=true ("Apply to all segments/VMs").
  4. The ESXi host datapath does not support multiple IPFIX profiles with apply_all=true simultaneously. In the observed scenario:
    • The Global profile was assigned Priority 1.
    • The vRNI global profile was assigned Priority 0.
  5. Because higher priority values take precedence, the host selected the Cisco collector profile and suppressed or redirected the DFW drop-flow records required by vRNI.
  6. Direct deletion of the conflicting Global profile fails because it contains manually created Group Profile Binding Maps that must first be unmapped or reassigned.

Resolution

To restore DFW flow visibility in vRNI, remove or deactivate the unused duplicate global IPFIX profile.

  1. Identify the duplicate DFW IPFIX profile that is not actively used by vRNI (typically the profile with an unexpected Domain ID or lower relevance to the vRNI deployment).
  2. Disable or delete the non-vRNI global profile configuration.
  3. Verify on the affected ESXi host, using NSX CLI commands, that only a single active global Firewall IPFIX profile remains.
  4. After the duplicate profile has been removed, the host will resume exporting DFW IPFIX flow records to the vRNI collector.

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.