Update to suppress-map used for BGP aggregate-address not taking

[Mark Williams]

Hi all.

I'm stumped with this one.

If I update a suppress route-map used to unsuppress some of the more specifics under a aggregate, I have to do a hard reset to get the more specific advertised.   I need to do a soft reset so I don't cause a BGP flap.

Config;

Router A;

router bgp 2000

  aggregate-address 10.30.0.0 255.255.0.0 suppress-map BGP_SUPPRESS

!

route-map BGP_SUPPRESS deny 40

match ip address prefix-list TEST1_DONT_SUPPRESS

!

route-map BGP_SUPPRESS deny 50

match ip address prefix-list TEST2_DONT_SUPPRESS

!

route-map BGP_SUPPRESS permit 100

!

ip prefix-list TEST1_DONT_SUPPRESS seq 100 permit 10.30.131.0/24

ip prefix-list TEST2_DONT_SUPPRESS seq 100 permit 10.30.132.0/24

On the neighbor router

;

routerB#show ip bgp neighbors 10.7.64.7 received-routes  | in 10.30

*>i10.30.0.0/16     10.7.64.7                0    100      0 i

*>i10.30.131.0/24   10.7.64.7                0    100      0 40000 i

*>i10.30.132.0/24   10.7.64.7                0    100      0 40000 i

Add new subnet to router A to not be suppressed

router A

route-map BGP_SUPPRESS deny 60

match ip address prefix-list TEST3_DONT_SUPPRESS

!

ip prefix-list TEST3_DONT_SUPPRESS seq 100 permit 10.30.133.0/24

The only way to make this route appear on the neighbors is to do a

clear ip bgp *

But I want to do a soft clear.

[John Blakley]

Mark,

I can lab this up if needed, but I'm curious as to the last part of your post with sequence 60 in your policy map. You reference TEST3_DONT_SUPPRESS, but your prefix list with the different subnet (10.30.133.0/24) is named TEST2_DONT_SUPPRESS. Was that a mistake?

HTH,
John

*** Please rate all useful posts ***

[Mark Williams]

Ooops.. it was a mistake.  I have corrected it.

[John Blakley]

Mark,

I'm not seeing the same thing that you are. My peer's table updates immediately without needing to clear. What platform and IOS are you on? I'd possibly suggest looking to update, but first we can look for any known bugs.

HTH,
John

*** Please rate all useful posts ***

[Mark Williams]

thanks John,

In the production environment where we first saw this; two ASR1002, running;

asr1000rp1-advipservicesk9.03.07.02.S.152-4.S2.bin

In the test lab where we can replicated it, both routers are ASR1002 running;

asr1000rp1-advipservicesk9.03.10.00.S.153-3.S-ext

[John Blakley]

I can't find a bug referring to this. There are some others on the forum that may be able to help out with that platform. I don't see a problem in 12.4T IOS as it automatically updates the neighbor. You may put a TAC case in to see if they can help.

HTH,
John

*** Please rate all useful posts ***

[Dave Bregman]

Hi Mark,

I'm a Cisco Advanced Services NCE and we saw the same thing at a customer site.  It was on a 6500 running 12.2(33)SXI9.  Once we modified the aggregate's suppress map to "unsuppress" a more specific route, we didn't see it advertised to the peers until we removed the aggrgate and reapplied it.

We did it on a Nexus 7K running 5.2(3a) and it worked without having to remove the aggregate.  It appears to be platform/code dependant.

Dave