Paolo Lucente
Wed, 25 Nov 2009 23:10:36 -0800
Hi Zenon, On Thu, Nov 26, 2009 at 01:51:44AM +0200, Zenon Mousmoulas wrote:
> 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. Consider the lookup must be done anyway to populate the other BGP related primitives. So grasping ASNs and next-hop from the BGP RIB is absolutely negligible operation. IHMO, it's way more savy to turn the BGP stuff off the NetFlow export at your routers. > 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! Yes, very true. I'm also curious to see if i got it correctly: your routers support 4-bytes ASNs (ie. you can set a clean peer-as 123456), supports NetFlow v9 and still can't encode the former into the latter? Btw, don't want to open a v9 vs v5 flame. But: if you consider many commercial entities are not really interested yet in accounting IPv6 (the interest come with the volumes, right?); and add that BGP can give easily the 4-bytes ASNs. Well, this makes less traction on v9 for these things expecially if some vendors let you pay extra to get it ... > Source peer ASN calculation does not seem to be affected by this > setting, however. Nfacctd still misses it somehow. Maybe more effective if i give this a brief look to see where the problem is. I'll contact you privately and we might post a summary afterwards. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists