Zenon Mousmoulas
Wed, 25 Nov 2009 15:53:19 -0800
Hi, On 25 Νοε 2009, at 5:46 ΜΜ, Paolo Lucente wrote:
On Wed, Nov 25, 2009 at 12:59:04PM +0200, Zenon Mousmoulas wrote:I am not sure if this affects nfacctd or, perhaps, if it overrides this information by looking up the next-hop (and perhaps also the dst peer AS)in the BGP RIB?If i'm not mistaken you are not using the 'nfacctd_as_new' configuration directive in your config - or it's not set to 'bgp'. If this is the case, that key causes fields that can be grasped from multiple sources, ie. BGP and NetFlow, like src_as, dst_as, bgp_nexthop to be looked up against BGP. Default value is to look them up in the export protocol (NetFlow, sFlow).Still if this holds, can you give it a try?
I was under the impression that 'nfacctd_as_new: bgp' would cause nfacctd to lookup ASNs even though the origin ASN is already exported in netflow datagrams; this is something I was trying to avoid. In any case, I enabled the directive. Comparing the results, there were a few cases where nfacctd recorded a different dst ASN than what the AS path shows, when this setting is left to the default value (false):
DST_AS AS_PATH
97 20965_3549_6789_6789_196705
6849 20965_1299_6849_{6877}
36619 20965_3549_36625
24326 20965_3549_2914_4651_45758
121 20965_3549_3257_35007_196729
32468 20965_3549_3561_6428_{32468}
532 20965_3549_7738_262676
196 20965_3549_9002_40965_196804
8865 20965_3549_3356_13293_29414
34169 20965_3549_3257_35007
Some of these are probably 4-byte ASNs obviously exported wrong in
netflow datagrams. When nfacctd_as_new is set to bgp, it doesn't get
these wrong.
So it seems that not "trusting" netflow records for these fields may be a good idea after all. Thanks!
Source peer ASN calculation does not seem to be affected by this setting, however. Nfacctd still misses it somehow.
Cheers, Z. _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists