[c-nsp] Netflow collection problem with AS traffic

[Yann Gauteron]

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?

Before opening the case by Cisco, I'd like to know if some people already
noticed this particular behavior. As I did not find any related bug to my
problem, maybe some are already created but with a description that did not
match my search keys.

Thanks for this living and great list.

Have a nice week, guys.
Yann
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bgp.txt
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20081006/b69bcece/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: partial-show-run-rewritten.txt
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20081006/b69bcece/attachment-0001.txt>