Hi list, Is there an easy way to dump the internal RIB of nfacctd? I'm trying to understand why AS_PATH keeps being '^$' for all the entries we see.
Relevant config includes --8<---------------cut here---------------start------------->8--- nfacctd_as_new: fallback bgp_daemon: true bgp_peer_src_as_type: bgp bgp_src_as_path_type: bgp bgp_src_local_pref_type: bgp bgp_src_med_type: bgp bgp_aspath_radius: 3 aggregate: src_host,src_net,src_mask,dst_host,dst_net,dst_mask,src_as,dst_as,as_path --8<---------------cut here---------------end--------------->8--- For info, SRC_AS and DST_AS are both 0 for all entries when nfacctd_as_new is set to 'bgp', which I guess indicates that nfacctd realises that its BGP info is bad or nonexistent. (Setting nfacctd_as_new to 'fallback' gives good result, presumably based on netflow data.) We've verified that the BGP feed looks good, with an "Id" the same as what nfacctd peers with. Example log entry: Jan 17 11:58:22 <hostname> nfacctd[7435]: INFO ( default/core/BGP ): [Id: <peering-router-ip>] u Prefix: <prefix0> Path: '<asn0> <asn1> <asn2>' Comms: '<comm0> <comm1>' EComms: '' LP: '<localpref>' MED: '0' Nexthop: '' The <peering-router-ip> does match the remote address of the BGP session. BTW, we're using mongodb, which seems to work just fine. Happy to follow up with more details on how this scales once we're up and running in production. (That said, we've tested all of this with the memory plugin, to ensure that this is not a backend issue.) -- Linus _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
