Need advise with BGP soft reset

[ck.chaminda]

Hello all,

I am redistributing static routes to BGP by using "redistribute static route-map". Recently I added a new static route to the access-list used in the route-map. I had to do "clear ip bgp * " to load the new static route into the BGP topology table.

Is there anyway to redistribute a static route into BGP without a hard reset?

Many thanks,

Chaminda

[John Blakley]

You can reset like:

clear ip bgp soft

[ck.chaminda]

hmm but I was under the impression using "clear ip bgp soft" is targeting sending/receiving routes to the neighbor.

But in this case I want the new static route to show on the originating router's BGP table. So is there a way to do a "soft in" for the originating router itself?

[John Blakley]

I've never had to reset a neighborship to get a route to take effect. I'm redistributing all statics though. The soft reconfiguration is for updating policy between the neighborships without downing the peering. If you're redistributing your statics via route-map on the neighbor line, you'll need to do a soft reset in order for the change to take effect immediately. If it doesn't work, let me know and I can lab it up...

Please rate all helpful posts...

[ck.chaminda]

Thanks for your advise. I will actually lab it myself and will post the results tomorrow.

[milan.kulik · Accepted solution]

Hi,

I'm afraid this might be a little tricky if you are using  "redistribute static route-map" under you router bgp ... process.

You might need some trigger to make the BGP process to reimport the static routes.

So when adding a new static route, it's easier.

You just modify the route-map first and then add the new static route.

And it gets redistribited to BGP without any need to "clear ip bgp".

The challenge is to make an existing static route to get redistributed to BGP while it is not permitted by the current route-map.

So again, you modify the route-map first.

Then you remove the static route and add it again.

But removing the static route might not be allowed in a productive environment, as you would lose the routing to the subnet temporarily :-(

So you might try following trick:

Before removing the static route, add more specific static routes covering the same IP range with the same next-hop.

I.e., if the current static is 10.1.1.0/24, add 10.1.1.0/25 plus 10.1.1.128/25 with the same next-hop.

Then remove the original static route, wait a while and add it again.

It should be redistributed to BGP now.

And finally you can remove those more specific static routes.

Hopefully everything is working without any pain.

HTH,

Milan

[ck.chaminda]

Thanks Milan, you are indeed correct. As I found out from my lab just biw trick is to change the route-map prior to adding the static route.

I've just simulated the same situation on my lab. So the 2 scenarios:

1) Adjust route-map prior to adding the static routing table =

Route immediatly appears on the BGP topology table as soon as the static route appears on the vrf routing table.

2) Add the static route first, then adjust the route-map =

Static appeared on the vrf routing table but not on the BGP toplogy table. However after about 3 minutes the new static route showed up on the topology table.

Does anyone know why there is a delay for the static route to find it self into the topology table in scenario 2?

Many thanks,

Chaminda

[milan.kulik · Accepted solution]

Hi,

I believe it might be 3x BGP Scanner process interval (60 seconds by default).

If you configure

bgp scan-time 5

it will decrease to 15 seconds.

But be careful when playing with BGP timers in a productive enviroment :-(

HTH,

Miloan

[ck.chaminda]

Thanks Milan, you've been most helpful. That does explain it.

Chamidna