BGP convergence time

[rmv72]

I have 2 routers-R1 ( L0=172.22.23.1) and R2 connected to each other in 2 ways - PLC Link 1 and via MPLS IP VPN.

#sh ip bgp

* 172.22.23.1/32 172.30.0.54 0 3216 65334 i

*> 172.22.22.17 0 0 65334 I

#sh ip bgp 172.22.23.1

BGP routing table entry for 172.22.23.1/32, version 364

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

172.30.0.54

3216 65334

172.30.0.54 from 172.30.0.54 (195.239.255.9)

Origin IGP, localpref 100, valid, external

65334

172.22.22.17 from 172.22.22.17 (172.22.23.1)

Origin IGP, metric 0, localpref 100, valid, external, best

R2 have 2 routes to 172.22.23.1 and selected best.

#sh ip route

.....

B 172.22.23.1/32 [20/0] via 172.22.22.17, 00:00:14

.....

# traceroute 172.22.23.1

Type escape sequence to abort.

Tracing the route to 172.22.23.1

1 172.22.22.17 20 msec * 20 msec

Link 1 failured and i had lost connection to 172.22.23.1 for 1-2 min -

#ping 172.22.23.1 repeat 10000

Type escape sequence to abort.

Sending 10000, 100-byte ICMP Echos to 172.22.23.1, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......

...............................................................!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!

Success rate is 86 percent (443/512), round-trip min/avg/max = 20/22/24 ms

# traceroute 172.22.23.1

Type escape sequence to abort.

Tracing the route to 172.22.23.1

1 172.30.0.54 0 msec 4 msec 0 msec

2 172.30.0.66 [AS 3216] 20 msec 24 msec 24 msec

3 172.30.0.65 [AS 3216] 20 msec * 20 msec

Is it normal that i have such long time for convergence or how to minimize time of failure?

[thomas.anthony]

try this - neighbor ip-address fall-over

This feature improves the response time of BGP to adjacency changes by allowing BGP to detect an adjacency change and deactivate the terminated session in between standard BGP scanning intervals. Enabling this feature improves overall BGP convergence.

In an ideal case, after a failure, a BGP router never selects an

invalid path nor delays updates by MRAI. Therefore, routing

convergence time is determined solely by the physical limits of

propagation and processing delay along the best path. Under

these assumptions, we will show that extra downtime and false

uptime are given as follows.

ε(s) = tup(s) + d(s) (1)

f(s) = tdown(s) + d(s) (2)

where d(s) is the propagation delay from S to D, tdown(s)

is the convergence time of the Tdown event, and tup(s) is the

convergence time of the Tup event

[royalblues]

You can tune the BGP timer parameters

router bgp xxxx

timers bgp 5 15

This will reduce the keepalive timers from the defaults 60/180 to 5/15

HTH

Narayan

[rmv72]

Do you think reduce bgp timers is better than neighbor ip-address fall-over?

[royalblues]

It depends

On the internet or if the link flaps too many times, it may not be a feasible option

I haven't really used the neighbor ip-address fall-over feature and hence cannot comment. The above timers are used by us in our internal network and also for PE-CE BGP and it turns out to be fine for us

HTH

Narayan

[thomas.anthony]

By default, the BGP hold timer is set to run every 180 seconds in Cisco IOS software. This timer value is set as default to protect the BGP routing process from instability that can be introduced by peering sessions with other routing protocols. BGP routers typically carry large routing tables, so frequent session resets are not desirable. The timer needs to be configured on BGP process where in it will applies to other neighbor as well,

BGP fast peering session deactivation improves BGP convergence and response time to adjacency changes with BGP neighbors. This feature is event driven and configured on a per-neighbor basis. When this feature is enabled, BGP will monitor the peering session with the specified neighbor. Adjacency changes are detected and terminated peering sessions are deactivated in between the default or configured BGP scanning interval.