BGP Keepalives
Last updated
Last updated
Load base.ipv4.and.ipv6.cfg
Configure eBGP between R5-R6-XR1 as follows:
R5 is in AS 5, R6 is in AS 6, and XR1 is in AS 19
The eBGP session between R5 and R6 must use the following parameters:
R5 allows R6 to use a holdtime no lower than 60 seconds
R6 allows R5 to use a holdtime no lower than 30 seconds
R5 configures the keepalive as 15 seconds and holdtime as 60
R6 uses the default keepalive/holdtime
The eBGP session between R6 and XR1 must use the following parameters:
XR1 allows R6 to use any holdtime
R6 configures the keepalive as 15 seconds and holdtime as 60 seconds
R6 allows any holdtime from XR1
XR1 configures the keepalive as 10 seconds and holdtime as 40 seconds
The eBGP session between R5 and XR1 must use the following parameters:
XR1 allows R5 to use a holdtime no lower than 60 seconds
R5 configures the keepalive as 10 seconds and holdtime as 30 seconds
R5 allows any holdtime from XR1
XR1 uses the default keepalive/holdtime
The BGP holdtime is a negotiated value. The lowest value bewteen the two peers is used for the session. However, each router has the ability to define a minimum acceptable hold time, so that the router is not forced into using a very low keepalive value if it is not able to handle that (from a CPU standpoint). You could consider this a security feature.
The command to set the BGP timers is neighbor timers <keepalive> <holdtime> <min acceptable holdtime> or timers can be globally set using timers bgp <keepalive> <holdtime> <min acceptable holdtime>. If no min acceptable value is configured, the default is 0 seconds on IOS-XE and 3 seconds on IOS-XR. A hold time of 0 seconds has a special meaning, which is that keepalives aren’t used at all.
The holdtime is the only value that is negotiated between peers in the OPEN message. The keepalive will always be one third of the hold time, except when the router’s timers are used for the session and the keepalive is manually configured to not be 1/3 of the hold time. (This is better explained via demonstration which we will see next).
Let’s first examine the R5-R6 peering session.
Based on the above configuration, R5’s holdtime should win (because it is lowest). R6 will set the keepalive/holdtime as 20/60 for the session. R5, as the “winner” will use its manually configured value of 15/60, even though 60 divided by 3 is 20. (Since R5 is the winner, it uses its manually configured keepalive timer, instead of using a keepalive based on 1/3 of the holdtime.)
We can confirm this in the show bgp neighbor output.
Notice above that the keepalive interval is asymmetric. But it will work fine as long as R5 configures a keepalive interval lower than the hold time. (In fact, it is not even possible to configure a keepalive higher than the hold time).
Next let’s examine the R6-XR1 session:
The lowest hold time is XR1’s holdtime of 40 seconds. This wins, and R6 will set its keepalive to 1/3 of this value. Since XR1 is the “winner” it uses its locally configured keepalive value. In previous versions of IOS-XR, it seems that XR1 would have still set its keepalive to 1/3 of the holdtime, ignoring the locally configured value. It appears that newer code now matches the IOS-XE behavior, allowing you to manually change the keepalive interval.
Let’s now examine the BGP session between R5-XR1:
Because XR1 specifies a min acceptable hold time of 60 seconds, and R5 uses a holdtime of 30 seconds, the BGP sesssion cannot form. We see the following log messages:
Unfortunately for the client (R5), it has no idea what hold time it is allowed to actually use. The value isn’t specified in the Notification message that XR1 sends to R5.
In summary, BFD is a much better mechanism as a fast keepalive between BGP peers. However, you can generally use the fact that the hold time is negotiated between peers to your advantage. You can usually set your side to a lower value, such as 5/15, and count on the other end being able to negotiate down to this with you. Just remember that you will need to reset the BGP session for this to take effect, as the hold time is negotiated during session setup via the OPEN message.
