BGP general scanning vs BGP Nexthop scanning

[kfarrington]

All,

I have an interesting question (i think). Diagram attached! and debugs in text file.

We are using conditional advertsiements in BGP, so we have two sites (one AS, AS66666), site1 and site2, advertising via eBGP only their site specific prefixes, and should site1 lose its eBGP peer to carrier1, site2 will start advertising site1s prefixes via carrier2, and should site2s eBGP peer go down on carrier2, site1 will start to advertise site2s prefixes via carrier1. This is done via a routemap matching on a prefix and as-path.

Also, the standard iBGP peering between the two sites

Criteria for conditional advertisments are (full config config below)

While there is a default route with as AS-PATH of 11111, DO NOT ADVERTISE THESE PREFIXES OUT OF site1

While there is a default route with as AS-PATH of 22222, DO NOT ADVERTISE THESE PREFIXES OUT OF site2

Now the question is as follows:-

When the eBGP peer goes down on site1, you have to wait for the BGP general scanning to happen on site2 before the routes will start to get advertised out of site2s eBGP interface. So we looked at change the bgp scan-time down to 5 (for example) but this only changes the BGP Nexthop scanning to 5 and not the BGP General scanning.

Is there a way of changing the BGP General scanning to below 60? (debugs below) and is the a definitive text showing what the two different scanning processes do.

Kind regards,

Ken

SITE1

router bgp 66666

addr ipv4

neighbor carrier1 advertise-map LOCALSUBNETS non-exist-map DEFAULTEXISTS

!

ip as-path access-list 40 permit ^22222......$

!

route-map DEFAULTEXISTS permit 10

match ip address prefix-list DEFAULTEXISTS

match as-path 40

!

no route-map LOCALSUBNETS permit 10

route-map LOCALSUBNETS permit 10

match ip address prefix-list LOCALSUBNETS

!

no ip prefix-list LOCALSUBNETS

ip prefix-list LOCALSUBNETS permit 3.3.3.0/24 le 32

ip prefix-list LOCALSUBNETS permit 10.189.32.0/19

ip prefix-list LOCALSUBNETS permit 155.195.117.0/24

ip prefix-list LOCALSUBNETS permit 155.195.58.35/32

!

ip prefix-list DEFAULTEXISTS seq 5 permit 0.0.0.0/0

router bgp 66666

addr ipv4

neighbor carrier2 advertise-map LOCALSUBNETS non-exist-map DEFAULTEXISTS

!

ip as-path access-list 40 permit ^11111......$

!

route-map DEFAULTEXISTS permit 10

match ip address prefix-list DEFAULTEXISTS

match as-path 40

!

no route-map LOCALSUBNETS permit 10

route-map LOCALSUBNETS permit 10

match ip address prefix-list LOCALSUBNETS

!

no ip prefix-list LOCALSUBNETS

ip prefix-list LOCALSUBNETS permit 2.2.2.0/24 le 32

ip prefix-list LOCALSUBNETS permit 155.195.105.0/24

ip prefix-list LOCALSUBNETS permit 155.195.125.56/30

ip prefix-list LOCALSUBNETS permit 155.195.120.0/24

ip prefix-list LOCALSUBNETS permit 155.195.103.0/24

ip prefix-list LOCALSUBNETS permit 155.195.121.0/24

ip prefix-list LOCALSUBNETS permit 155.195.122.0/26

ip prefix-list LOCALSUBNETS permit 155.195.124.0/25

ip prefix-list LOCALSUBNETS permit 10.189.0.0/19

ip prefix-list LOCALSUBNETS permit 155.195.58.19/32

ip prefix-list LOCALSUBNETS permit 155.195.123.128/25

ip prefix-list LOCALSUBNETS permit 155.195.58.20/32

!

ip prefix-list DEFAULTEXISTS seq 5 permit 0.0.0.0/0

Kindest regards, and Thx,

Ken

[ruwhite]

There is only one BGP scanner, but there are two types of BGP scan runs, one for just importing routes into and out of VRFs (called an import/export scan), and one for checking next hops, conditional advertisement, and other things (called a general scan). The import scan is normally performed every 15 seconds, and the general scan every 60 seconds (inlcuding the conditional advertisement stuff).

