Hi Paolo,
On 27 Οκτ 2009, at 2:04 ΜΜ, Paolo Lucente wrote:
1. Does bgp_peer_src_as_map apply both to src and dst AS or only the
first? In any case, I don't understand how bgp_nexthop can be used
for calculating the peer src AS, since that field applies to the
destination recorded in the flow record?
As the name says, bgp_peer_src_as_map applies to the src peer AS
only. bgp_nexthop check in the context of bgp_peer_src_as_map is
employed to do a reverse lookup on the source IP prefix and check
the bgp_nexthop (ie. where the ingress router would route to the
source IP prefix) is what you expect (ie. traffic is symmetric).
Makes sense?
I think so, yes. It reminds me somewhat of RPF for IP multicast.
Just so I'm sure I understand it right: You lookup the source IP
address or network (for prefix-aggregated flow records) in the BGP RIB
and you then match the next-hop (among other options) against this
map. Correct?
Shouldn't the RIB lookup also reveal (via the AS-path) the next AS in
the path to this address or network? Would this be the peer AS in most
cases, or am I missing something?
I can't figure out how the lookup helps when there is asymmetric
routing. It runs at our end and not the far end, so it can't reveal
the actual entry point of the traffic. Right?
What about peer_dst_as? Not as complicated as peer_src_as, but is a
RIB lookup used to calculate it?
2. Does bgp_peer_src_as_map work with as-aggregated netflow?
Actually a broader question is if any of BGP lookup features work
when using any form of aggregated flow records where src/dst IP
address is not available.
Broader question is good: correlation of NetFlow and BGP is done
by looking up source and destination IP prefixes in NetFlow into
the BGP RIB. If you aggregate IP addresses logically to the network
boundaries - then it's still OK.
What do you mean by the last sentence? For router-based aggregation
the only scheme I can think of which still shows (summarized) IP
address space is prefix-based aggregation.
If you aggregate by removing the
IP layer at all and export only AS numbers, well, it will not work
anymore ... but you are raising a very valid point.
OK I see. So AS-aggregated netflow is practically useless (for now) if
you are going to use the BGP features.
IHMO, it would be good to put some efforts in this direction -
specifically, before even developing something general-purpose, it
should be seen how much accuracy is affected by rather common
de-aggregation or prefix load-balancing practices on the internet:
ie. i have one AS, two /18 allocations, two upstream provider: i'll
advertise a /18 here and one there.
I'm not sure I understand this, perhaps you'd like to further elaborate.
In any case, the motivation for router-based aggregation is that
nfacctd will have to process less flow records, thereby increasing the
scalability of the whole setup, compared to unaggregated netflow.
Of course it is irrelevant if you don't have to worry about this, e.g.
if you don't have that many flows or if nfacctd can be tuned to
process all of them anyway.
3. In BGP peerings it is quite common practice to advertise
"next-hop self" for a number of different, valid reasons. I am right
to assume such a practice effectively renders useless any next-hop
based lookups?
iBGP or eBGP? Can you bring an example?
Both. The router advertises itself as the next hop for any particular
prefix it has not originated, instead of the original next hop. It is
used to 'blind' your peer so that it doesn't need to also have a route
installed for the actual next hop (which could be anywhere).
On an different topic: I have seen that nfacctd detects and supports
netflow v5 sampling, but I am not sure if this is also true for v9.
It may have been mentioned somewhere/discussed previously, but I
have been unable to dig it up. I am fully aware however that
detecting sampling in netflow v9 PDUs does require a lot more
work...
NetFlow v9 sampling is supported as of 0.12.0rc3 (which is currently
in the CVS and due to be released ... soonish).
Great!
Many thanks,
Z.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
