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
AS65002
\
AS65001 \ AS65001
main \ backup
\ \ /
\ \ /
\ \ /
\ \ /
/---------\
| |
| border |
| AS65100 |
\---------/
AS65100, AS65001 and AS65002 are illustrating numbers. Actually, these are real
allocated AS numbers to Swiss providers.
AS65001 main link is on Gigabit3/0/0.911 (dot1Q 911)
AS65002 link is on Gigabit 3/0/0.921 (dot1Q 921)
AS65001 backup is on Gigabit3/1/0.912 (dot1Q 912)
*** Netflow configuration ***
ip flow-cache timeout active 5
ip flow-export source Loopback0
ip flow-export version 5 origin-as
ip flow-aggregation cache as
cache timeout active 5
export destination 10.0.0.129 9000
enabled
*** Interface and BGP configuration ***
*** (ip flow ingress configured on the proper interfaces) ***
interface GigabitEthernet3/0/0
description Physical interface to Core1 Gi0/13
no ip address
negotiation auto
!
interface GigabitEthernet3/0/0.110
description Link to Core1
encapsulation dot1Q 110
ip address 10.0.0.1 255.255.255.252
ip ospf message-digest-key 1 md5 7 ***key***
!
interface GigabitEthernet3/0/0.911
description Link to AS65001 main
encapsulation dot1Q 911
ip address 192.168.1.1 255.255.255.252
ip access-group ACL_AntiSpoof_IN in
ip access-group ACL_AntiSpoof_OUT out
ip flow ingress
no cdp enable
!
interface GigabitEthernet3/0/0.921
description Link to AS65002
encapsulation dot1Q 921
ip address 192.168.2.1 255.255.255.252
ip access-group ACL_AntiSpoof_IN in
ip access-group ACL_AntiSpoof_OUT out
ip flow ingress
no cdp enable
!
interface GigabitEthernet3/1/0
description Physical interface to Core2 Gi0/13
no ip address
negotiation auto
!
interface GigabitEthernet3/1/0.130
description Link to Core2
encapsulation dot1Q 130
ip address 10.0.0.5 255.255.255.252
ip ospf message-digest-key 1 md5 7 ***key***
!
interface GigabitEthernet3/1/0.912
description Link to AS65002 backup
encapsulation dot1Q 912
ip address 192.168.1.5 255.255.255.252
ip access-group ACL_AntiSpoof_IN in
ip access-group ACL_AntiSpoof_OUT out
ip flow ingress
no cdp enable
router bgp 65100
no synchronization
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.224.0 route-map MY-10-0-0-IN
neighbor 192.168.1.6 remote-as 65001
neighbor 192.168.1.6 description AS65001 backup
neighbor 192.168.1.6 send-community
neighbor 192.168.1.6 prefix-list rfc1918-dsua in
neighbor 192.168.1.6 route-map AS65001-BACKUP-IN in
neighbor 192.168.1.6 route-map AS65001-BACKUP-OUT out
neighbor 192.168.1.6 password 7 ***key***
neighbor 192.168.1.2 remote-as 65001
neighbor 192.168.1.2 description AS65001 main
neighbor 192.168.1.2 send-community
neighbor 192.168.1.2 prefix-list rfc1918-dsua in
neighbor 192.168.1.2 route-map AS65001-MAIN-IN in
neighbor 192.168.1.2 route-map AS65001-MAIN-OUT out
neighbor 192.168.1.2 password 7 ***key***
neighbor 192.168.2.2 remote-as 6730
neighbor 192.168.2.2 description AS65002
neighbor 192.168.2.2 send-community
neighbor 192.168.2.2 prefix-list rfc1918-dsua in
neighbor 192.168.2.2 route-map AS65002-MAIN-IN in
neighbor 192.168.2.2 route-map AS65002-MAIN-OUT out
neighbor 192.168.2.2 password 7 ***key***
no auto-summary
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
