diff options
| author | Quentin Young <qlyoung@cumulusnetworks.com> | 2019-09-16 17:33:49 +0200 |
|---|---|---|
| committer | Quentin Young <qlyoung@cumulusnetworks.com> | 2019-09-16 18:15:07 +0200 |
| commit | bfc18a0205a7658a489add497600edbc8c503fb1 (patch) | |
| tree | 34e68b96ed4dfd3d30e9586c2670cacb752f47ad /bgpd/bgp_keepalives.c | |
| parent | Merge pull request #4834 from srimohans/support_bundle (diff) | |
| download | frr-bfc18a0205a7658a489add497600edbc8c503fb1.tar.xz frr-bfc18a0205a7658a489add497600edbc8c503fb1.zip | |
bgpd: do not send keepalives when KA timer is 0
RFC4271 specifies behavior when the hold timer is sent to zero - we
should not send keepalives or run a hold timer. But FRR, and other
vendors, allow the keepalive timer to be set to zero with a nonzero hold
timer. In this case we were sending keepalives constantly and maxing out
a pthread to do so. Instead behave similarly to other vendors and do not
send keepalives.
Unsure what the utility of this is, but blasting keepalives is
definitely the wrong thing to do.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Diffstat (limited to 'bgpd/bgp_keepalives.c')
| -rw-r--r-- | bgpd/bgp_keepalives.c | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/bgpd/bgp_keepalives.c b/bgpd/bgp_keepalives.c index 6de1c216a..3a49e8bc0 100644 --- a/bgpd/bgp_keepalives.c +++ b/bgpd/bgp_keepalives.c @@ -97,11 +97,18 @@ static void peer_process(struct hash_bucket *hb, void *arg) static struct timeval tolerance = {0, 100000}; + uint32_t v_ka = atomic_load_explicit(&pkat->peer->v_keepalive, + memory_order_relaxed); + + /* 0 keepalive timer means no keepalives */ + if (v_ka == 0) + return; + /* calculate elapsed time since last keepalive */ monotime_since(&pkat->last, &elapsed); /* calculate difference between elapsed time and configured time */ - ka.tv_sec = pkat->peer->v_keepalive; + ka.tv_sec = v_ka; timersub(&ka, &elapsed, &diff); int send_keepalive = |