In this post we’ll deep into the operation of BGP that is a Border Gateway protocol aimed at connecting (routing information exchange) autonomous system in contrast with IGP (Interior Gateway Protocols) that run into each autonomous system. Thus, we do not need to have detailed information about IGPs to exchange routing information… before this routing information is exchanged, it is necessary to build neighborship between BGP routers.
At the beginning of the BGP peering establishment, the BGP neighbors agree on the hold time value (included in OPEN message, look at the upcoming figure showing a paquet capture for this information): the time a peering would be maintained without the reception of a KEEPALIVE or UPDATE… Keepalive messages help refresh BGP session information but if the timer reaches the hold time value, this informatoin is just sweept away.
Lab setup
In Cisco IOS version: Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.3(3)XB12, RELEASE SOFTWARE (fc2), It is possible to configure these times globally, per peer group or per neighbor.
Keepalive, hold and minimum acceptable hold times,
Essentially 2 timers are put into play : keepalive, and hold. The default values are 60, 180 and 180 seconds, respectively…
The keepalive time is the time interval between different keepalive message sendings.
On the other hand, the hold time is the time during which a BGP peering session is maintained before any KEEPALIVE or UPDATE reception from the peer.
The Minimum acceptable hold time is the minimum accepted hold time of a specific neighbor.
In the upcoming paragraphs, will explore in detail the operation of all these timers during the establishement of the BGP peering sessions and their maintenance…
A minimum acceptable hold time,
The Minimum acceptable hold time is the minimum accepted hold time of a specific neighbor and should be less than or equal to the configured hold time. Why?
Let’s suppose that this time is strictly greater than the configured hold time, then all the hold time values, received from the peer, that are between the local BGP router configured hold time and the minimum acceptable hold time, are not accepted which causes the peering session simply to not establish…
In the case where the BGP neighbor is not of equivalent class (very performant), this check on the received hold time guarantees that the local router would have the necessary resources (CPU, RAM, I/O, etc.) to generate keepalive messages or updates in a timely manner… it’s a way for it to pace the frequency of status update of the session.
In addition, this parameter may help get around bad network condition, that may impact the peering signalling operation, too… the more the condition is bad (flapping, unstable) the more big is the value of the holdown to allow the establishement of the session. This is a way to get rid of the bad condition of the network but does not mean that it’s safe to act like this for the simple reason that the information get obsolete and thus, may induce more network poor performance. Using Holddown timer in response to bad network condition need to be studied carefully…
Keepalive is local, hold is global…
If set to the default, the keepalive time calculation is based on the agreed upon session hold time. This is to ensure a correlated hold and keepalive time processing, and a more stable system…
But the administrator still has the control over the keepalive values to choose whatever value less than or equal to the third of the local router session hold time…
A step-by-step,
First and locally to each neighbor, the configured keepalive value is compared to the third of the configured hold time (hold time/3).
The minimum value of both is retained as the actual router keepalive.
At the reception of an OPEN message, each BGP router compares the BGP neighbor hold time to its corresponding local minimum acceptable hold time.
If the received hold time is less than the minimum acceptable hold time, a BGP NOTIFICATION message is sent to the neighbor and the neighborship session is reset.
Otherwise, the BGP router compares its configured hold time to the received hold time in the BGP neighbor OPEN message.
The minimum hold time is the new session hold time.
Locally to each BGP peer, the session keepalive time interval is deduced by comparing the configured keepalive to the third of the session hold time….
Conclusion,
BGP peers agree on the minimum hold time during session establishment and keepalive times, that are locally calculated, maybe different among peers.
If set to the default, the keepalive time calculation is based on the agreed upon session hold time. This is to ensure a correlated hold and keepalive time processing, and a more stable system…
But the administrator still has the control (directly per neighbor) over the keepalive values to choose whatever value less than or equal to the third of the local router session hold time…
The minimum acceptable hold time is to ensure that the BGP router and network have the necessary resources to support the peering signalling operation…