Setting bgp scan-time should set the general scan rate. If you set the general scan rate under 15 seconds, then the import scanner will run at the same time and frequency as the general scanner. There's also another command, bgp scan-time import, that will set the import scan runs independant of the general scans.

So, in your case, you should see the time it takes to conditionall advertise a route based on the timer set with bgp scan time, which defaults to 60 seconds. I looked at your debugs, but couldn't figure out if this was with the scan time changed or not--could you test this with bgp scan-time set to, say, 5 seconds?

:-)

Russ.W

[kfarrington]

Russ,

Hey mate, how you doin fella :)

So Here is the BGP config and debug ip bgp events to show that the general scanning is not happening every 5 seconds as set, but just the next hop scanning is being performed every 5 secs. I will test on other platforms and IOS to see if I can get a general scan down to 5 seconds as you suggest it should.

In the attached file. Please let me know at ken.farrington@barcap.com if you do not get the file.

PS. if you look at the 1st debug i sent on the other post, you can see that I am doing a debug ip bgp events, and while the dual1 router has been downed, i do a show ip bgp nei advert on dual 3 and the conditional routes are not being sent, and you can see that the next hop scan has run, every 5 seconds, but it is not until you get the BGP general scanning being performed that the dual3 peer start to advertise the conditional routes.

Its a bit hard to see in that file.

Thx Russ,

Ken

[ruwhite]

Have you tried setting the scan-time under the bgp process, rather than the AF? I'm fairly certain (though I can double check a bit later) that the general scanner isn't per AF, so setting it under the AF won't cause the general run timer to change (?).

:-)

Russ.W

[kfarrington]

did this

Dual1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Dual1(config)#router bgp 66666

Dual1(config-router)#address-family ipv4

Dual1(config-router-af)#no bgp scan-time 5

Dual1(config-router-af)#exit

Dual1(config-router)#bgp scan-time 5

Dual1(config-router)#^Z

Dual1#

but it puts the scan time back under the ipv4 AF

:(

[ruwhite]

Can you open a case on this through TAC? What I need to have done is a recreate internally, and make certain we have all the debugs we need to look at it more closely, in case there's a bug in here someplace.

We'd also need to check the behaviour in code after the next hop checking was pulled out of the scanner, to see what happens there.

:-)

Russ.W

[kfarrington]

Hi Russ,

I will raise a TAC case for this, and I will alert our Cisco AS team so that they can track this via the TAC case.

Kind regards,

Ken

[kfarrington]

TAC Case ID 601754423.

As I say, we can use local-pref, but conditional advertisments is a very valid tool for us should we be able to get convergents under 15 seconds end-to-end, with the BGP withdrawals and then the start of the new updating process.

Kindest regards,

Ken

[kfarrington]

Russ,

Just an update, we have decided just to set a community value with the prefixes, advertise all prefixes out into both carrier cloulds and use local-pref at the remote sites to either use carrier1 or carrier2, ie both 155.195.120.0/24 (is at site1) and and 155.195.117.0 (is at site2), we advertise both prefixes out of both sites.

On the site1 router we say that 155.195.120.0 has its stanard community, and 155.195.117.0 has its standard community and another community value.

On the site2 router we say that 155.195.117.0 has its stanard community, and 155.195.120.0 has its standard community and another community value.

At the remote sites, if they receive 155.195.120.0 or 155.195.117.0 and it has its standard community PLUS this new community, demote LP to 50, and this way, the remote sites will route the most optimum way for that prefix.

We were just a little disappinted with the convergence times of conditional adverting, as this would have been a good tool for the BGP toolbox!!

Diag and results plus configs for the new solution.

Also, the fact that all prefixes are in the MPLS clouds at the same time and we make the right decision with local-pref, is always going to be faster, than conditionally advertising a route as it has to meet the condition, and then start the process of advertising it into BGP. I WOULD ASSUME?????

If you still know why cond adverts are not going on the scan time, please let us know.

The very best of regards,

Ken

[ruwhite]

Okay--the TAC Engineer emailed me... I'll take a poke around the attachments tomorrow morning (I hope), and probably tell them to file a bug, then work with one of the DE's on how to fix it.

:-)

Russ.W