--- danny@tcb.net wrote: From: Danny McPherson <danny@tcb.net> On May 12, 2010, at 9:40 AM, Jay Nakamura wrote:
I just tested this and, yes, with Cisco to Cisco, changing the setting won't reset the connection but you have to reset the connection to have the value take effect. I need to look up what happens when two sides are set to different values and which one takes precedent.
: The holdtime isn't technically negotiated, both sides convey their : value in the open message and the lower of the two is used by both : BGP speakers. This isn't a negotiation? : IIRC, neither J or C reset the session with the timer change, but the : new holdtimer expiry value doesn't take effect until then. We use Alcatel 7750s. Damn thing just resets the session; no warning, no nothing. :-( : One other thing to note is that by default, keepalive intervals in : those implementations are {holdtime/3}. Normally, if you're setting : holdtime to something really lower (e.g., 10 seconds) you might want : to increase the frequency of keepalives such that the probability of : getting one through in times of instability rise. In particular, : congestion incurred outside of BGP, as update messages themselves : will serve as implicit keepalives, and with the amount of churn in BGP, : empty updates (keepalives) are rare for most speakers with a global BGP : view. I have been looking for info on the negative impact on a router by increasing the keepalive frequency to a high rate. I'm sure it's minimal for a few BGP peers, but I could imagine with a lot of peers it's a non-zero impact. scott
On 05/12/2010 02:41 PM, Scott Weeks wrote:
--- danny@tcb.net wrote: From: Danny McPherson <danny@tcb.net> On May 12, 2010, at 9:40 AM, Jay Nakamura wrote:
I just tested this and, yes, with Cisco to Cisco, changing the setting won't reset the connection but you have to reset the connection to have the value take effect. I need to look up what happens when two sides are set to different values and which one takes precedent.
: The holdtime isn't technically negotiated, both sides convey their : value in the open message and the lower of the two is used by both : BGP speakers.
This isn't a negotiation?
: IIRC, neither J or C reset the session with the timer change, but the : new holdtimer expiry value doesn't take effect until then.
We use Alcatel 7750s. Damn thing just resets the session; no warning, no nothing. :-(
: One other thing to note is that by default, keepalive intervals in : those implementations are {holdtime/3}. Normally, if you're setting : holdtime to something really lower (e.g., 10 seconds) you might want : to increase the frequency of keepalives such that the probability of : getting one through in times of instability rise. In particular, : congestion incurred outside of BGP, as update messages themselves : will serve as implicit keepalives, and with the amount of churn in BGP, : empty updates (keepalives) are rare for most speakers with a global BGP : view.
I have been looking for info on the negative impact on a router by increasing the keepalive frequency to a high rate. I'm sure it's minimal for a few BGP peers, but I could imagine with a lot of peers it's a non-zero impact.
with a keep alive interval of 10 seconds you can expect to get 10pps from a 100 peers. the keepalive message is 19bytes That doesn't seem particularly hurtful even by the standards of 5 year old control plane processors.
scott
participants (2)
-
Joel Jaeggli -
Scott Weeks