Hi Zenon, On Tue, Oct 27, 2009 at 09:44:52PM +0200, Zenon Mousmoulas wrote:
> 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? Correct. RPF checks the input interface. Which is a check supported by the bgp_peer_src_as_map. Additionally, you can check the next-hop (or alternatively as you said the first AS in the AS-PATH - although this is not currently supported) in scenarios where you have multiple peers off a single interface (which is the typical Internet Exchange scenario). > 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? The BGP next-hop check on the source IP prefix helps by limiting false positives in case of asymmetric routing - compared to getting peer-AS information via NetFlow from the router (as the router only does a FIB lookup). The ideal solution would be having MAC addresses exported via NetFlow; NetFlow v9 is up to that; does your C12k allow to get such L2 info via NetFlow? > What about peer_dst_as? Not as complicated as peer_src_as, but is a > RIB lookup used to calculate it? Correct. > >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. That's what i was meaning. Prefix-based aggregation would work fine in correlating NetFlow flows and BGP RIB data. > OK I see. So AS-aggregated netflow is practically useless (for now) > if you are going to use the BGP features. Correct. > >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. If an AS spreads its IP address space across multiple AS-PATHs for whatever purpose (load-balancing mainly) and NetFlow is AS-aggregating at the router (so you don't have IP prefix visibility anymore), what is the correct AS-PATH for a given aggregate? You can't say for sure as there are multiple choices. Effectiveness (or precision) of AS-aggregated NetFlow depends on how diffuse are practices like this (spreading or de-aggregating the own IP address space) by service providers on the internet. > 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. Fully see the point. > 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). Setting the next-hop-self in case of eBGP peerings is diffuse practice, expecially in MPLS networks, and it's OK (all next-hops are from your own infrastructure; well, let me add a disclaimer: this is in theory). Setting the next-hop-self to iBGP peers, yes, has a blinding effect and hence its use should (must?) be avoided to the collector. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
