]> git.puffer.fish Git - mirror/frr.git/commit
bgpd: avoid clearing routes for peers that were never established 16302/head
authorLoïc Sang <loic.sang@6wind.com>
Wed, 19 Jun 2024 14:19:22 +0000 (16:19 +0200)
committerMergify <37929162+mergify[bot]@users.noreply.github.com>
Wed, 26 Jun 2024 20:46:36 +0000 (20:46 +0000)
commit73b18210f284684e3be2553269c389383f871a33
tree8335d820d42eb1fb9ff50e9e7479f2acaf409a60
parent6ea0a93ceb7e5d7245395f63d869b9c4991c577d
bgpd: avoid clearing routes for peers that were never established

Under heavy system load with many peers in passive mode and a large
number of routes, bgpd can enter an infinite loop. This occurs while
processing timeout BGP_OPEN messages, which prevents it from accepting
new connections. The following log entries illustrate the issue:
>bgpd[6151]: [VX6SM-8YE5W][EC 33554460] 3.3.2.224: nexthop_set failed, resetting connection - intf 0x0
>bgpd[6151]: [P790V-THJKS][EC 100663299] bgp_open_receive: bgp_getsockname() failed for peer: 3.3.2.224
>bgpd[6151]: [HTQD2-0R1WR][EC 33554451] bgp_process_packet: BGP OPEN receipt failed for peer: 3.3.2.224
... repeating

The issue occurs when bgpd handles a massive number of routes in the RIB
while receiving numerous BGP_OPEN packets. If bgpd is overloaded, it
fails to process these packets promptly, leading the remote peer to
close the connection and resend BGP_OPEN packets.

When bgpd eventually starts processing these timeout BGP_OPEN packets,
it finds the TCP connection closed by the remote peer, resulting in
"bgp_stop()" being called. For each timeout peer, bgpd must iterate
through the routing table, which is time-consuming and causes new
incoming BGP_OPEN packets to timeout, perpetuating the infinite loop.

To address this issue, the code is modified to check if the peer has
been established at least once before calling "bgp_clear_route_all()".
This ensures that routes are only cleared for peers that had a
successful session, preventing unnecessary iterations over the routing
table for peers that never established a connection.

With this change, BGP_OPEN timeout messages may still occur, but in the
worst case, bgpd will stabilize. Before this patch, bgpd could enter a
loop where it was unable to accpet any new connections.

Signed-off-by: Loïc Sang <loic.sang@6wind.com>
(cherry picked from commit e0ae285eb8beeef7b43bdadc073d8ae346eaeb6c)
bgpd/bgp_fsm.c