On 18 Jul 2017, at 2:28, Paolo Lucente wrote:
The version the post refers to is very old and, yes, the issue was
resolved back then. I would start from scratch investigating what your
issue may be. What version are you using (sfacctd -V output)? What is
your current setup and config?
Reproduced on sfacctd 1.7.0-git (20170717-00) at commit
'--enable-sqlite3' '--enable-ipv6' '--enable-v4-mapped' '--enable-64bit'
'--enable-threads' '--enable-jansson' '--enable-geoip' '--enable-rabbitmq'
'--enable-l2' '--enable-traffic-bins' '--enable-bgp-bins' '--enable-bmp-bins'
Setup is Juniper EX switches exporting sFlow data to sfacctd. The EXs do not
include AS data in the sFlow records, so iBGP is set up between each EX and
sfacctd. sfacctd is configured as an RR client on each EX.
As per Rob's email, prefixes originated internally have an empty AS_PATH, and
so end up with src_as or dst_as set to 0. I'm trying to replace this with our
ASN, using networks_file. This mostly works, but in some cases, records with
our source/destination IP address still have their src_as/dst_as respectively
set to 0.
Digging into the affected IP addresses, it seems like maybe
networks_file_no_lpm is not working. If I take a fictitious example of a source
IP address in our network of 126.96.36.199, then there is:
* BGP: 188.8.131.52/20 (with empty AS_PATH)
* BGP: 184.108.40.206/24 (with empty AS_PATH)
* networks_file: <myasn>,220.127.116.11/20
In this scenario (with the below configuration file), sFlow records with
src_host 18.104.22.168 have src_as set to 0, rather than <myasn>. If I add
<myasn>,22.214.171.124/24 to the networks_file, then sFlow records with src_host
126.96.36.199 have src_as correctly set to <myasn>. I thought this was exactly the
scenario that networks_file_no_lpm existed for - am I mistaken?
Config is fairly straight-forward:
Hope that's enough information!
pmacct-discussion mailing list