Turns out this was something stupid... the process I have that creates
networks_file was OOMing and exiting... this meant that traffic wasn't
getting aggregated by ASN properly, and wasn't showing up when I was
looking at data.
On 4/25/2018 11:38 AM, Brian Rak wrote:
I seemingly keep running into issues where my pre_tag_map values
aren't actually getting applied. I haven't really been able to figure
out what's happening, and my debugging thus far has involved making
changes to the map and seeing if they fix the issue.
Is there a reliable way of debugging these that I'm not seeing?
I have a pretty simple file:
set_tag=20 ip=43.224.32.252 in=581
set_tag=20 ip=43.224.32.252 out=581
set_tag=20 ip=43.224.32.252 vlan=30
If I decode one of the packets with sflowtool, it seems like it should
be matching on 'out_vlan 30':
https://gist.githubusercontent.com/devicenull/67f2f82d97263ba406baa8256d8b053b/raw/8621e684f67fd19514f35c2c889d816ed60852de/gistfile1.txt
(ignore incorrect datagramSourceIP, that's related to how I captured
the traffic).
If I trigger a reload, I don't get any entries indicating I have an
invalid config:
sfacctd[28498]: INFO ( default/core ): [/etc/pre_tag_map] (re)loading
map.
sfacctd[28498]: INFO ( default/core ): [/etc/pre_tag_map] map
successfully (re)loaded.
sfacctd *does* record traffic, it's just not applying the set_tag=20
to it. The same sfacctd config (with different pre_tag_map values)
works on other routers.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
