Hi Federico,
This is indeed very strange since, unless your vendor is trying to
specify the IP address of the exporter (and this is somehow failing) as
part of the flows, the IP address is taken directly from the operating
system socket.
The feature of using IE #130 (exporterIPv4Address) or #131
(exporterIPv6Address), afaik, is mostly a J feature .. so, given your
mentioning of your exporting platform, we may have a match there.
Any chance you can send me a small trace (in libpcap format) so to have
a look in these IPFIX packets and their templates? In case you should
not be familiar on how to produce one, please see here:
https://github.com/pmacct/pmacct/blob/d8ea3ec9c7fd6ff679ec4be302324c563e563cd5/QUICKSTART#L3067-L3081
Paolo
On 8/11/22 12:16, Federico Urtizberea wrote:
Hello everyone. Thank you for taking a moment and reading these lines.
I am trying to differentiate the ip of the exporter of the Netflow
packets, in this case the exporter is an MX104.
From what I understand, the field used by nfacct for this is
peer_ip_src. For IPv4 Netflows, peer_ip_src is completed correctly, but
for IPv6 for a few packets (i suspect the first ones), peer_ip_src is
the IPv6 address of the exporter, and for all other packets it is
completed with 0.0.0.0.
Launching nfacctd in debug mode you can see that the Netflow packets
arriving with the IPv6 of the exporter, and sniffing the incomming
interface for the nfacctd server searching for 0.0.0.0, nothing is found.
The nfacctd version that I'm using is nfacctd 1.7.7-git.
Thanks in advance,
Federico
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
