This problem occurs due to the default behavior of both technologies. Let's begin by first analyzing the default behavior of UDP Director (UDPD).
UDPD acts as a central point of aggregation between flow exporters and flow collectors, allowing for transparent forwarding of NetFlow, SNMP and Syslog data.
The default behavior of UDPD is to maintain the original source IP address of a flow exporter device. This means that when UDPD sends traffic to a flow collector device, it sources the traffic from the IP address of the flow exporter device, not from its own IP address. Therefore, if UDPD is connected to ACI (which implies that the traffic from flow exporter to flow collector must traverse the ACI fabric), then the "spoofed" IP address will be re-learned in ACI on a different leaf switch interface (the interface that is connected to UDPD), rather than the original leaf switch interface that is connected to the flow exporter device. This means that the source IP address will now be bound to a different MAC address in ACI.
Why is this a problem?
Let's quickly analyze the default behavior of endpoint learning in ACI to understand why.
In ACI, endpoint MAC and IP addresses are learned via the data plane by default, not the control plane. This means that when a packet is received on a front-panel port of an ACI leaf switch, depending on the configuration in ACI, the leaf switch will either install the MAC address, or both the MAC and IP address, of the interface/device that sent the traffic into the local leaf endpoint table. If ACI receives traffic from two different MAC addresses that have the same IP address in the same VRF, a number of problems can occur. You might observe endpoint flapping, intermittent connectivity, or blackholing of traffic (just to name a few).
Therefore, in the case of connecting UDPD to ACI, we need to look at some workarounds to prevent potential issues from occurring.
Workarounds
The first workaround that we can implement to resolve the problem is to change the core service (flowfan) on the UDPD appliance so that it does not maintain the original source IP address of a flow collector device. You may need Cisco TAC's assistance to perform this operation. Be advised that this is not a recommended workaround, as it will cause all flow data in SNA to be displayed with the UDP Director as the original flow exporter device, and this can lead to a large loss of functionality.
A second (and better) workaround is to disable IP data-plane learning in ACI. This can be done either at the EPG (per host), BD or VRF level. The best option is to disable IP data-plane learning at the EPG (host) level for the UDPD appliance. Please note that you must be running ACI software version 5.2(1g) or higher in order to disable IP data-plane learning at the EPG (host) level. To read more about this configuration option, please refer here: ACI Fabric Endpoint Learning White Paper
There are other possible workarounds that we could use to resolve this problem, but they are complex in nature and require a substantial amount of configuration. Therefore, I have intentionally left them out of this article for the sake of brevity.
Conclusion
Problems can occur when connecting Cisco SNA (Stealthwatch) UDP Director to Cisco ACI due to the default behaviors of both technologies. However, there are workarounds that we can implement to mitigate the potential issues that we may face when connecting these two technologies together. The most simple and least impactful option is to disable IP data-plane learning in ACI at the EPG (host) level for the UDPD appliance.
