How to configure BGP timers
BGP timers are used in peering procedure with iBGP and eBGP speaking routers. In this blog I will try to explain where to use and how to tune and benefit for BGP timers. First let us see the basic timers:
- KEEPALIVE and HOLD-DOWN
- ADVERTISEMENT INVERVAL
- SCAN-TIMER
Keepalive and hold-down timers are the most common in BGP peerings. Using the default settings, the keepalive timer is 60 seconds and hold-down timer is 3 x keepalive or 180 seconds.When we have a successfull peering, router counts from 0 to every second up. Every keepalive packet a router receives from the neighbor resets the BGP timer and the count procedure starts again. If a router does not send keep alives packets three in a row the default BGP hold-down timer expires. This will reproduce a hold down period expired and the peering will go down. Thus the routes from the iBGP speaking router will not be advertised from the neighbor router. We do not want that to happen often in the production enviroment.
Let us see a small lab diagram and test the timer tuning configs.
We can use the show command to see the output of the default BGP timer values on one of the eBGP peers. We can look at the customer router.
CUSTOMER#sh ip bgp neighbors 192.168.1.1
BGP neighbor is 192.168.1.1, remote AS 500, external link
BGP version 4, remote router ID 1.1.1.1
BGP state = Established, up for 01:35:20
Last read 00:00:20, last write 00:00:20, hold time is 180, keepalive interval is 60 seconds
Default minimum time between advertisement runs is 30 seconds
In order to keep the BGP table stable BGP speaking router maintains a period of advertising the routes to the neighboring router. This period is called advertisiment timer. The default timer for the iBGP router is 0 seconds and for the eBGP routes is 30 seconds.
Service providers often agree on what should be the BGP timers set on their sides, depending on what services is the router carrying. In our situation we will change to smaller values to improve convergence in case of failures.
We will set the the keepalive to 20 seconds and the hold down timer to 60 seconds. To send this settings to eBGP peers, we should reset the BGP peering with the clear ip bgp * (note the the soft reconfiguration will not work under these cases).
CUSTOMER(config-router)#neighbor 192.168.1.1 timers 20 60
CUSTOMER#sh running-config | section bgp
router bgp 1
no synchronization
bgp router-id 10.10.10.10
bgp log-neighbor-changes
network 50.50.50.0 mask 255.255.255.0
network 100.100.100.0 mask 255.255.255.0
neighbor 192.168.1.1 remote-as 500
neighbor 192.168.1.1 timers 20 60
no auto-summary
CUSTOMER#clear ip bgp *
*Mar 1 02:08:14.423: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up
We can verify now that the settings took place and we have a smaller time frame set on the current BGP peering with the eBGP router.
CUSTOMER#sh ip bgp neighbors 192.168.1.1
BGP neighbor is 192.168.1.1, remote AS 500, external link
BGP version 4, remote router ID 1.1.1.1
BGP state = Established, up for 00:00:33
Last read 00:00:13, last write 00:00:01, hold time is 60, keepalive interval is 20 seconds
Now we should tweak the advertisiment timer under the BGP proccess. We will set the routes refresh for 10 seconds. This is more than enough for this type of connection.
CUSTOMER(config-router)#neighbor 192.168.1.1 advertisement-interval 15
We can se from the output of the BGP neighbor on the Customer router we have some advertisement activity. And the default timer is now configured to 15 seconds as we told the router to do.
For address family: IPv4 Unicast
BGP table version 5, neighbor version 5/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 2 2 (Consumes 104 bytes)
Prefixes Total: 2 2
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 2
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Bestpath from this peer: 2 n/a
Total: 2 0
Number of NLRIs in the update sent: max 2, min 2
Minimum time between advertisement runs is 15 seconds
One more last timer we should include in this blog is the BGP-SCANNER. BGP scan time defines the period that the router will retry to scan the complete routing table. As the table grow larger, a complete Internet routing table could get up to 200 MB, default time is 60 seconds. The Scan process of BGP protocol looks inside the routing table and finds the missing or wrong IGP route for the next-hop , or a better alternative to a prefix using the BGP attributes. We can lower this time if we have enough resources on the router to do this job for us.
CUSTOMER(config-router)#bgp scan-time 20
To verify the actual scanning time we can see it in the summary output.
CUSTOMER#sh ip bgp summary
BGP router identifier 10.10.10.10, local AS number 1
BGP table version is 5, main routing table version 5
4 network entries using 468 bytes of memory
4 path entries using 208 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1196 total bytes of memory
BGP activity 16/12 prefixes, 16/12 paths, scan interval 20 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.1 4 500 178 165 5 0 0 00:11:07 2
So the final configs on our freshly tuned eBGP peer should look like this:
CUSTOMER#show running-config | section bgp
router bgp 1
no synchronization
bgp router-id 10.10.10.10
bgp log-neighbor-changes
bgp scan-time 20
network 50.50.50.0 mask 255.255.255.0
network 100.100.100.0 mask 255.255.255.0
neighbor 192.168.1.1 remote-as 500
neighbor 192.168.1.1 timers 20 60
neighbor 192.168.1.1 advertisement-interval 15
no auto-summary
Thanks for reading. Feel free to comment.
No comments:
Post a Comment