As it seems, there is always something that you think you know, until it's proven the other way around.
Some years ago, when i was studying for the CCIE, i knew that in order to suppress more specific routes from an aggregate advertisement in BGP, you could use the "aggregate-address .... summary-only" command. And i believed it until recently.
Let's suppose you have the following config in a ASR1k (10.1.1.1) running 15.1(2)S2:
router bgp 100 bgp router-id 10.1.1.1 neighbor 10.2.2.2 remote-as 100 neighbor 10.2.2.2 update-source Loopback0 ... address-family ipv4 aggregate-address 10.10.10.0 255.255.255.0 summary-only redistribute connected neighbor 10.2.2.2 activate ...
Then you have 2 subscribers logging in.
With "show bgp" the 2 /32 routes under 10.10.10.0/24 seem to be suppressed and the /24 is in the BGP table as it should be:
*> 10.10.10.0/24 0.0.0.0 32768 i s> 10.10.10.3/32 0.0.0.0 0 32768 ? s> 10.10.10.4/32 0.0.0.0 0 32768 ?
but doing some "debug bgp updates/events" reveals the following:
BGP(0): 10.2.2.2 send UPDATE (format) 10.10.10.3/32, next 10.1.1.1, metric 0, path Local BGP(0): 10.2.2.2 send UPDATE (format) 10.10.10.4/32, next 10.1.1.1, metric 0, path Local
...and after a while:
BGP: aggregate timer expired BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.10.3/32 BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.10.4/32
At the same time on the peer router (10.2.2.2) you can see the above 2 /32 routes being received:
RP/0/RP0/CPU0:ASR9k#sh bgp neighbor 10.1.1.1 routes | i /32 *>i10.10.10.3/32 10.1.1.1 0 100 0 ? *>i10.10.10.4/32 10.1.1.1 0 100 0 ?
and immediately afterwards you can see the 2 /32 routes being withdrawn:
RP/0/RP0/CPU0:ASR9k#sh bgp neighbor 10.1.1.1 routes | i /32
Cisco is a little bit contradicting on this behavior, as usual.
According to Cisco tac, the default aggregation logic runs every 30 seconds, but bgp update processing will be done almost every 2 seconds. That's the reason the route is being updated initially and later withdrawn (due to the aggregation processing following the initial update). They also admit that the root cause of this problem is with the BGP code. The route will be advertised as soon as the best path is completed. It may take 30 seconds or more for the aggregation logic to complete and withdraw the more specific route.
Then we also have the following:
Bug CSCsu96698
BGP: /32 route being advertised while 'summary-only' is configured
Symptoms: More specific routes are advertised and withdrawn later even if config aggregate-address net mask summary-only is configured. The BGP table shows the specific prefixes as suppressed with s>
Conditions: This occurs only with very large configurations.
Workaround: Configure a distribute-list in BGP process that denies all of the aggregation child routes.
Related Bug Information
It takes 30 seconds for BGP to form aggregate route
Symptom: for approximately 30 seconds router announces specific prefixes instead of aggregate route
Conditions: bgp session up/down
Workaround: unknown yet
Release notes of 12.2SB and 12.0S
The periodic function is by default called at 60 second intervals. The aggregate processing is normally done based on the CPU load. If there is no CPU load, then the aggregate processing function would be triggered within one second. As the CPU load increases, this function call will be triggered at higher intervals and if the CPU load is very high it could go as high as the maximum aggregate timer value configured via command. By default this maximum value is 30 seconds and is configurable with a range of 6-60 seconds and in some trains 0. So, if default values are configured, then as the CPU load increases, the chances of hitting this defect is higher.
Release notes of 12.2(33)SXH6
CLI change to bgp aggregate-timer command to suppress more specific routes.
Old Behavior: More specific routes are advertised and withdrawn later, even if aggregate-address
summary-only is configured. The BGP table shows the specific prefixes as suppressed.
New Behavior: The bgp aggregate-timer command now accepts the value of 0 (zero), which
disables the aggregate timer and suppresses the routes immediately.
Command Reference for "bgp aggregate-timer"
To set the interval at which BGP routes will be aggregated or to disable timer-based route aggregation, use the bgp aggregate-timer command in address-family or router configuration mode. To restore the default value, use the no form of this command.
bgp aggregate-timer seconds
no bgp aggregate-timer
Syntax Description
seconds
Interval (in seconds) at which the system will aggregate BGP routes.
•The range is from 6 to 60 or else 0 (zero). The default is 30.
•A value of 0 (zero) disables timer-based aggregation and starts aggregation immediately.
Command Default
30 seconds
Usage Guidelines
Use this command to change the default interval at which BGP routes are aggregated.
In very large configurations, even if the aggregate-address summary-only command is configured, more specific routes are advertised and later withdrawn. To avoid this behavior, configure the bgp aggregate-timer to 0 (zero), and the system will immediately check for aggregate routes and suppress specific routes.
The interesting part is that the command reference for "aggregate-address ... summary-only" doesn't mention anything about this behavior in order to warn you.
Using the summary-only keyword not only creates the aggregate route (for example, 192.*.*.*) but also suppresses advertisements of more-specific routes to all neighbors. If you want to suppress only advertisements to certain neighbors, you may use the neighbor distribute-list command, with caution. If a more-specific route leaks out, all BGP or mBGP routers will prefer that route over the less-specific aggregate you are generating (using longest-match routing).
The following debug logs show the default aggregate-timer which is 30 secs, vs the default BGP scan timer which is 60 secs:
Nov 12 21:45:32.468: BGP: Performing BGP general scanning Nov 12 21:45:38.906: BGP: aggregate timer expired Nov 12 21:46:09.637: BGP: aggregate timer expired Nov 12 21:46:32.487: BGP: Performing BGP general scanning Nov 12 21:46:40.379: BGP: aggregate timer expired Nov 12 21:47:11.099: BGP: aggregate timer expired Nov 12 21:47:32.506: BGP: Performing BGP general scanning Nov 12 21:47:41.828: BGP: aggregate timer expired Nov 12 21:48:12.547: BGP: aggregate timer expired Nov 12 21:48:32.525: BGP: Performing BGP general scanning Nov 12 21:48:43.268: BGP: aggregate timer expired Nov 12 21:49:13.989: BGP: aggregate timer expired Nov 12 21:49:32.544: BGP: Performing BGP general scanning Nov 12 21:49:44.765: BGP: aggregate timer expired Nov 12 21:50:15.510: BGP: aggregate timer expired
Guess what! After changing the aggregate-timer to 0, the cpu load increases by a steady +10%, due to the BGP Router process!
ASR1k#sh proc cpu s | exc 0.00 CPU utilization for five seconds: 17%/6%; one minute: 16%; five minutes: 15% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 61 329991518 1083305044 304 4.07% 4.09% 3.93% 0 IOSD ipc task 340 202049403 53391862 3784 1.35% 2.10% 2.11% 0 VTEMPLATE Backgr 404 84594181 2432529294 0 1.19% 1.18% 1.14% 0 PPP Events 229 49275197 1710570 28806 0.71% 0.33% 0.39% 0 QoS stats proces 152 39536838 801801056 49 0.63% 0.56% 0.51% 0 SSM connection m 159 51982155 383585236 135 0.47% 0.66% 0.64% 0 SSS Manager ASR1k#conf t Enter configuration commands, one per line. End with CNTL/Z. ASR1k(config)#router bgp 100 ASR1k(config-router)# address-family ipv4 ASR1k(config-router-af)# bgp aggregate-timer 0 ASR1k(config-router-af)#^Z
...and after a while:
ASR1k#sh proc cpu s | exc 0.00 CPU utilization for five seconds: 29%/6%; one minute: 26%; five minutes: 25% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 394 143774989 19776654 7269 9.91% 7.93% 7.32% 0 BGP Router 61 329983414 1083280872 304 4.79% 3.97% 3.90% 0 IOSD ipc task 340 202044852 53390504 3784 2.71% 2.22% 2.04% 0 VTEMPLATE Backgr 404 84591714 2432460324 0 1.03% 1.16% 1.09% 0 PPP Events 159 51980758 383575060 135 0.79% 0.66% 0.62% 0 SSS Manager 152 39535734 801779715 49 0.63% 0.54% 0.50% 0 SSM connection m
Conclusions
1) By default, the "aggregate-address ... summary-only" command doesn't immediately stop the announcement of more specific routes, as it's supposed to. You need to also change the BGP aggregate-timer to 0.
2) After changing the BGP aggregate-timer to 0, the announcement of more specific routes stops, but the cpu load increases by 10%.
C'mon Cisco! You gave us NH Address Tracking and PIC, and you can't fix the aggregation process?
Posts
