Hi,
On 27 Οκτ 2009, at 11:24 ΜΜ, Paolo Lucente wrote:
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).
OK fine, it's just extra work then. The only argument for using the
"first AS" instead of BGP next-hop is that some times (e.g. with next-
hop self) not even that is available, so in an IXP scenario and if you
don't have MAC address info, this option would be useful.
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).
Alright, I get the point.
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?
Unfortunately not. Netflow v9 implementation on the C12k platform with
classic IOS (i.e. not IOS XR) is effectively limited to an ipv4-only
template and practically does not convey/export any more information
than netflow v5.
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. Prefix aggregation seemed messy and complicated, but I will look
into it.
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.
I get your point. This is indeed very common practice. Traditionally
our clients have been able to signal via ebgp communities how they
want traffic to their subnets spread across multiple sites and access
links.
Are there any other options? I think it's clear now that AS-aggregated
netflow is no good for such use.
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.
Agreed & understood.
Thanks,
Z.
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
