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 [EMAIL PROTECTED] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
