Zenon Mousmoulas
Wed, 25 Nov 2009 03:00:43 -0800
Hello,I am trying to get nfacctd to calculate peer ASNs, both dst and src. According to the documentation, I have these configuration directives:
aggregate: src_as, dst_as, peer_src_as, peer_dst_as, [...] bgp_daemon: true bgp_agent_map: /srv/pmacct/test_nfacctd.bgp_agent_map bgp_peer_src_as_type: map bgp_peer_src_as_map: /srv/pmacct/test_nfacctd.bgp_peer_src_as_map bgp_src_as_path_type: bgpWe only have a peering with a route server, which acts as a route reflector for nfacctd. Therefore the contents of the agent map always point to this peering:
id=w.x.y.z ip=a.b.c.d id=w.x.y.z ip=::ffff:a.b.c.d The notation above is necessary since we have built pmacct with ipv6.The bgp_peer_src_as_map associates bgp next-hops with peer ASNs. Since netflow is currently only exported from one router to nfacctd, all the records are set to point to this source, regardless where the peering actually happens:
id=65001 bgp_nexthop=1.2.3.4 ip=a.b.c.d id=65001 bgp_nexthop=1.2.3.4 ip=::ffff:a.b.c.d id=65002 bgp_nexthop=2.3.4.5 ip=a.b.c.d id=65002 bgp_nexthop=2.3.4.5 ip=::ffff:a.b.c.dI am using this repetitive notation due to ipv6, but I am not sure if it is necessary?
Nfacctd is getting netflow v9 non-aggregated feed from a Cisco router (12K, IOS 12.0S). It is actually equivalent to netflow v5 but with the addition of BGP next-hop. The next-hop that is being exported in netflow records is actually "mangled" due to the fact that next-hop self is used by other routers in their iBGP peerings with the particular router. I have confirmed this by looking into the actual netflow datagrams. On the other hand, this next-hop information is not mangled in the BGP feed nfacctd receives through the route server. 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? The in-memory table shows that nfacctd has successfully looked up peer_dst_as even for records which contain the the "mangled" next-hop, so it does not seem to be affected by the above.
However the table shows nfacctd has trouble finding the peer_src_as. I have added src_host to the aggregates to help with debugging. Here is a sample:
SRC_AS DST_AS SRC_AS_PATH PEER_SRC_AS PEER_DST_AS SRC_IP
8253 8248 8253 0 8248 83.212.132.1
65044 1241 65044 0 1241 194.177.211.75
47616 8359 47616 0 20965 160.40.50.21
47616 1241 47616 0 1241 160.40.50.21
47616 3329 47616 0 3329 160.40.50.21
47616 6799 47616 0 6799 160.40.50.21
65042 1241 65042 0 1241 195.251.116.198
65042 6799 65042 0 6799 195.251.116.198
47616 6799 47616 0 6799 160.40.50.150
[...]
(~2600 records in total)
The route server shows:
rc# sh ip bgp 83.212.132.1
BGP routing table entry for 83.212.128.0/21
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
[...]
8253
194.177.209.182 from [...]
Origin IGP, metric 0, localpref 120, valid, internal, best
Last update: Tue Nov 24 14:06:07 2009
$ grep 194.177.209.182 test_nfacctd.bgp_peer_src_as_map
id=8253 bgp_nexthop=194.177.209.182 ip=a.b.c.d
id=8253 bgp_nexthop=194.177.209.182 ip=::ffff:a.b.c.d
The same is true for all such records. What is common in all such
cases is that the origin and peer src AS always match, i.e. we have a
direct peering with the source network. However I don't understand why
the peer AS lookup should fail. Could this be a bug?
This has been tested with 0.12.0rc3 as well as the latest CVS HEAD (checked out yesterday).
Best regards, Z. _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists