[c-nsp] Netflow collection problem with AS traffic

[Kristian Larsson]

On Mon, Oct 06, 2008 at 12:44:26PM +0200, Yann Gauteron wrote:
> Hello the list,
> 
> I am a new talker here, but an attentive reader and I appreciate the level
> of your discussions, guys.
> 
> As I am having some suspect behaviour with one of my (in fact one of my
> customer's) border router, I'd like to read about your experience and maybe
> you already have had such a misbehavior.
> 
> I use as a BGP border router a Cisco uBR10012 CMTS (Cable Modem Termination
> System). This device is close to Cisco 10000 Series routers, but with
> dedicated interfaces for CATV operators offering Internet services.
> 
> Initially, this BGP border (AS65100) had 2 BGP peerings with AS65001 (these
> are not the actual ASN) : - one peering is the main and active peering; -
> the second one is the backup with no traffic exchanged.
> 
> I installed by this customer a nice free software, called AS-stats (
> https://neon1.net/as-stats/, a presentation of this tool is here
> https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf) permitting to
> visualize the traffic received from / sent to an AS on a given peering. This
> tool works based on the Netflow data. We succesfully used this tool for
> weeks without noticing reporting problems.
> 
> Last week, an additional peering was established with AS65002. No special
> policy were defined in the route-map for the routes learned from this new
> AS. So BGP should have been able to route traffic according to the AS-Path
> length.
> 
> Since that time, we noticed that the reporting on the AS-stats were not
> updated for the AS which were routed to that new AS65002 peer! We rerouted
> (filtered in the route-maps) most of the AS back to the older BGP peer, but
> 2 (the ASN for the provider we already peered and the ASN for a network
> where we have a lot of traffic). We expected to have back the reporting for
> all AS that were rerouted back. We were wrong... Reporting is not present
> for these AS, only for the ASs that always remained on the initial peering.
> 
> The problem is not located on the AS-stats tool, as I did some trace points
> in the code and noticed that it receives Netflow data, but not for the AS
> that lacks reporting.
> 
> For your information, you have attached a diagram of the simple BGP
> topology, and a partial show running (anonymized and focusing on Netflow
> configuration + BGP).
> 
> So come my question: Does some of you already encountered some bad
> experience with Netflow on Cisco routers (especially 10000 Series or
> uBR10012) when dealing with BGP AS information? Have you already such a
> Netflow blocking of information? Is there any suggested workaround according
> to your experience?

Perhaps not what you want to hear.. but when I've
hacked together tools to parse NetFlow data I've
tended to use a separate BGP table on the
collector to lookup information. That way you can
get more than just the src/dst as which you
usually get with via NetFlow.

I could probably provide you with some sample code
if you're interested.

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
Network Engineer / Internet Core        Tele2 / SWIPnet [AS1257]
+46 704 910401			              kll at spritelink.net