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
684920965_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
886520965_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
