matthieu/frr
1
0
Fork 0
forked from Mirror/frr
Code Pull requests Activity
frr/bgpd/bgp_fsm.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

3095 lines
93 KiB
C
Raw Normal View History

*: auto-convert to SPDX License IDs Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-08 13:17:09 +01:00
// SPDX-License-Identifier: GPL-2.0-or-later
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP-4 Finite State Machine
*: make consistent & update GPLv2 file headers The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-05-13 10:25:29 +02:00
* From RFC1771 [A Border Gateway Protocol 4 (BGP-4)]
* Copyright (C) 1996, 97, 98 Kunihiro Ishiguro
*/
Initial revision
2002-12-13 21:15:29 +01:00
#include <zebra.h>
#include "linklist.h"
#include "prefix.h"
#include "sockunion.h"
*: Convert event.h to frrevent.h We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-07 20:22:48 +01:00
#include "frrevent.h"
Initial revision
2002-12-13 21:15:29 +01:00
#include "log.h"
#include "stream.h"
bgpd: use ring buffer for network input The multithreading code has a comment that reads: "XXX: Heavy abuse of stream API. This needs a ring buffer." This patch makes the relevant code use a ring buffer. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-01-02 19:20:00 +01:00
#include "ringbuf.h"
Initial revision
2002-12-13 21:15:29 +01:00
#include "memory.h"
#include "plist.h"
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
#include "workqueue.h"
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
#include "queue.h"
lib, bgpd, tests: Refactor FILTER_X in zebra.h lib/zebra.h has FILTER_X #define's. These do not belong there. Put them in lib/filter.h where they belong. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> (cherry picked from commit 0490729cc033a3483fc6b0ed45085ee249cac779)
2016-01-07 16:03:01 +01:00
#include "filter.h"
bgpd: argv update for all but bgp_vty.c Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2016-09-22 17:15:50 +02:00
#include "command.h"
bgpd: Convert to using LIB_ERR_XXX where possible Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-06-19 20:42:55 +02:00
#include "lib_errors.h"
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
#include "zclient.h"
Added json formating support to show-...-neighbors-... bgp commands. Ticket: CM-6789 Reviewed By: CCR-3263 Testing Done: Manual Testing and smoke tests Whenever some sort of output is encountered, added a json version with proper logic as well.
2015-08-12 15:59:18 +02:00
#include "lib/json.h"
Initial revision
2002-12-13 21:15:29 +01:00
#include "bgpd/bgpd.h"
#include "bgpd/bgp_attr.h"
#include "bgpd/bgp_debug.h"
bgpd: implement zlog_ferr facility for enhance error messages in bgp Signed-off-by: Don Slice <dslice@cumulusnetworks.com<
2018-06-15 23:08:53 +02:00
#include "bgpd/bgp_errors.h"
Initial revision
2002-12-13 21:15:29 +01:00
#include "bgpd/bgp_fsm.h"
#include "bgpd/bgp_packet.h"
#include "bgpd/bgp_network.h"
#include "bgpd/bgp_route.h"
#include "bgpd/bgp_dump.h"
#include "bgpd/bgp_open.h"
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
#include "bgpd/bgp_advertise.h"
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
#include "bgpd/bgp_community.h"
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
#include "bgpd/bgp_updgrp.h"
bgpd: bgpd-warnings.patch Remove compile warnings for the bgpd directory Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by:
2015-05-20 03:12:17 +02:00
#include "bgpd/bgp_nht.h"
This patch changes BGP from only listening mode for BFD status updates to interactive mode of dynamically registering/deregistering BFD enabled peers with PTM/BFD through zebra. Peer is registered with BFD when it goes into established state and de-registers when it goes out of establish state. This patch also adds BFD multihop support for BGP. Whether a peer is multi-hop or single hop is determined internally. All IGP peers are considered as multi-hop peers. EBGP peers are considered as single hop unless configured as multi-hop. BGP BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx). router bgp <as-number> neighbor <name/ip-address> bfd <detect mult> <min rx> <min tx> Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
2015-06-12 16:59:11 +02:00
#include "bgpd/bgp_bfd.h"
*: split & distribute memtypes and stop (re|ab)using lib/ MTYPEs This is a rather large mechanical commit that splits up the memory types defined in lib/memtypes.c and distributes them into *_memory.[ch] files in the individual daemons. The zebra change is slightly annoying because there is no nice place to put the #include "zebra_memory.h" statement. bgpd, ospf6d, isisd and some tests were reusing MTYPEs defined in the library for its own use. This is bad practice and would break when the memtype are made static. Acked-by: Vincent JARDIN <vincent.jardin@6wind.com> Acked-by: Donald Sharp <sharpd@cumulusnetworks.com> [CF: rebased for cmaster-next] Signed-off-by: David Lamparter <equinox@opensourcerouting.org> Signed-off-by: Christian Franke <chris@opensourcerouting.org>
2015-05-29 05:48:31 +02:00
#include "bgpd/bgp_memory.h"
bgpd: put BGP keepalives in a pthread This patch, in tandem with moving packet writes into a dedicated kernel thread, fixes session flaps caused by long-running internal operations starving the (old) userspace write thread. BGP keepalives are now produced by a kernel thread and placed onto the peer's output queue. These are then consumed by the write thread. Both of these tasks are concurrent with the rest of bgpd, obviating the session flaps described above. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-01-06 00:13:16 +01:00
#include "bgpd/bgp_keepalives.h"
bgpd: move bgp i/o to a separate source file After implement threading, bgp_packet.c was serving the double purpose of consolidating packet parsing functionality and handling actual I/O operations. This is somewhat messy and difficult to understand. I've thus moved all code and data structures for handling threaded packet writes to bgp_io.[ch]. Although bgp_io.[ch] only handles writes at the moment to keep the noise on this commit series down, for organization purposes, it's probably best to move bgp_read() and its trappings into here as well and restructure that code so that read()'s happen in the pthread and packet processing happens on the main thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-04-18 20:11:43 +02:00
#include "bgpd/bgp_io.h"
bgpd: Respect ability to reach nexthop if available When bgp is thinking about opening a connection to a peer, if we are connected to zebra, allow that to influence our decision to start the connection. Found Scenario: Both bgp and zebra are started up at the same time. Zebra is being used to create the connected route through which bgp will establish a peering relationship. The machine is a bit loaded due to other startup conditions and as such bgp gets to the connection stage here before zebra has installed the route. If bgp does not respect zebra data when it does have a connection then we will attempt to connect. The connect will fail because there is no route. At that time we will go into the connect timeout(2 minutes) and delay connection. What this does. If we have established a zebra connection and we do not have a clear path to the destination at this point do not allow the connection to proceed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-05-11 13:40:55 +02:00
#include "bgpd/bgp_zebra.h"
bgpd: Use the header Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-17 22:36:22 +01:00
#include "bgpd/bgp_vty.h"
*: nuke ^L (page feed) Quagga sources have inherited a slew of Page Feed (^L, \xC) characters from ancient history. Among other things, these break patchwork's XML-RPC API because \xC is not a valid character in XML documents. Nuke them from high orbit. Patches can be adapted simply by: sed -e 's%^L%%' -i filename.patch (you can type page feeds in some environments with Ctrl-V Ctrl-L) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2014-06-04 06:53:35 +02:00
*: use hooks for sending SNMP traps This means there are no ties into the SNMP code anymore other than the init call at startup. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2016-06-12 17:32:23 +02:00
DEFINE_HOOK(peer_backward_transition, (struct peer * peer), (peer));
bgpd: hook for bgp peer status change events Generally available hook for plugging application-specific code in for bgp peer change events. This hook (peer_status_changed) replaces the previous, more specific 'peer_established' hook with a more general-purpose one. Also, 'bgp_dump_state' is now registered under this hook. Signed-off-by: Marton Kun-Szabo <martonk@amazon.com>
2019-08-09 19:53:01 +02:00
DEFINE_HOOK(peer_status_changed, (struct peer * peer), (peer));
bgpd: Use the header Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-17 22:36:22 +01:00
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
/* Definition of display strings corresponding to FSM events. This should be
* kept consistent with the events defined in bgpd.h
*/
*: generously apply const const const const your boat, merrily down the stream... Signed-off-by: David Lamparter <equinox@diac24.net>
2019-11-20 17:26:59 +01:00
static const char *const bgp_event_str[] = {
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
NULL,
"BGP_Start",
"BGP_Stop",
"TCP_connection_open",
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
"TCP_connection_open_w_delay",
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
"TCP_connection_closed",
"TCP_connection_open_failed",
"TCP_fatal_error",
"ConnectRetry_timer_expired",
"Hold_Timer_expired",
"KeepAlive_timer_expired",
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
"DelayOpen_timer_expired",
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
"Receive_OPEN_message",
"Receive_KEEPALIVE_message",
"Receive_UPDATE_message",
"Receive_NOTIFICATION_message",
"Clearing_Completed",
};
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP FSM (finite state machine) has three types of functions. Type
one is thread functions. Type two is event functions. Type three
is FSM functions. Timer functions are set by bgp_timer_set
function. */
/* BGP event function. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
void bgp_event(struct event *event);
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP thread functions. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_start_timer(struct event *event);
static void bgp_connect_timer(struct event *event);
static void bgp_holdtime_timer(struct event *event);
static void bgp_delayopen_timer(struct event *event);
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
/* Register peer with NHT */
bgpd: Address LL peer not NHT when receiving connection attempt The new LL code in: 8761cd6ddb5437767625f58c8e9cc3ccda7887ab Introduced the idea of the bgp unnumbered peers using interface up/down events to track the bgp peers nexthop. This code was not properly working when a connection was received from a peer in some circumstances. Effectively the connection from a peer was immediately skipping state transitions and FRR was never properly tracking the peers nexthop. When we receive the connection attempt, let's track the nexthop now. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-12 20:16:30 +02:00
int bgp_peer_reg_with_nht(struct peer *peer)
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
{
int connected = 0;
bgpd: Replace magic number 1 for TTL to BGP_DEFAULT_TTL For readability and maintainability purposes. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2019-11-27 09:48:17 +01:00
if (peer->sort == BGP_PEER_EBGP && peer->ttl == BGP_DEFAULT_TTL
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
&& !CHECK_FLAG(peer->flags, PEER_FLAG_DISABLE_CONNECTED_CHECK)
bgpd: Replace bgp_flag_* to [UN]SET/CHECK_FLAG macros Most of the code uses macros, thus let's keep the code unified. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-06 15:37:20 +01:00
&& !CHECK_FLAG(peer->bgp->flags, BGP_FLAG_DISABLE_NH_CONNECTED_CHK))
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
connected = 1;
bgpd: Move the peer->su to connection->su The sockunion is per connection. So let's move it over. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-08 18:02:05 +02:00
return bgp_find_or_add_nexthop(peer->bgp, peer->bgp,
family2afi(
peer->connection->su.sa.sa_family),
SAFI_UNICAST, NULL, peer, connected,
NULL);
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
}
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
static void peer_xfer_stats(struct peer *peer_dst, struct peer *peer_src)
{
/* Copy stats over. These are only the pre-established state stats */
peer_dst->open_in += peer_src->open_in;
peer_dst->open_out += peer_src->open_out;
peer_dst->keepalive_in += peer_src->keepalive_in;
peer_dst->keepalive_out += peer_src->keepalive_out;
peer_dst->notify_in += peer_src->notify_in;
peer_dst->notify_out += peer_src->notify_out;
peer_dst->dynamic_cap_in += peer_src->dynamic_cap_in;
peer_dst->dynamic_cap_out += peer_src->dynamic_cap_out;
}
static struct peer *peer_xfer_conn(struct peer *from_peer)
{
struct peer *peer;
afi_t afi;
safi_t safi;
bgpd: Convert #define of bgp fsm events to an enum In PR #6052 which fixes issue #5963 the bgp fsm events were confused with the bgp fsm status leading to a bug. Let's start separating those out so these types of failures cannot just easily occur. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-03-20 01:19:50 +01:00
enum bgp_fsm_events last_evt, last_maj_evt;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *keeper, *going_away;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
assert(from_peer != NULL);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
/*
* Keeper is the connection that is staying around
*/
keeper = from_peer->connection;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
peer = from_peer->doppelganger;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (!peer || !CHECK_FLAG(peer->flags, PEER_FLAG_CONFIG_NODE))
return from_peer;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
/*
* from_peer is pointing at the non config node and
* at this point peer is pointing at the CONFIG node
* peer ( non incoming connection ). The going_away pointer
* is the connection that is being placed on to
* the non Config node for deletion.
*/
going_away = peer->connection;
bgpd: Try to notice when configuration changes during startup During peer startup there exists the possibility that both locally and remote peers try to start communication at the same time. In addition it is possible for local configuration to change at the same time this is going on. When this happens try to notice that the remote peer may be in opensent or openconfirm and if so we need to restart the connection from both sides. Additionally try to write a bit of extra code in peer_xfer_conn to notice when this happens and to emit a error message to the end user about this happening so that it can be cleaned up. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-09-11 14:13:42 +02:00
/*
* Let's check that we are not going to loose known configuration
* state based upon doppelganger rules.
*/
FOREACH_AFI_SAFI (afi, safi) {
if (from_peer->afc[afi][safi] != peer->afc[afi][safi]) {
flog_err(
EC_BGP_DOPPELGANGER_CONFIG,
"from_peer->afc[%d][%d] is not the same as what we are overwriting",
afi, safi);
return NULL;
}
}
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
if (bgp_debug_neighbor_events(peer))
During connection setup, there may be two connections in progress for a BGP peer - one initiated by the local system and the other initiated by the peer. Enhance key debug logs to also print the socket file descriptor so that it is clear which events pertain to which connection.
2015-05-20 03:04:19 +02:00
zlog_debug("%s: peer transfer %p fd %d -> %p fd %d)",
bgpd: Convert `struct peer_connection` to dynamically allocated As part of the conversion to a `struct peer_connection` it will be desirable to have 2 pointers one for when we open a connection and one for when we receive a connection. Start this actual conversion over to this in `struct peer`. If this sounds confusing take a look at the bgp state machine for connections and how it resolves the processing of this router opening -vs- this router receiving an open. At some point in time the state machine decides that we are keeping one of the two connections. Future commits will allow us to untangle the peer/doppelganger duality with this abstraction. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 05:43:46 +02:00
from_peer->host, from_peer, from_peer->connection->fd,
peer, peer->connection->fd);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_writes_off(going_away);
bgp_reads_off(going_away);
bgp_writes_off(keeper);
bgp_reads_off(keeper);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: BGP assert when it tries to access peer which is closed. Problem: BGP peer pointer is present in keepalive hash table even when socket has been closed in some race condition. When keepalive tries to access this peer it asserts. RCA: Below sequence of events causing assert. 1. Config node peer has went down due to TCP reset it's FD has been set to -1. 2. Doppelganger peer goes to established state and it has been added to peer hash table for keepalive when it was in openconfirm state. 3. Config node parameters including FD are exchanged with doppelganger. Doppelganger will not have FD -1. 4. Doppelganger will be deleted as part of this it will remove it from the keepalive peer hash table. 5. While removing from hash table it tries to acquire lock. 6. During this time keepalive thread has the lock and in a loop trying to send keepalive for peers in hash table. 7. It tries to send keepalive for doppelganger peer with fd set to -1 and asserts. Signed-off-by: Santosh P K <sapk@vmware.com>
2019-11-25 17:49:38 +01:00
/*
* Before exchanging FD remove doppelganger from
* keepalive peer hash. It could be possible conf peer
* fd is set to -1. If blocked on lock then keepalive
* thread can access peer pointer with fd -1.
*/
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_keepalives_off(keeper);
EVENT_OFF(going_away->t_routeadv);
EVENT_OFF(going_away->t_connect);
EVENT_OFF(going_away->t_delayopen);
EVENT_OFF(going_away->t_connect_check_r);
EVENT_OFF(going_away->t_connect_check_w);
bgpd: Fix wrong pthread event cancelling 0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 1 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 2 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 3 0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 4 0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258 5 <signal handler called> 6 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 7 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 8 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 9 0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79 11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470 14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355 15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610 16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152 17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639 18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111 19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252 20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214 21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180 22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) f 12 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 1428 assert(m->owner == pthread_self()); In this decode the attempt to cancel the connection's events from the wrong thread is causing the crash. Modify the code to create an event on the bm->master to cancel the events for the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-10-24 23:44:31 +02:00
EVENT_OFF(going_away->t_stop_with_notify);
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(keeper->t_routeadv);
EVENT_OFF(keeper->t_connect);
EVENT_OFF(keeper->t_delayopen);
EVENT_OFF(keeper->t_connect_check_r);
EVENT_OFF(keeper->t_connect_check_w);
EVENT_OFF(keeper->t_process_packet);
bgpd: move packet writes into dedicated pthread * BGP_WRITE_ON() removed * BGP_WRITE_OFF() removed * peer_writes_on() added * peer_writes_off() added * bgp_write_proceed_actions() removed Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-02-07 00:39:06 +01:00
bgpd, tests: comment formatting Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-08 17:51:12 +02:00
/*
* At this point in time, it is possible that there are packets pending
* on various buffers. Those need to be transferred or dropped,
* otherwise we'll get spurious failures during session establishment.
*/
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
peer->connection = keeper;
keeper->peer = peer;
from_peer->connection = going_away;
going_away->peer = from_peer;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-no-as.patch bgp: Fixup of the remote-as command to allow user to not have to enter an actual as number Signed-off-by: Donald Sharp<sharpd@cumulusnetworks.com> Reviewed-by:
2015-05-20 03:04:25 +02:00
peer->as = from_peer->as;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
peer->v_holdtime = from_peer->v_holdtime;
peer->v_keepalive = from_peer->v_keepalive;
peer->v_routeadv = from_peer->v_routeadv;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
peer->v_delayopen = from_peer->v_delayopen;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
peer->v_gr_restart = from_peer->v_gr_restart;
peer->cap = from_peer->cap;
bgpd: Add patches for RFC9234 implementation This commit fixes some issues that were noted by the reviewer Signed-off-by: Eugene Bogomazov <eb@qrator.net>
2022-06-20 14:39:03 +02:00
peer->remote_role = from_peer->remote_role;
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
last_evt = peer->last_event;
last_maj_evt = peer->last_major_event;
peer->last_event = from_peer->last_event;
peer->last_major_event = from_peer->last_major_event;
from_peer->last_event = last_evt;
from_peer->last_major_event = last_maj_evt;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
peer->remote_id = from_peer->remote_id;
bgpd: Add a new command to only show failed peerings In a data center, having 32-128 peers is not uncommon. In such a situation, to find a peer that has failed and why is several commands. This hinders both the automatability of failure detection and the ease/speed with which the reason can be found. To simplify this process of catching a failure and its cause quicker, this patch does the following: 1. Created a new function, bgp_show_failed_summary to display the failed summary output for JSON and vty 2. Created a new function to display the reset code/subcode. This is now used in the failed summary code and in the show neighbors code 3. Added a new variable failedPeers in all the JSON outputs, including the vanilla "show bgp summary" family. This lists the failed session count. 4. Display peer, dropped count, estd count, uptime and the reason for failure as the output of "show bgp summary failed" family of commands 5. Added three resset codes for the case where we're waiting for NHT, waiting for peer IPv6 addr, waiting for VRF to init. This also counts the case where only one peer has advertised an AFI/SAFI. The new command has the optional keyword "failed" added to the classical summary command. The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr, the output of that command will show a "waiting for NHT" etc. as the last reset reason. This patch includes update to the documentation too. Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
2019-08-31 18:24:49 +02:00
peer->last_reset = from_peer->last_reset;
bgpd: Set 4096 instead of 65535 as new max packet size for a new peer New peers should be initialized with a usual max packet size and later determined on OPEN messages. Testing with different peers supporting/not supporting extended support. 2021/07/02 13:48:00 BGP: [WEV7K-2GAQ5] u2:s2 send UPDATE len 8991 (max message len: 65535) numpfx 1788 2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809 2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809 Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-07-02 15:50:39 +02:00
peer->max_packet_size = from_peer->max_packet_size;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
BGP_GR_ROUTER_DETECT_AND_SEND_CAPABILITY_TO_ZEBRA(peer->bgp,
peer->bgp->peer);
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
bgpd: BGP tcp session failed to apply GR configuration on the transferred bgp tcp connection. When the BGP peer is configured between two bgp routes both routers would create peer structure , when they receive each other’s open message. In this event both speakers, open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. If BGP GR is enabled the old tcp session is dumped and the new session is retained. So while this transfer of connection is happening, if all the bgp gr config is not migrated to the new connection, the new bgp gr mode will never get applied. Fix Summary: 1. Replicate GR configuration from the old session to the new session in bgp_accept(). 2. Replicate GR configuration from stub to full-fledged peer in bgp_establish(). 3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers (if they are running) when the bgp GR mode is changed to “Disabled”. 4. Disable R-bit in cap, if it is not set the received open message. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-24 06:40:53 +02:00
if (bgp_peer_gr_mode_get(peer) == PEER_DISABLE) {
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_MODE);
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
if (CHECK_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT)) {
bgpd: BGP tcp session failed to apply GR configuration on the transferred bgp tcp connection. When the BGP peer is configured between two bgp routes both routers would create peer structure , when they receive each other’s open message. In this event both speakers, open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. If BGP GR is enabled the old tcp session is dumped and the new session is retained. So while this transfer of connection is happening, if all the bgp gr config is not migrated to the new connection, the new bgp gr mode will never get applied. Fix Summary: 1. Replicate GR configuration from the old session to the new session in bgp_accept(). 2. Replicate GR configuration from stub to full-fledged peer in bgp_establish(). 3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers (if they are running) when the bgp GR mode is changed to “Disabled”. 4. Disable R-bit in cap, if it is not set the received open message. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-24 06:40:53 +02:00
peer_nsf_stop(peer);
}
}
bgpd: Vanish FQDN capability hostname/domainname before handling new BGP OPEN Before this, if the peer disables sending FQDN capability, the old hostname still (STALE) exists and is misleading in the outputs of `show bgp ...`. Especially when using with `bgp default show-hostname`, etc. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-30 22:23:38 +01:00
if (peer->hostname) {
XFREE(MTYPE_BGP_PEER_HOST, peer->hostname);
peer->hostname = NULL;
}
bgpd: Exchange hostname capability and display hostnames in output This patch adds a hostname capability. The node's hostname and domainname are exchanged in the new capability and used in show command outputs based on a knob enabled by the user. The hostname and domainname can be a maximum of 64 chars long, each. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Ticket: CM-5660 Reviewed By: CCR-2563 Testing Done:
2015-09-11 05:10:16 +02:00
if (from_peer->hostname != NULL) {
bgpd: optimize copy of strings on peer_xfer_conn() Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2016-11-01 10:37:50 +01:00
peer->hostname = from_peer->hostname;
BGP memory leak in peer hostname Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-9786
2016-03-10 04:58:48 +01:00
from_peer->hostname = NULL;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Vanish FQDN capability hostname/domainname before handling new BGP OPEN Before this, if the peer disables sending FQDN capability, the old hostname still (STALE) exists and is misleading in the outputs of `show bgp ...`. Especially when using with `bgp default show-hostname`, etc. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-01-30 22:23:38 +01:00
if (peer->domainname) {
XFREE(MTYPE_BGP_PEER_HOST, peer->domainname);
peer->domainname = NULL;
}
bgpd: Exchange hostname capability and display hostnames in output This patch adds a hostname capability. The node's hostname and domainname are exchanged in the new capability and used in show command outputs based on a knob enabled by the user. The hostname and domainname can be a maximum of 64 chars long, each. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Ticket: CM-5660 Reviewed By: CCR-2563 Testing Done:
2015-09-11 05:10:16 +02:00
if (from_peer->domainname != NULL) {
bgpd: optimize copy of strings on peer_xfer_conn() Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2016-11-01 10:37:50 +01:00
peer->domainname = from_peer->domainname;
BGP memory leak in peer hostname Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-9786
2016-03-10 04:58:48 +01:00
from_peer->domainname = NULL;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Add BGP Software Version Capability Implement: https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability Tested with GoBGP: ``` % ./gobgp neighbor 192.168.10.124 BGP neighbor is 192.168.10.124, remote AS 65001 BGP version 4, remote router ID 200.200.200.202 BGP state = ESTABLISHED, up for 00:01:49 BGP OutQ = 0, Flops = 0 Hold time is 3, keepalive interval is 1 seconds Configured hold time is 90, keepalive interval is 30 seconds Neighbor capabilities: multiprotocol: ipv4-unicast: advertised and received ipv6-unicast: advertised route-refresh: advertised and received extended-nexthop: advertised Local: nlri: ipv4-unicast, nexthop: ipv6 UnknownCapability(6): received UnknownCapability(9): received graceful-restart: advertised and received Local: restart time 10 sec ipv6-unicast ipv4-unicast Remote: restart time 120 sec, notification flag set ipv4-unicast, forward flag set 4-octet-as: advertised and received add-path: received Remote: ipv4-unicast: receive enhanced-route-refresh: received long-lived-graceful-restart: advertised and received Local: ipv6-unicast, restart time 10 sec ipv4-unicast, restart time 20 sec Remote: ipv4-unicast, restart time 0 sec, forward flag set fqdn: advertised and received Local: name: donatas-pc, domain: Remote: name: spine1-debian-11, domain: software-version: advertised and received Local: GoBGP/3.10.0 Remote: FRRouting/8.5-dev-MyOwnFRRVersion-gdc92f44a45-dirt cisco-route-refresh: received Message statistics: ``` FRR side: ``` root@spine1-debian-11:~# vtysh -c 'show bgp neighbor 192.168.10.17 json' | \ > jq '."192.168.10.17".neighborCapabilities.softwareVersion.receivedSoftwareVersion' "GoBGP/3.10.0" root@spine1-debian-11:~# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-25 08:00:23 +01:00
if (peer->soft_version) {
XFREE(MTYPE_BGP_SOFT_VERSION, peer->soft_version);
peer->soft_version = NULL;
}
if (from_peer->soft_version) {
peer->soft_version = from_peer->soft_version;
from_peer->soft_version = NULL;
}
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
FOREACH_AFI_SAFI (afi, safi) {
peer->af_sflags[afi][safi] = from_peer->af_sflags[afi][safi];
peer->af_cap[afi][safi] = from_peer->af_cap[afi][safi];
peer->afc_nego[afi][safi] = from_peer->afc_nego[afi][safi];
peer->afc_adv[afi][safi] = from_peer->afc_adv[afi][safi];
peer->afc_recv[afi][safi] = from_peer->afc_recv[afi][safi];
peer->orf_plist[afi][safi] = from_peer->orf_plist[afi][safi];
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
peer->llgr[afi][safi] = from_peer->llgr[afi][safi];
bgpd: Implement Paths-Limit capability https://datatracker.ietf.org/doc/html/draft-abraitis-idr-addpath-paths-limit Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-01-23 19:33:18 +01:00
peer->addpath_paths_limit[afi][safi] =
from_peer->addpath_paths_limit[afi][safi];
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
if (bgp_getsockname(keeper) < 0) {
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_LIB_SOCKET,
"%%bgp_getsockname() failed for %s peer %s fd %d (from_peer fd %d)",
(CHECK_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER)
? "accept"
: ""),
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
peer->host, going_away->fd, keeper->fd);
BGP_EVENT_ADD(going_away, BGP_Stop);
BGP_EVENT_ADD(keeper, BGP_Stop);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
return NULL;
}
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (going_away->status > Active) {
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
if (bgp_getsockname(going_away) < 0) {
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_LIB_SOCKET,
"%%bgp_getsockname() failed for %s from_peer %s fd %d (peer fd %d)",
(CHECK_FLAG(from_peer->sflags,
PEER_STATUS_ACCEPT_PEER)
? "accept"
: ""),
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
from_peer->host, going_away->fd, keeper->fd);
bgp_stop(going_away);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
from_peer = NULL;
}
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: use atomic_* ops on _Atomic variables Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-01-09 21:38:17 +01:00
// Note: peer_xfer_stats() must be called with I/O turned OFF
if (from_peer)
peer_xfer_stats(peer, from_peer);
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
/* Register peer for NHT. This is to allow RAs to be enabled when
* needed, even on a passive connection.
*/
bgp_peer_reg_with_nht(peer);
bgpd: Address LL peer not NHT when receiving connection attempt The new LL code in: 8761cd6ddb5437767625f58c8e9cc3ccda7887ab Introduced the idea of the bgp unnumbered peers using interface up/down events to track the bgp peers nexthop. This code was not properly working when a connection was received from a peer in some circumstances. Effectively the connection from a peer was immediately skipping state transitions and FRR was never properly tracking the peers nexthop. When we receive the connection attempt, let's track the nexthop now. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-12 20:16:30 +02:00
if (from_peer)
bgp_replace_nexthop_by_peer(from_peer, peer);
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_reads_on(keeper);
bgp_writes_on(keeper);
event_add_event(bm->master, bgp_process_packet, keeper, 0,
&keeper->t_process_packet);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
return (peer);
}
Initial revision
2002-12-13 21:15:29 +01:00
/* Hook function called after bgp event is occered. And vty's
neighbor command invoke this function after making neighbor
structure. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
void bgp_timer_set(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
afi_t afi;
safi_t safi;
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
struct peer *peer = connection->peer;
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
switch (connection->status) {
Initial revision
2002-12-13 21:15:29 +01:00
case Idle:
/* First entry point of peer's finite state machine. In Idle
status start timer is on unless peer is shutdown or peer is
inactive. All other timer must be turned off */
bgpd: Print the real reason why the peer is not accepted (incoming) If it's suppressed due to BFD down or unspecified connection, we never know the real reason and just say "no AF activated" which is misleading. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-03-17 13:52:42 +01:00
if (BGP_PEER_START_SUPPRESSED(peer) || peer_active(connection) != BGP_PEER_ACTIVE ||
bgpd: peer_active is connection oriented, make it so Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 21:30:32 +01:00
peer->bgp->vrf_id == VRF_UNKNOWN) {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
Initial revision
2002-12-13 21:15:29 +01:00
} else {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_start, bgp_start_timer,
Reduce the amount of time it takes to bring up a large number of peers Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
peer->v_start);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_connect);
EVENT_OFF(connection->t_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
EVENT_OFF(connection->t_delayopen);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
case Connect:
Initial revision
2002-12-13 21:15:29 +01:00
/* After start timer is expired, the peer moves to Connect
status. Make sure start timer is off and connect timer is
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
on. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
if (CHECK_FLAG(peer->flags, PEER_FLAG_TIMER_DELAYOPEN))
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_connect, bgp_connect_timer,
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
(peer->v_delayopen + peer->v_connect));
else
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_connect, bgp_connect_timer,
peer->v_connect);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
Initial revision
2002-12-13 21:15:29 +01:00
break;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
case Active:
/* Active is waiting connection from remote peer. And if
connect timer is expired, change status to Connect. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
Reduce the amount of time it takes to bring up a large number of peers Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
/* If peer is passive mode, do not set connect timer. */
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
if (CHECK_FLAG(peer->flags, PEER_FLAG_PASSIVE)
|| CHECK_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT)) {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_connect);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
} else {
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
if (CHECK_FLAG(peer->flags, PEER_FLAG_TIMER_DELAYOPEN))
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_connect,
bgpd: t_connect conversion from peer to peer_connect Move t_connect into struct peer_connect Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:13:56 +02:00
bgp_connect_timer,
(peer->v_delayopen +
peer->v_connect));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
else
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_connect,
bgpd: t_connect conversion from peer to peer_connect Move t_connect into struct peer_connect Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:13:56 +02:00
bgp_connect_timer, peer->v_connect);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
Initial revision
2002-12-13 21:15:29 +01:00
case OpenSent:
/* OpenSent status. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
EVENT_OFF(connection->t_connect);
Initial revision
2002-12-13 21:15:29 +01:00
if (peer->v_holdtime != 0) {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer,
peer->v_holdtime);
Reduce the amount of time it takes to bring up a large number of peers Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
} else {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_holdtime);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
EVENT_OFF(connection->t_delayopen);
Reduce the amount of time it takes to bring up a large number of peers Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
break;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Reduce the amount of time it takes to bring up a large number of peers Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
case OpenConfirm:
Initial revision
2002-12-13 21:15:29 +01:00
/* OpenConfirm status. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
EVENT_OFF(connection->t_connect);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
/*
* If the negotiated Hold Time value is zero, then the Hold Time
* timer and KeepAlive timers are not started.
* Additionally if a different hold timer has been negotiated
* than we must stop then start the timer again
*/
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
if (peer->v_holdtime == 0)
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
else {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer,
peer->v_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_on(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
EVENT_OFF(connection->t_delayopen);
Initial revision
2002-12-13 21:15:29 +01:00
break;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
case Established:
/* In Established status start and connect timer is turned
off. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
EVENT_OFF(connection->t_connect);
EVENT_OFF(connection->t_delayopen);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
/*
* Same as OpenConfirm, if holdtime is zero then both holdtime
* and keepalive must be turned off.
* Additionally if a different hold timer has been negotiated
* then we must stop then start the timer again
*/
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
if (peer->v_holdtime == 0)
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: Always restart timer from scratch in OpenConfirm/Established Imagine this scenario: A peer has very large hold/keepalive timers of 600/200. This peer is using the DataCenter default time. As such the open will cause the t_holdtime to be negotiated to 600 seconds. Now also imagine that both peers are in update-delay. If we do not restart the timers and both peers are in Update Delay, we will continously reset the peer because the hold time will be hit( since the peer is not sending us any data ). Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-17 00:19:04 +01:00
else {
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer,
peer->v_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_on(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
break;
case Deleted:
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
EVENT_OFF(peer->connection->t_gr_restart);
EVENT_OFF(peer->connection->t_gr_stale);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
FOREACH_AFI_SAFI (afi, safi)
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(peer->t_llgr_stale[afi][safi]);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
bgpd: move t_pmax_restart to peer_connection The t_pmax_restart event pointer belongs in the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 04:20:16 +02:00
EVENT_OFF(peer->connection->t_pmax_restart);
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(peer->t_refresh_stalepath);
build: add -Wimplicit-fallthrough Also: - replace all /* fallthrough */ comments with portable fallthrough; pseudo keyword to accomodate both gcc and clang - add missing break; statements as required by older versions of gcc - cleanup some code to remove unnecessary fallthrough Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2023-10-10 23:15:32 +02:00
fallthrough;
Initial revision
2002-12-13 21:15:29 +01:00
case Clearing:
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_start);
EVENT_OFF(connection->t_connect);
EVENT_OFF(connection->t_holdtime);
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
EVENT_OFF(connection->t_routeadv);
EVENT_OFF(connection->t_delayopen);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
bgpd: Convert status defines to enum Convert some status defines for the fsm to an enum so that we cannot mix and match them in the future. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-03-20 14:03:08 +01:00
case BGP_STATUS_MAX:
flog_err(EC_LIB_DEVELOPMENT,
"BGP_STATUS_MAX while a legal state is not valid state for the FSM");
break;
Initial revision
2002-12-13 21:15:29 +01:00
}
}
/* BGP start timer. This function set BGP_Start event to thread value
and process event. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_start_timer(struct event *thread)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
Initial revision
2002-12-13 21:15:29 +01:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Timer (start timer expire for %s).", peer->host,
bgp_peer_get_connection_direction(connection));
Initial revision
2002-12-13 21:15:29 +01:00
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_VAL(thread) = BGP_Start;
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
bgp_event(thread); /* bgp_event unlocks peer */
Initial revision
2002-12-13 21:15:29 +01:00
}
/* BGP connect retry timer. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_connect_timer(struct event *thread)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* stop the DelayOpenTimer if it is running */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_delayopen);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
assert(!connection->t_write);
assert(!connection->t_read);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Timer (connect timer (%us) expire for %s)", peer->host,
peer->v_connect, bgp_peer_get_connection_direction(connection));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
if (CHECK_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER))
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_stop(connection);
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
else {
bgpd: Implement connect retry backoff Instead of starting with a fairly high value of retry, let's try with a lower and increase with a backoff to reach what was a default value (120s). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-05 09:49:52 +01:00
if (!peer->connect)
peer->v_connect = MIN(BGP_MAX_CONNECT_RETRY, peer->v_connect * 2);
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_VAL(thread) = ConnectRetry_timer_expired;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
bgp_event(thread); /* bgp_event unlocks peer */
}
Initial revision
2002-12-13 21:15:29 +01:00
}
/* BGP holdtime timer. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_holdtime_timer(struct event *thread)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Allow extending peer timeout in rare case Currently the I/O pthread handles incoming/outgoing data communication with all peers. There is no attempt at modifying the hold timers. It's sole goal is to read/write data to appropriate channels. All this data is handled as *events* on the master pthread in BGP. The problem is that if the master pthread is extremely busy then any packet read that would be treated as a keepalive event may happen after the hold timer pops, due to the way thread events are handled in lib/thread.c. In a last gap attempt, if we notice that we have incoming data to proceses on the input Queue, slightly delay the hold timer. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-06-15 16:35:50 +02:00
atomic_size_t inq_count;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
Initial revision
2002-12-13 21:15:29 +01:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Timer (holdtime timer expire for %s)", peer->host,
bgp_peer_get_connection_direction(connection));
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Allow extending peer timeout in rare case Currently the I/O pthread handles incoming/outgoing data communication with all peers. There is no attempt at modifying the hold timers. It's sole goal is to read/write data to appropriate channels. All this data is handled as *events* on the master pthread in BGP. The problem is that if the master pthread is extremely busy then any packet read that would be treated as a keepalive event may happen after the hold timer pops, due to the way thread events are handled in lib/thread.c. In a last gap attempt, if we notice that we have incoming data to proceses on the input Queue, slightly delay the hold timer. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-06-15 16:35:50 +02:00
/*
* Given that we do not have any expectation of ordering
* for handling packets from a peer -vs- handling
* the hold timer for a peer as that they are both
* events on the peer. If we have incoming
* data on the peers inq, let's give the system a chance
* to handle that data. This can be especially true
* for systems where we are heavily loaded for one
* reason or another.
*/
bgpd: Ensure ibuf count is protected by mutex Grab the count of streams in ibuf when it is protected by a mutex. Since this data is written to it in another pthread. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-01-15 19:26:58 +01:00
frr_with_mutex (&connection->io_mtx) {
inq_count = atomic_load_explicit(&connection->ibuf->count, memory_order_relaxed);
}
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
if (inq_count)
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer,
bgpd: Allow extending peer timeout in rare case Currently the I/O pthread handles incoming/outgoing data communication with all peers. There is no attempt at modifying the hold timers. It's sole goal is to read/write data to appropriate channels. All this data is handled as *events* on the master pthread in BGP. The problem is that if the master pthread is extremely busy then any packet read that would be treated as a keepalive event may happen after the hold timer pops, due to the way thread events are handled in lib/thread.c. In a last gap attempt, if we notice that we have incoming data to proceses on the input Queue, slightly delay the hold timer. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-06-15 16:35:50 +02:00
peer->v_holdtime);
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_VAL(thread) = Hold_Timer_expired;
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
bgp_event(thread); /* bgp_event unlocks peer */
Initial revision
2002-12-13 21:15:29 +01:00
}
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
void bgp_routeadv_timer(struct event *thread)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
Initial revision
2002-12-13 21:15:29 +01:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Timer (routeadv timer expire for %s)", peer->host,
bgp_peer_get_connection_direction(connection));
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Convert from bgp_clock() to monotime() Let's convert to our actual library call instead of using yet another abstraction that makes it fun for people to switch daemons. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-08-18 00:27:54 +02:00
peer->synctime = monotime(NULL);
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
event_add_timer_msec(bm->master, bgp_generate_updgrp_packets, connection,
0, &connection->t_generate_updgrp_packets);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
/* MRAI timer will be started again when FIFO is built, no need to
* do it here.
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
*/
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* RFC 4271 DelayOpenTimer */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
void bgp_delayopen_timer(struct event *thread)
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Timer (DelayOpentimer expire for %s)", peer->host,
bgp_peer_get_connection_direction(connection));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_VAL(thread) = DelayOpen_timer_expired;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgp_event(thread); /* bgp_event unlocks peer */
}
Merge bgpd changeset 1176 from Zebra repository by Rivo Nurges.
2004-05-20 11:19:34 +02:00
/* BGP Peer Down Cause */
bgpd: Make `suppress-fib-pending` clear peering When a peer has come up and already started installing routes into the rib and `suppress-fib-pending` is either turned on or off. BGP is left with some routes that may need to be withdrawn from peers and routes that it does not know the status of. Clear the BGP peers for the interesting parties and let's let us come up to speed as needed. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-12-11 16:46:53 +01:00
const char *const peer_down_str[] = {
"",
"Router ID changed",
"Remote AS changed",
"Local AS change",
"Cluster ID changed",
"Confederation identifier changed",
"Confederation peer changed",
"RR client config change",
"RS client config change",
"Update source change",
"Address family activated",
"Admin. shutdown",
"User reset",
"BGP Notification received",
"BGP Notification send",
"Peer closed the session",
"Neighbor deleted",
"Peer-group add member",
"Peer-group delete member",
"Capability changed",
"Passive config change",
"Multihop config change",
"NSF peer closed the session",
"Intf peering v6only config change",
"BFD down received",
"Interface down",
"Neighbor address lost",
"No path to specified Neighbor",
"Waiting for Peer IPv6 LLA",
"Waiting for VRF to be initialized",
"No AFI/SAFI activated for peer",
"AS Set config change",
"Waiting for peer OPEN",
"Reached received prefix count",
"Socket Error",
"Admin. shutdown (RTT)",
"Suppress Fib Turned On or Off",
bgpd: Set the last_reset if we change the password also ``` donatas.net(config-router)# do show ip bgp summary failed IPv4 Unicast Summary: BGP router identifier 1.1.1.1, local AS number 65001 VRF default vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 1, using 24 KiB of memory Neighbor EstdCnt DropCnt ResetTime Reason 127.0.0.1 2 2 00:02:02 Password config change (GoBGP/3.26.0) Displayed neighbors 1 Total number of neighbors 1 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-07-25 12:06:46 +02:00
"Password config change",
bgpd: Do not start BGP session if BGP identifier is not set If we have IPv6-only network and no IPv4 addresses at all, then by default 0.0.0.0 is created which is treated as malformed according to RFC 6286. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-29 22:03:06 +01:00
"Router ID is missing",
bgpd: Make `suppress-fib-pending` clear peering When a peer has come up and already started installing routes into the rib and `suppress-fib-pending` is either turned on or off. BGP is left with some routes that may need to be withdrawn from peers and routes that it does not know the status of. Clear the BGP peers for the interesting parties and let's let us come up to speed as needed. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-12-11 16:46:53 +01:00
};
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
static void bgp_graceful_restart_timer_off(struct peer_connection *connection,
struct peer *peer)
Merge bgpd changeset 1176 from Zebra repository by Rivo Nurges.
2004-05-20 11:19:34 +02:00
{
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
afi_t afi;
Merge bgpd changeset 1176 from Zebra repository by Rivo Nurges.
2004-05-20 11:19:34 +02:00
safi_t safi;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
FOREACH_AFI_SAFI (afi, safi)
if (CHECK_FLAG(peer->af_sflags[afi][safi],
PEER_STATUS_LLGR_WAIT))
return;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT);
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_gr_stale);
bgpd: Do not delete BGP dynamic peers if graceful restart kicks in ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 *donatas-pc(192.168.10.17) 4 65002 8 12 0 0 0 00:01:35 2 14 N/A ``` Before shutting down 192.168.10.17: ``` ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Last update: Sat Jan 15 21:45:47 2022 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (Older Path) Last update: Sat Jan 15 21:25:19 2022 ``` After 192.168.10.17 is down: ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 donatas-pc(192.168.10.17) 4 65002 5 9 0 0 0 00:00:12 Active 0 N/A ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Community: llgr-stale Last update: Sat Jan 15 21:49:01 2022 Time until Long-lived stale route deleted: 16 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Sat Jan 15 21:25:19 2022 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-15 22:16:15 +01:00
if (peer_dynamic_neighbor(peer) &&
!(CHECK_FLAG(peer->flags, PEER_FLAG_DELETE))) {
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s (dynamic neighbor) deleted (%s) for %s", __func__,
peer->host, bgp_peer_get_connection_direction(connection));
bgpd: Do not delete BGP dynamic peers if graceful restart kicks in ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 *donatas-pc(192.168.10.17) 4 65002 8 12 0 0 0 00:01:35 2 14 N/A ``` Before shutting down 192.168.10.17: ``` ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Last update: Sat Jan 15 21:45:47 2022 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (Older Path) Last update: Sat Jan 15 21:25:19 2022 ``` After 192.168.10.17 is down: ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 donatas-pc(192.168.10.17) 4 65002 5 9 0 0 0 00:00:12 Active 0 N/A ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Community: llgr-stale Last update: Sat Jan 15 21:49:01 2022 Time until Long-lived stale route deleted: 16 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Sat Jan 15 21:25:19 2022 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-15 22:16:15 +01:00
peer_delete(peer);
}
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_timer_set(connection);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
}
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_llgr_stale_timer_expire(struct event *thread)
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
{
struct peer_af *paf;
struct peer *peer;
afi_t afi;
safi_t safi;
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
paf = EVENT_ARG(thread);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
peer = paf->peer;
afi = paf->afi;
safi = paf->safi;
/* If the timer for the "Long-lived Stale Time" expires before the
* session is re-established, the helper MUST delete all the
* stale routes from the neighbor that it is retaining.
*/
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP Long-lived stale timer (%s) expired for %s", peer,
get_afi_safi_str(afi, safi, false),
bgp_peer_get_connection_direction(peer->connection));
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
UNSET_FLAG(peer->af_sflags[afi][safi], PEER_STATUS_LLGR_WAIT);
bgp_clear_stale_route(peer, afi, safi);
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_graceful_restart_timer_off(peer->connection, peer);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
}
static void bgp_set_llgr_stale(struct peer *peer, afi_t afi, safi_t safi)
{
struct bgp_dest *dest;
bgpd: When calling bgp_process, prevent infinite loop If we have this construct: for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) { ... bgp_process(); } This can induce an infinite loop. This happens because bgp_process will move the unsorted items to the top of the list for handling, as such it is necessary to hold the next pointer to the side to actually look at each possible bgp_path_info. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-12 21:08:35 +01:00
struct bgp_path_info *pi, *next;
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
struct bgp_table *table;
struct attr attr;
if (safi == SAFI_MPLS_VPN || safi == SAFI_ENCAP || safi == SAFI_EVPN) {
for (dest = bgp_table_top(peer->bgp->rib[afi][safi]); dest;
dest = bgp_route_next(dest)) {
struct bgp_dest *rm;
table = bgp_dest_get_bgp_table_info(dest);
if (!table)
continue;
for (rm = bgp_table_top(table); rm;
rm = bgp_route_next(rm))
bgpd: When calling bgp_process, prevent infinite loop If we have this construct: for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) { ... bgp_process(); } This can induce an infinite loop. This happens because bgp_process will move the unsorted items to the top of the list for handling, as such it is necessary to hold the next pointer to the side to actually look at each possible bgp_path_info. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-12 21:08:35 +01:00
for (pi = bgp_dest_get_bgp_path_info(rm);
(pi != NULL) && (next = pi->next, 1); pi = next) {
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
if (pi->peer != peer)
continue;
bgpd: Reuse get/set helpers for attr->community Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-02-23 08:05:47 +01:00
if (bgp_attr_get_community(pi->attr) &&
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
community_include(
bgpd: Reuse get/set helpers for attr->community Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-02-23 08:05:47 +01:00
bgp_attr_get_community(
pi->attr),
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
COMMUNITY_NO_LLGR))
continue;
bgpd: Set LLGR stale routes for all the paths including addpath Without this patch we set only the first path for the route (if multiple exist) as LLGR stale and stop doing that for the rest of the paths, which is wrong. Fixes: 1479ed2fb35f4a5ae1017201a7ee37ba2727163a ("bgpd: Implement LLGR helper mode") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-07 12:08:35 +01:00
if (bgp_attr_get_community(pi->attr) &&
community_include(bgp_attr_get_community(pi->attr),
COMMUNITY_LLGR_STALE))
continue;
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
if (bgp_debug_neighbor_events(peer))
zlog_debug(
bgpd: Add `%pBP` printfrr() extension to print `IP(hostname)` for BGP peer Replace existing bgp_peer_hostname() function. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-31 14:59:06 +02:00
"%pBP Long-lived set stale community (LLGR_STALE) for: %pFX",
bgpd: Convert from struct bgp_node to struct bgp_dest This is based on @donaldsharp's work The current code base is the struct bgp_node data structure. The problem with this is that it creates a bunch of extra data per route_node. The table structure generates ‘holder’ nodes that are never going to receive bgp routes, and now the memory of those nodes is allocated as if they are a full bgp_node. After splitting up the bgp_node into bgp_dest and route_node, the memory of ‘holder’ node which does not have any bgp data will be allocated as the route_node, not the bgp_node, and the memory usage is reduced. The memory usage of BGP node will be reduced from 200B to 96B. The total memory usage optimization of this part is ~16.00%. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
2023-07-31 14:34:48 +02:00
peer, &dest->rn->p);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
attr = *pi->attr;
bgp_attr_add_llgr_community(&attr);
pi->attr = bgp_attr_intern(&attr);
bgpd: Reduce # of iterations when doing llgr Code was scanning a table then identifying a prefix that needed to be modified then calling code that reran bestpath on the entire table again. If you had multiple items that needed processing you would end up scanning and setting the entire table to be scanned multiple times. No bueno. a) We do not need to reprocess items that are not being modified. b) We do not need to walk the entire table multiple times, we have the data that is needed already. Modify the code to just call bgp_process on the interesting nodes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-09-06 16:39:41 +02:00
bgp_process(peer->bgp, rm, pi, afi,
safi);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
}
}
} else {
for (dest = bgp_table_top(peer->bgp->rib[afi][safi]); dest;
dest = bgp_route_next(dest))
bgpd: When calling bgp_process, prevent infinite loop If we have this construct: for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) { ... bgp_process(); } This can induce an infinite loop. This happens because bgp_process will move the unsorted items to the top of the list for handling, as such it is necessary to hold the next pointer to the side to actually look at each possible bgp_path_info. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-12 21:08:35 +01:00
for (pi = bgp_dest_get_bgp_path_info(dest);
(pi != NULL) && (next = pi->next, 1); pi = next) {
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
if (pi->peer != peer)
continue;
bgpd: Reuse get/set helpers for attr->community Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-02-23 08:05:47 +01:00
if (bgp_attr_get_community(pi->attr) &&
community_include(
bgp_attr_get_community(pi->attr),
COMMUNITY_NO_LLGR))
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
continue;
bgpd: Set LLGR stale routes for all the paths including addpath Without this patch we set only the first path for the route (if multiple exist) as LLGR stale and stop doing that for the rest of the paths, which is wrong. Fixes: 1479ed2fb35f4a5ae1017201a7ee37ba2727163a ("bgpd: Implement LLGR helper mode") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-07 12:08:35 +01:00
if (bgp_attr_get_community(pi->attr) &&
community_include(bgp_attr_get_community(pi->attr),
COMMUNITY_LLGR_STALE))
continue;
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
if (bgp_debug_neighbor_events(peer))
zlog_debug(
bgpd: Add `%pBP` printfrr() extension to print `IP(hostname)` for BGP peer Replace existing bgp_peer_hostname() function. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-31 14:59:06 +02:00
"%pBP Long-lived set stale community (LLGR_STALE) for: %pFX",
bgpd: Convert from struct bgp_node to struct bgp_dest This is based on @donaldsharp's work The current code base is the struct bgp_node data structure. The problem with this is that it creates a bunch of extra data per route_node. The table structure generates ‘holder’ nodes that are never going to receive bgp routes, and now the memory of those nodes is allocated as if they are a full bgp_node. After splitting up the bgp_node into bgp_dest and route_node, the memory of ‘holder’ node which does not have any bgp data will be allocated as the route_node, not the bgp_node, and the memory usage is reduced. The memory usage of BGP node will be reduced from 200B to 96B. The total memory usage optimization of this part is ~16.00%. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
2023-07-31 14:34:48 +02:00
peer, &dest->rn->p);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
attr = *pi->attr;
bgp_attr_add_llgr_community(&attr);
pi->attr = bgp_attr_intern(&attr);
bgpd: Reduce # of iterations when doing llgr Code was scanning a table then identifying a prefix that needed to be modified then calling code that reran bestpath on the entire table again. If you had multiple items that needed processing you would end up scanning and setting the entire table to be scanned multiple times. No bueno. a) We do not need to reprocess items that are not being modified. b) We do not need to walk the entire table multiple times, we have the data that is needed already. Modify the code to just call bgp_process on the interesting nodes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-09-06 16:39:41 +02:00
bgp_process(peer->bgp, dest, pi, afi, safi);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
}
}
}
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_graceful_restart_timer_expire(struct event *thread)
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
struct peer *tmp_peer;
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
struct listnode *node, *nnode;
struct peer_af *paf;
afi_t afi;
safi_t safi;
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
if (bgp_debug_neighbor_events(peer))
zlog_debug("%pBP graceful restart timer expired and graceful restart stalepath timer stopped for %s",
peer, bgp_peer_get_connection_direction(connection));
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
FOREACH_AFI_SAFI (afi, safi) {
if (!peer->nsf[afi][safi])
continue;
/* Once the "Restart Time" period ends, the LLGR period is
* said to have begun and the following procedures MUST be
* performed:
*
* The helper router MUST start a timer for the
* "Long-lived Stale Time".
*
* The helper router MUST attach the LLGR_STALE community
* for the stale routes being retained. Note that this
* requirement implies that the routes would need to be
* readvertised, to disseminate the modified community.
*/
if (peer->llgr[afi][safi].stale_time) {
paf = peer_af_find(peer, afi, safi);
if (!paf)
continue;
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP Long-lived stale timer (%s) started for %d sec for %s",
peer, get_afi_safi_str(afi, safi, false),
peer->llgr[afi][safi].stale_time,
bgp_peer_get_connection_direction(connection));
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
SET_FLAG(peer->af_sflags[afi][safi],
PEER_STATUS_LLGR_WAIT);
bgp_set_llgr_stale(peer, afi, safi);
bgp_clear_stale_route(peer, afi, safi);
*: Convert thread_add_XXX functions to event_add_XXX Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-20 20:19:08 +02:00
event_add_timer(bm->master, bgp_llgr_stale_timer_expire,
paf, peer->llgr[afi][safi].stale_time,
&peer->t_llgr_stale[afi][safi]);
bgpd: Implement LLGR helper mode Tested between GoBGP and FRR (this commit). ``` ┌───────────┐ ┌────────────┐ │ │ │ │ │ GoBGPD │ │ FRRouting │ │ (restart) │ │ │ │ │ │ │ └──────┬────┘ └───────┬────┘ │ │ │ │ │ │ │ ┌───────────┐ │ │ │ │ │ │ │ │ │ └─────┤ FRRouting ├────────┘ │ (helper) │ │ │ └───────────┘ // GoBGPD % cat /etc/gobgp/config.toml [global.config] as = 65002 router-id = "2.2.2.2" port = 179 [[neighbors]] [neighbors.config] peer-as = 65001 neighbor-address = "2a02:abc::123" [neighbors.graceful-restart.config] enabled = true restart-time = 3 long-lived-enabled = true [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv6-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 10 [[neighbors.afi-safis]] [neighbors.afi-safis.config] afi-safi-name = "ipv4-unicast" [neighbors.afi-safis.mp-graceful-restart.config] enabled = true [neighbors.afi-safis.long-lived-graceful-restart.config] enabled = true restart-time = 20 % ./gobgp global rib add -a ipv6 2001:db8:4::/64 % ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7 % ./gobgp global rib add -a ipv4 100.100.100.100/32 % ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7 ``` 1. When killing GoBGPD, graceful restart timer starts in FRR helper router; 2. When GR timer expires in helper router: a) LLGR_STALE community is attached to routes to be retained; b) Clear stale routes that have NO_LLGR community attached; c) Start LLGR timer per AFI/SAFI; d) Recompute bestpath and reannounce routes to peers; d) When LLGR timer expires, clear all routes on particular AFI/SAFI. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2021-12-20 22:03:09 +01:00
for (ALL_LIST_ELEMENTS(peer->bgp->peer, node, nnode,
tmp_peer))
bgp_announce_route(tmp_peer, afi, safi, false);
} else {
bgp_clear_stale_route(peer, afi, safi);
}
}
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_graceful_restart_timer_off(connection, peer);
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_graceful_stale_timer_expire(struct event *thread)
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
afi_t afi;
safi_t safi;
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP graceful restart stalepath timer expired for %s", peer,
bgp_peer_get_connection_direction(connection));
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* NSF delete stale route */
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
FOREACH_AFI_SAFI_NSF (afi, safi)
if (peer->nsf[afi][safi])
bgp_clear_stale_route(peer, afi, safi);
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
/* Selection deferral timer processing function */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_graceful_deferral_timer_expire(struct event *thread)
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
{
struct afi_safi_info *info;
afi_t afi;
safi_t safi;
struct bgp *bgp;
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
info = EVENT_ARG(thread);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
afi = info->afi;
safi = info->safi;
bgp = info->bgp;
if (BGP_DEBUG(update, UPDATE_OUT))
bgpd: Cleanup some bad formating Some recent commits got some bad formating. Clean this up. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-01-31 15:19:24 +01:00
zlog_debug(
"afi %d, safi %d : graceful restart deferral timer expired",
afi, safi);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
bgp->gr_info[afi][safi].eor_required = 0;
bgp->gr_info[afi][safi].eor_received = 0;
XFREE(MTYPE_TMP, info);
/* Best path selection */
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
bgp_best_path_select_defer(bgp, afi, safi);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
static bool bgp_update_delay_applicable(struct bgp *bgp)
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
{
/* update_delay_over flag should be reset (set to 0) for any new
applicability of the update-delay during BGP process lifetime.
And it should be set after an occurence of the update-delay is
over)*/
if (!bgp->update_delay_over)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
bool bgp_update_delay_active(struct bgp *bgp)
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
{
if (bgp->t_update_delay)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
bool bgp_update_delay_configured(struct bgp *bgp)
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
{
if (bgp->v_update_delay)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
}
/* Do the post-processing needed when bgp comes out of the read-only mode
on ending the update delay. */
void bgp_update_delay_end(struct bgp *bgp)
{
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(bgp->t_update_delay);
EVENT_OFF(bgp->t_establish_wait);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
/* Reset update-delay related state */
bgp->update_delay_over = 1;
bgp->established = 0;
bgp->restarted_peers = 0;
bgp->implicit_eors = 0;
bgp->explicit_eors = 0;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
*: Rename quagga_timestamp with frr_timestamp Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-11-11 20:33:41 +01:00
frr_timestamp(3, bgp->update_delay_end_time,
sizeof(bgp->update_delay_end_time));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/*
* Add an end-of-initial-update marker to the main process queues so
* that
bgpd-scale-update-delay-packing.patch ISSUE: During startup, BGP update prefix packing wasnt optimal and route installation was found to be spread over. SOLUTION: With this patch, update-delay post processing is serialized to achieve: a. better peer update packing (which helps in reducing total number of BGP update packets) b. installation of the resulting routes in zebra as close to each others as possible. (which can help zebra batch its processing and updates to Kernel better)
2015-05-20 02:40:42 +02:00
* the route advertisement timer for the peers can be started. Also set
* the zebra and peer update hold flags. These flags are used to achieve
* three stages in the update-delay post processing:
* 1. Finish best-path selection for all the prefixes held on the
* queues.
* (routes in BGP are updated, and peers sync queues are populated
* too)
* 2. As the eoiu mark is reached in the bgp process routine, ship all
* the
* routes to zebra. With that zebra should see updates from BGP
* close
* to each other.
* 3. Unblock the peer update writes. With that peer update packing
* with
* the prefixes should be at its maximum.
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
*/
BGP: route-server will now use addpath...chop the _rsclient code Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-8122 per draft-ietf-idr-ix-bgp-route-server-09: 2.3.2.2.2. BGP ADD-PATH Approach The [I-D.ietf-idr-add-paths] Internet draft proposes a different approach to multiple path propagation, by allowing a BGP speaker to forward multiple paths for the same prefix on a single BGP session. As [RFC4271] specifies that a BGP listener must implement an implicit withdraw when it receives an UPDATE message for a prefix which already exists in its Adj-RIB-In, this approach requires explicit support for the feature both on the route server and on its clients. If the ADD-PATH capability is negotiated bidirectionally between the route server and a route server client, and the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients. For this reason, ADD- PATH implementations on a route server should enforce send-only mode with the route server clients, which would result in negotiating receive-only mode from the client to the route server. This allows us to delete all of the following code: - All XXXX_rsclient() functions - peer->rib - BGP_TABLE_MAIN and BGP_TABLE_RSCLIENT - RMAP_IMPORT and RMAP_EXPORT
2015-11-10 16:29:12 +01:00
bgp_add_eoiu_mark(bgp);
bgpd-scale-update-delay-packing.patch ISSUE: During startup, BGP update prefix packing wasnt optimal and route installation was found to be spread over. SOLUTION: With this patch, update-delay post processing is serialized to achieve: a. better peer update packing (which helps in reducing total number of BGP update packets) b. installation of the resulting routes in zebra as close to each others as possible. (which can help zebra batch its processing and updates to Kernel better)
2015-05-20 02:40:42 +02:00
bgp->main_zebra_update_hold = 1;
bgp->main_peers_update_hold = 1;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Make the process_queue per bgp process We currently have a global process queue for handling route updates in bgp. This is fine, in general, except there are places and times where we plug the queue for no new work during certain peer states of bgp update delay. If we happen to be processing multiple bgp instances on startup why do we want to stop processing in vrf A when vrf B is in a bit of a pickle? Also this separation will allow us to start forward thinking about how to fully integrate pthreads into route processing in bgp. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-10-17 15:43:14 +02:00
/*
* Resume the queue processing. This should trigger the event that would
* take care of processing any work that was queued during the read-only
* mode.
*/
work_queue_unplug(bgp->process_queue);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
}
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/**
* see bgp_fsm.h
*/
void bgp_start_routeadv(struct bgp *bgp)
{
struct listnode *node, *nnode;
struct peer *peer;
bgpd: changes for code maintainability these changes are for improving the code maintainability Signed-off-by: sri-mohan1 <sri.mohan@samsung.com>
2022-09-01 20:55:16 +02:00
zlog_info("%s, update hold status %d", __func__,
BGP: route-server will now use addpath...chop the _rsclient code Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-8122 per draft-ietf-idr-ix-bgp-route-server-09: 2.3.2.2.2. BGP ADD-PATH Approach The [I-D.ietf-idr-add-paths] Internet draft proposes a different approach to multiple path propagation, by allowing a BGP speaker to forward multiple paths for the same prefix on a single BGP session. As [RFC4271] specifies that a BGP listener must implement an implicit withdraw when it receives an UPDATE message for a prefix which already exists in its Adj-RIB-In, this approach requires explicit support for the feature both on the route server and on its clients. If the ADD-PATH capability is negotiated bidirectionally between the route server and a route server client, and the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients. For this reason, ADD- PATH implementations on a route server should enforce send-only mode with the route server clients, which would result in negotiating receive-only mode from the client to the route server. This allows us to delete all of the following code: - All XXXX_rsclient() functions - peer->rib - BGP_TABLE_MAIN and BGP_TABLE_RSCLIENT - RMAP_IMPORT and RMAP_EXPORT
2015-11-10 16:29:12 +01:00
bgp->main_peers_update_hold);
bgpd-scale-update-delay-packing.patch ISSUE: During startup, BGP update prefix packing wasnt optimal and route installation was found to be spread over. SOLUTION: With this patch, update-delay post processing is serialized to achieve: a. better peer update packing (which helps in reducing total number of BGP update packets) b. installation of the resulting routes in zebra as close to each others as possible. (which can help zebra batch its processing and updates to Kernel better)
2015-05-20 02:40:42 +02:00
BGP: route-server will now use addpath...chop the _rsclient code Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-8122 per draft-ietf-idr-ix-bgp-route-server-09: 2.3.2.2.2. BGP ADD-PATH Approach The [I-D.ietf-idr-add-paths] Internet draft proposes a different approach to multiple path propagation, by allowing a BGP speaker to forward multiple paths for the same prefix on a single BGP session. As [RFC4271] specifies that a BGP listener must implement an implicit withdraw when it receives an UPDATE message for a prefix which already exists in its Adj-RIB-In, this approach requires explicit support for the feature both on the route server and on its clients. If the ADD-PATH capability is negotiated bidirectionally between the route server and a route server client, and the route server client propagates multiple paths for the same prefix to the route server, then this could potentially cause the propagation of inactive, invalid or suboptimal paths to the route server, thereby causing loss of reachability to other route server clients. For this reason, ADD- PATH implementations on a route server should enforce send-only mode with the route server clients, which would result in negotiating receive-only mode from the client to the route server. This allows us to delete all of the following code: - All XXXX_rsclient() functions - peer->rib - BGP_TABLE_MAIN and BGP_TABLE_RSCLIENT - RMAP_IMPORT and RMAP_EXPORT
2015-11-10 16:29:12 +01:00
if (bgp->main_peers_update_hold)
bgpd-scale-update-delay-packing.patch ISSUE: During startup, BGP update prefix packing wasnt optimal and route installation was found to be spread over. SOLUTION: With this patch, update-delay post processing is serialized to achieve: a. better peer update packing (which helps in reducing total number of BGP update packets) b. installation of the resulting routes in zebra as close to each others as possible. (which can help zebra batch its processing and updates to Kernel better)
2015-05-20 02:40:42 +02:00
return;
*: Rename quagga_timestamp with frr_timestamp Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-11-11 20:33:41 +01:00
frr_timestamp(3, bgp->update_delay_peers_resume_time,
sizeof(bgp->update_delay_peers_resume_time));
bgpd-scale-update-delay-packing.patch ISSUE: During startup, BGP update prefix packing wasnt optimal and route installation was found to be spread over. SOLUTION: With this patch, update-delay post processing is serialized to achieve: a. better peer update packing (which helps in reducing total number of BGP update packets) b. installation of the resulting routes in zebra as close to each others as possible. (which can help zebra batch its processing and updates to Kernel better)
2015-05-20 02:40:42 +02:00
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
for (ALL_LIST_ELEMENTS(bgp->peer, node, nnode, peer)) {
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
struct peer_connection *connection = peer->connection;
if (!peer_established(connection))
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
continue;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_routeadv);
BGP_TIMER_ON(connection->t_routeadv, bgp_routeadv_timer, 0);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
}
/**
* see bgp_fsm.h
*/
void bgp_adjust_routeadv(struct peer *peer)
{
bgpd: Convert from bgp_clock() to monotime() Let's convert to our actual library call instead of using yet another abstraction that makes it fun for people to switch daemons. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-08-18 00:27:54 +02:00
time_t nowtime = monotime(NULL);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
double diff;
unsigned long remain;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = peer->connection;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Changes to improve BGP convergence time: - Schedule write thread for advertisements and withdraws only if corresponding FIFOs are growing and/or upon work_queue getting fully processed. - Set non-default yield time for the main work_queue, as the default value of 10ms results in yielding after processing very few nodes. - Remove unnecessary scheduling of write thread when update packet is formed. - If MRAI is 0, don't start a timer unnecessarily, directly schedule write thread. - Some debugs.
2015-05-20 02:58:12 +02:00
/* Bypass checks for special case of MRAI being 0 */
if (peer->v_routeadv == 0) {
/* Stop existing timer, just in case it is running for a
* different
* duration and schedule write thread immediately.
*/
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_routeadv);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Convert from bgp_clock() to monotime() Let's convert to our actual library call instead of using yet another abstraction that makes it fun for people to switch daemons. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-08-18 00:27:54 +02:00
peer->synctime = monotime(NULL);
bgpd: Advertise FIB installed routes to bgp peers (Part 3) * Process FIB update in bgp_zebra_route_notify_owner() and call group_announce_route() if route is installed * When bgp update is received for a route which is not installed earlier (flag BGP_NODE_FIB_INSTALLED is not set) and suppress fib is enabled set the flag BGP_NODE_FIB_INSTALL_PENDING to indicate fib install is pending for the route. The route will be advertised when zebra send ZAPI_ROUTE_INSTALLED status. * The advertisement delay (BGP_DEFAULT_UPDATE_ADVERTISEMENT_TIME) is added to allow more routes to be sent in single update message. This is required since zebra sends route notify message for each route. The delay will be applied to update group timer which advertises routes to peers. Signed-off-by: kssoman <somanks@gmail.com>
2020-11-06 04:25:56 +01:00
/* If suppress fib pending is enabled, route is advertised to
* peers when the status is received from the FIB. The delay
* is added to update group packet generate which will allow
* more routes to be sent in the update message
*/
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_UPDATE_GROUP_TIMER_ON(&connection->t_generate_updgrp_packets,
bgpd: Advertise FIB installed routes to bgp peers (Part 3) * Process FIB update in bgp_zebra_route_notify_owner() and call group_announce_route() if route is installed * When bgp update is received for a route which is not installed earlier (flag BGP_NODE_FIB_INSTALLED is not set) and suppress fib is enabled set the flag BGP_NODE_FIB_INSTALL_PENDING to indicate fib install is pending for the route. The route will be advertised when zebra send ZAPI_ROUTE_INSTALLED status. * The advertisement delay (BGP_DEFAULT_UPDATE_ADVERTISEMENT_TIME) is added to allow more routes to be sent in single update message. This is required since zebra sends route notify message for each route. The delay will be applied to update group timer which advertises routes to peers. Signed-off-by: kssoman <somanks@gmail.com>
2020-11-06 04:25:56 +01:00
bgp_generate_updgrp_packets);
Changes to improve BGP convergence time: - Schedule write thread for advertisements and withdraws only if corresponding FIFOs are growing and/or upon work_queue getting fully processed. - Set non-default yield time for the main work_queue, as the default value of 10ms results in yielding after processing very few nodes. - Remove unnecessary scheduling of write thread when update packet is formed. - If MRAI is 0, don't start a timer unnecessarily, directly schedule write thread. - Some debugs.
2015-05-20 02:58:12 +02:00
return;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/*
* CASE I:
* If the last update was written more than MRAI back, expire the timer
* instantly so that we can send the update out sooner.
*
* <------- MRAI --------->
* |-----------------|-----------------------|
* <------------- m ------------>
* ^ ^ ^
* | | |
* | | current time
* | timer start
* last write
*
* m > MRAI
*/
bgpd: 'Last write' does not update when we TX a keepalive Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-5518
2016-10-06 15:20:02 +02:00
diff = difftime(nowtime, peer->last_update);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (diff > (double)peer->v_routeadv) {
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_routeadv);
BGP_TIMER_ON(connection->t_routeadv, bgp_routeadv_timer, 0);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
return;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/*
* CASE II:
* - Find when to expire the MRAI timer.
* If MRAI timer is not active, assume we can start it now.
*
* <------- MRAI --------->
* |------------|-----------------------|
* <-------- m ----------><----- r ----->
* ^ ^ ^
* | | |
* | | current time
* | timer start
* last write
*
* (MRAI - m) < r
*/
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (connection->t_routeadv)
remain = event_timer_remain_second(connection->t_routeadv);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
else
remain = peer->v_routeadv;
diff = peer->v_routeadv - diff;
if (diff <= (double)remain) {
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
EVENT_OFF(connection->t_routeadv);
BGP_TIMER_ON(connection->t_routeadv, bgp_routeadv_timer, diff);
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
static bool bgp_maxmed_onstartup_applicable(struct bgp *bgp)
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
{
if (!bgp->maxmed_onstartup_over)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
bool bgp_maxmed_onstartup_configured(struct bgp *bgp)
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
{
if (bgp->v_maxmed_onstartup != BGP_MAXMED_ONSTARTUP_UNCONFIGURED)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
}
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
bool bgp_maxmed_onstartup_active(struct bgp *bgp)
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
{
if (bgp->t_maxmed_onstartup)
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
return true;
return false;
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
}
void bgp_maxmed_update(struct bgp *bgp)
{
*: use C99 standard fixed-width integer types The following types are nonstandard: - u_char - u_short - u_int - u_long - u_int8_t - u_int16_t - u_int32_t Replace them with the C99 standard types: - uint8_t - unsigned short - unsigned int - unsigned long - uint8_t - uint16_t - uint32_t Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-03-27 21:13:34 +02:00
uint8_t maxmed_active;
uint32_t maxmed_value;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
if (bgp->v_maxmed_admin) {
maxmed_active = 1;
maxmed_value = bgp->maxmed_admin_value;
} else if (bgp->t_maxmed_onstartup) {
maxmed_active = 1;
maxmed_value = bgp->maxmed_onstartup_value;
} else {
maxmed_active = 0;
maxmed_value = BGP_MAXMED_VALUE_DEFAULT;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
if (bgp->maxmed_active != maxmed_active
|| bgp->maxmed_value != maxmed_value) {
bgp->maxmed_active = maxmed_active;
bgp->maxmed_value = maxmed_value;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
update_group_announce(bgp);
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
}
}
bgpd: Add subcodes for BGP Finite State Machine Error Implement https://tools.ietf.org/html/rfc6608 I used python scapy library to send a notification message in OpenSent state: ``` send(IP(dst="192.168.0.1")/TCP(sport=sp, dport=179, seq=rec.ack, ack=rec.seq + 1, flags=0x18)/BGPHeader(type=3)/BGPNotification(error_code=4, error_subcode=0)) ``` Logs from FRR: ``` %NOTIFICATION: sent to neighbor 192.168.0.2 5/1 (Neighbor Events Error/Receive Unexpected Message in OpenSent State) 0 bytes ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-15 13:19:11 +01:00
int bgp_fsm_error_subcode(int status)
{
int fsm_err_subcode = BGP_NOTIFY_FSM_ERR_SUBCODE_UNSPECIFIC;
switch (status) {
case OpenSent:
fsm_err_subcode = BGP_NOTIFY_FSM_ERR_SUBCODE_OPENSENT;
break;
case OpenConfirm:
fsm_err_subcode = BGP_NOTIFY_FSM_ERR_SUBCODE_OPENCONFIRM;
break;
case Established:
fsm_err_subcode = BGP_NOTIFY_FSM_ERR_SUBCODE_ESTABLISHED;
break;
default:
break;
}
return fsm_err_subcode;
}
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
/* The maxmed onstartup timer expiry callback. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_maxmed_onstartup_timer(struct event *thread)
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
{
struct bgp *bgp;
zlog_info("Max med on startup ended - timer expired.");
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
bgp = EVENT_ARG(thread);
EVENT_OFF(bgp->t_maxmed_onstartup);
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
bgp->maxmed_onstartup_over = 1;
bgp_maxmed_update(bgp);
}
static void bgp_maxmed_onstartup_begin(struct bgp *bgp)
{
/* Applicable only once in the process lifetime on the startup */
if (bgp->maxmed_onstartup_over)
return;
zlog_info("Begin maxmed onstartup mode - timer %d seconds",
bgp->v_maxmed_onstartup);
*: Convert thread_add_XXX functions to event_add_XXX Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-20 20:19:08 +02:00
event_add_timer(bm->master, bgp_maxmed_onstartup_timer, bgp,
bgp->v_maxmed_onstartup, &bgp->t_maxmed_onstartup);
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
if (!bgp->v_maxmed_admin) {
bgp->maxmed_active = 1;
bgp->maxmed_value = bgp->maxmed_onstartup_value;
}
/* Route announce to all peers should happen after this in
* bgp_establish() */
}
static void bgp_maxmed_onstartup_process_status_change(struct peer *peer)
{
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
if (peer_established(peer->connection) && !peer->bgp->established) {
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
bgp_maxmed_onstartup_begin(peer->bgp);
}
}
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
/* The update delay timer expiry callback. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_update_delay_timer(struct event *thread)
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
{
struct bgp *bgp;
zlog_info("Update delay ended - timer expired.");
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
bgp = EVENT_ARG(thread);
EVENT_OFF(bgp->t_update_delay);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
bgp_update_delay_end(bgp);
}
/* The establish wait timer expiry callback. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_establish_wait_timer(struct event *thread)
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
{
struct bgp *bgp;
zlog_info("Establish wait - timer expired.");
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
bgp = EVENT_ARG(thread);
EVENT_OFF(bgp->t_establish_wait);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
bgp_check_update_delay(bgp);
}
/* Steps to begin the update delay:
- initialize queues if needed
- stop the queue processing
- start the timer */
static void bgp_update_delay_begin(struct bgp *bgp)
{
struct listnode *node, *nnode;
struct peer *peer;
/* Stop the processing of queued work. Enqueue shall continue */
bgpd: Make the process_queue per bgp process We currently have a global process queue for handling route updates in bgp. This is fine, in general, except there are places and times where we plug the queue for no new work during certain peer states of bgp update delay. If we happen to be processing multiple bgp instances on startup why do we want to stop processing in vrf A when vrf B is in a bit of a pickle? Also this separation will allow us to start forward thinking about how to fully integrate pthreads into route processing in bgp. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-10-17 15:43:14 +02:00
work_queue_plug(bgp->process_queue);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
for (ALL_LIST_ELEMENTS(bgp->peer, node, nnode, peer))
peer->update_delay_over = 0;
/* Start the update-delay timer */
*: Convert thread_add_XXX functions to event_add_XXX Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-20 20:19:08 +02:00
event_add_timer(bm->master, bgp_update_delay_timer, bgp,
bgp->v_update_delay, &bgp->t_update_delay);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
if (bgp->v_establish_wait != bgp->v_update_delay)
*: Convert thread_add_XXX functions to event_add_XXX Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-20 20:19:08 +02:00
event_add_timer(bm->master, bgp_establish_wait_timer, bgp,
bgp->v_establish_wait, &bgp->t_establish_wait);
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
*: Rename quagga_timestamp with frr_timestamp Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-11-11 20:33:41 +01:00
frr_timestamp(3, bgp->update_delay_begin_time,
sizeof(bgp->update_delay_begin_time));
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
}
static void bgp_update_delay_process_status_change(struct peer *peer)
{
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
if (peer_established(peer->connection)) {
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
if (!peer->bgp->established++) {
bgp_update_delay_begin(peer->bgp);
zlog_info(
"Begin read-only mode - update-delay timer %d seconds",
peer->bgp->v_update_delay);
}
bgpd: Rename graceful restart constants for R-bit capabilities Just to better understand what they mean. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-04-27 21:30:29 +02:00
if (CHECK_FLAG(peer->cap, PEER_CAP_GRACEFUL_RESTART_R_BIT_RCV))
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
bgp_update_restarted_peers(peer);
}
bgpd: Convert `struct peer_connection` to dynamically allocated As part of the conversion to a `struct peer_connection` it will be desirable to have 2 pointers one for when we open a connection and one for when we receive a connection. Start this actual conversion over to this in `struct peer`. If this sounds confusing take a look at the bgp state machine for connections and how it resolves the processing of this router opening -vs- this router receiving an open. At some point in time the state machine decides that we are keeping one of the two connections. Future commits will allow us to untangle the peer/doppelganger duality with this abstraction. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 05:43:46 +02:00
if (peer->connection->ostatus == Established &&
bgpd: Move status and ostatus to `struct peer_connection` The status and ostatus are a function of the `struct peer_connection` move it into that data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-06-03 23:13:52 +02:00
bgp_update_delay_active(peer->bgp)) {
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
/* Adjust the update-delay state to account for this flap.
NOTE: Intentionally skipping adjusting implicit_eors or
explicit_eors
counters. Extra sanity check in bgp_check_update_delay()
should
be enough to take care of any additive discrepancy in bgp eor
counters */
peer->bgp->established--;
peer->update_delay_over = 0;
}
}
*: spelchek Signed-off-by: David Lamparter <equinox@diac24.net>
2018-10-25 20:06:59 +02:00
/* Called after event occurred, this function change status and reset
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
read/write and timer thread. */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
void bgp_fsm_change_status(struct peer_connection *connection,
enum bgp_fsm_status status)
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer *peer = connection->peer;
struct bgp *bgp = peer->bgp;
bgpd: Creating Loopback Interface Flaps BGPd (#2865) * The function bgp_router_id_zebra_bump() will check for active bgp peers before chenging the router ID. If there are established peers, router ID is not modified which prevents the flapping of established peer connection * Added field in bgp structure to store the count of established peers Signed-off-by: kssoman <somanks@vmware.com>
2018-11-19 13:35:32 +01:00
uint32_t peer_count;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
bgpd: Creating Loopback Interface Flaps BGPd (#2865) * The function bgp_router_id_zebra_bump() will check for active bgp peers before chenging the router ID. If there are established peers, router ID is not modified which prevents the flapping of established peer connection * Added field in bgp structure to store the count of established peers Signed-off-by: kssoman <somanks@vmware.com>
2018-11-19 13:35:32 +01:00
peer_count = bgp->established_peers;
bgpd: Implement connect retry backoff Instead of starting with a fairly high value of retry, let's try with a lower and increase with a backoff to reach what was a default value (120s). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-05 09:49:52 +01:00
if (status == Established) {
bgpd: Creating Loopback Interface Flaps BGPd (#2865) * The function bgp_router_id_zebra_bump() will check for active bgp peers before chenging the router ID. If there are established peers, router ID is not modified which prevents the flapping of established peer connection * Added field in bgp structure to store the count of established peers Signed-off-by: kssoman <somanks@vmware.com>
2018-11-19 13:35:32 +01:00
bgp->established_peers++;
bgpd: Implement connect retry backoff Instead of starting with a fairly high value of retry, let's try with a lower and increase with a backoff to reach what was a default value (120s). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-05 09:49:52 +01:00
/* Reset the retry timer if we already established */
if (peer->connect)
peer->v_connect = peer->connect;
else
peer->v_connect = peer->bgp->default_connect_retry;
} else if ((peer_established(connection)) && (status != Established))
bgpd: Creating Loopback Interface Flaps BGPd (#2865) * The function bgp_router_id_zebra_bump() will check for active bgp peers before chenging the router ID. If there are established peers, router ID is not modified which prevents the flapping of established peer connection * Added field in bgp structure to store the count of established peers Signed-off-by: kssoman <somanks@vmware.com>
2018-11-19 13:35:32 +01:00
bgp->established_peers--;
bgpd: Update an fsm debug message When debugging I was having a hard time correlating some data and noticed that a particular debug was not being very useful. Signed-off-by: Donald Sharp <sharpd@cumulusnstworks.com>
2019-05-29 00:08:28 +02:00
if (bgp_debug_neighbor_events(peer)) {
struct vrf *vrf = vrf_lookup_by_id(bgp->vrf_id);
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s : vrf %s(%u), Status: %s established_peers %u for %s", __func__,
bgpd: Update an fsm debug message When debugging I was having a hard time correlating some data and noticed that a particular debug was not being very useful. Signed-off-by: Donald Sharp <sharpd@cumulusnstworks.com>
2019-05-29 00:08:28 +02:00
vrf ? vrf->name : "Unknown", bgp->vrf_id,
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
lookup_msg(bgp_status_msg, status, NULL), bgp->established_peers,
bgp_peer_get_connection_direction(connection));
bgpd: Update an fsm debug message When debugging I was having a hard time correlating some data and noticed that a particular debug was not being very useful. Signed-off-by: Donald Sharp <sharpd@cumulusnstworks.com>
2019-05-29 00:08:28 +02:00
}
bgpd: Creating Loopback Interface Flaps BGPd (#2865) * The function bgp_router_id_zebra_bump() will check for active bgp peers before chenging the router ID. If there are established peers, router ID is not modified which prevents the flapping of established peer connection * Added field in bgp structure to store the count of established peers Signed-off-by: kssoman <somanks@vmware.com>
2018-11-19 13:35:32 +01:00
/* Set to router ID to the value provided by RIB if there are no peers
* in the established state and peer count did not change
*/
if ((peer_count != bgp->established_peers) &&
(bgp->established_peers == 0))
bgp_router_id_zebra_bump(bgp->vrf_id, NULL);
[bgpd] Peer delete can race with reconfig leading to crash 2007-02-22 Paul Jakma <paul.jakma@sun.com> * bgp_fsm.c: (bgp_fsm_change_status) Handle state change into clearing or greater here. Simpler. (bgp_event) Clearing state change work moved to previous * bgp_route.c: (bgp_clear_route_node) Clearing adj-in here is too late, as it leaves a race between a peer being deleted and an identical peer being configured before clearing completes, leading to a crash. Simplest fix is to clean peers Adj-in up-front, rather than queueing such work. (bgp_clear_route_table) Clear peer's Adj-In and Adj-Out up-front here, rather than queueing such work. Extensive comment added on the various bits of indexed data that exist and how they need to be dealt with. (bgp_clear_route) Update comment.
2007-02-22 18:48:42 +01:00
/* Transition into Clearing or Deleted must /always/ clear all routes..
* (and must do so before actually changing into Deleted..
*/
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>
2024-06-19 16:19:22 +02:00
if (status >= Clearing && (peer->established || peer == bgp->peer_self)) {
When a peer that is Established goes down, it is moved into the Clearing state to facilitate clearing of the routes received from the peer - remove from the RIB, reselect best path, update/delete from Zebra and to other peers etc. At the end of this, a Clearing_Completed event is generated to the FSM which will allow the peer to move out of Clearing to Idle. The issue in the code is that there is a possibility of multiple Clearing Completed events being generated for a peer, one per AFI/SAFI. Upon the first such event, the peer would move to Idle. If other events happened (e.g., new connection got established) before the last Clearing_Completed event is received, bad things can happen. Fix to ensure only one Clearing_Completed event is generated.
2015-05-20 03:04:12 +02:00
bgp_clear_route_all(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
When a peer that is Established goes down, it is moved into the Clearing state to facilitate clearing of the routes received from the peer - remove from the RIB, reselect best path, update/delete from Zebra and to other peers etc. At the end of this, a Clearing_Completed event is generated to the FSM which will allow the peer to move out of Clearing to Idle. The issue in the code is that there is a possibility of multiple Clearing Completed events being generated for a peer, one per AFI/SAFI. Upon the first such event, the peer would move to Idle. If other events happened (e.g., new connection got established) before the last Clearing_Completed event is received, bad things can happen. Fix to ensure only one Clearing_Completed event is generated.
2015-05-20 03:04:12 +02:00
/* If no route was queued for the clear-node processing,
* generate the
* completion event here. This is needed because if there are no
* routes
* to trigger the background clear-node thread, the event won't
* get
* generated and the peer would be stuck in Clearing. Note that
* this
* event is for the peer and helps the peer transition out of
* Clearing
* state; it should not be generated per (AFI,SAFI). The event
* is
* directly posted here without calling clear_node_complete() as
* we
* shouldn't do an extra unlock. This event will get processed
* after
* the state change that happens below, so peer will be in
* Clearing
* (or Deleted).
*/
bgpd: Fix several use after free's in bgp for the peer Three fixes: a) When calling bgp_fsm_change_status with `Deleted` do not add a new event to the peer's t_event because we are already in the process of deleting everything b) When bgp_stop decides to delete a peer return a notification that it is happening to bgp_event_update so that it does not set the peer state back to idle or do other processing. c) bgp_event_update can cause a peer deletion, because the peer can be deleted in the fsm function but the peer data structure is still pointed to and used after words. So lock the peer before entering and prevent a use after free. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-01 19:12:40 +01:00
if (!work_queue_is_scheduled(peer->clear_node_queue) &&
status != Deleted)
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_EVENT_ADD(connection, Clearing_Completed);
When a peer that is Established goes down, it is moved into the Clearing state to facilitate clearing of the routes received from the peer - remove from the RIB, reselect best path, update/delete from Zebra and to other peers etc. At the end of this, a Clearing_Completed event is generated to the FSM which will allow the peer to move out of Clearing to Idle. The issue in the code is that there is a possibility of multiple Clearing Completed events being generated for a peer, one per AFI/SAFI. Upon the first such event, the peer would move to Idle. If other events happened (e.g., new connection got established) before the last Clearing_Completed event is received, bad things can happen. Fix to ensure only one Clearing_Completed event is generated.
2015-05-20 03:04:12 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
/* Preserve old status and change into new status. */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
connection->ostatus = connection->status;
connection->status = status;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Add `neighbor <neigh> shutdown rtt` command This would be useful in cases with lots of peers and shutdown them automatically if RTT goes above the specified limit. A host with 512 or more IPv6 addresses has a higher latency due to ipv6_addr_label(). This method tries to pick the best candidate address fo outgoing connection and literally increases processing latency. ``` Samples: 28 of event 'cycles', Event count (approx.): 22131542 Children Self Command Shared Object Symbol + 100.00% 0.00% ping6 [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath + 100.00% 0.00% ping6 [unknown] [.] 0x0df0ad0b8047022a + 100.00% 0.00% ping6 libc-2.17.so [.] __sendto_nocancel + 100.00% 0.00% ping6 [kernel.kallsyms] [k] sys_sendto + 100.00% 0.00% ping6 [kernel.kallsyms] [k] SYSC_sendto + 100.00% 0.00% ping6 [kernel.kallsyms] [k] sock_sendmsg + 100.00% 0.00% ping6 [kernel.kallsyms] [k] inet_sendmsg + 100.00% 0.00% ping6 [kernel.kallsyms] [k] rawv6_sendmsg + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ip6_dst_lookup_flow + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ip6_dst_lookup_tail + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ip6_route_get_saddr + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ipv6_dev_get_saddr + 100.00% 0.00% ping6 [kernel.kallsyms] [k] __ipv6_dev_get_saddr + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ipv6_get_saddr_eval + 100.00% 0.00% ping6 [kernel.kallsyms] [k] ipv6_addr_label + 100.00% 100.00% ping6 [kernel.kallsyms] [k] __ipv6_addr_label + 0.00% 0.00% ping6 [kernel.kallsyms] [k] schedule ``` This is how it works: ``` ~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs' 9 ~# tc qdisc add dev eth1 root netem delay 120ms ~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs' 89 ~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".estimatedRttInMsecs' null ~# vtysh -c 'show bgp neigh 192.168.0.2 json' | jq '."192.168.0.2".lastResetDueTo' "Admin. shutdown" ``` Warning message: bgpd[14807]: 192.168.0.2 shutdown due to high round-trip-time (200ms > 150ms) Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-07-25 08:10:56 +02:00
/* Reset received keepalives counter on every FSM change */
peer->rtt_keepalive_rcv = 0;
bgpd: fix invocation of bgpTrapBackwardTransition The bgpTrapBackwardTransition callback was being called only during bgp_stop and only under the condition that peer status was Established. The MIB defines that the event should be generated for every transition of the BGP FSM from a higher to a lower state. Signed-off-by: Babis Chalios <mail@bchalios.io>
2020-08-04 15:19:25 +02:00
/* Fire backward transition hook if that's the case */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (connection->ostatus == Established &&
connection->status != Established)
bgpd: fix invocation of bgpTrapBackwardTransition The bgpTrapBackwardTransition callback was being called only during bgp_stop and only under the condition that peer status was Established. The MIB defines that the event should be generated for every transition of the BGP FSM from a higher to a lower state. Signed-off-by: Babis Chalios <mail@bchalios.io>
2020-08-04 15:19:25 +02:00
hook_call(peer_backward_transition, peer);
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
/* Save event that caused status change. */
peer->last_major_event = peer->cur_event;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: hook for bgp peer status change events Generally available hook for plugging application-specific code in for bgp peer change events. This hook (peer_status_changed) replaces the previous, more specific 'peer_established' hook with a more general-purpose one. Also, 'bgp_dump_state' is now registered under this hook. Signed-off-by: Marton Kun-Szabo <martonk@amazon.com>
2019-08-09 19:53:01 +02:00
/* Operations after status change */
hook_call(peer_status_changed, peer);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (status == Established)
UNSET_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd-maxmed-administrative-onstartup.patch COMMAND: Possible forms of the command configuration: [no] bgp max-med administrative [no] bgp max-med administrative <max-med-value> [no] bgp max-med on-startup <period> [no] bgp max-med on-startup <period> <max-med-value> DESCRIPTION: 'administrative' takes effect from the time of the config until the config is removed. 'on-startup' is effective only at the startup time for the given '<period>' after the first peer is established. '<max-med-value>' is used as the MED value to be sent out when the max-med is effective. Default max-med value is 4294967294. NOTE: When max-med is active, MED is changed only in the outgoing attributes to the peers, it doesn't modify any MED specific state of the attributes in BGP on the local node. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:42 +02:00
/* If max-med processing is applicable, do the necessary. */
if (status == Established) {
if (bgp_maxmed_onstartup_configured(peer->bgp)
&& bgp_maxmed_onstartup_applicable(peer->bgp))
bgp_maxmed_onstartup_process_status_change(peer);
else
peer->bgp->maxmed_onstartup_over = 1;
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-update-delay.patch COMMAND: 'update-delay <max-delay in seconds> [<establish-wait in seconds>]' DESCRIPTION: This feature is used to enable read-only mode on BGP process restart or when BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode would begin as soon as the first peer reaches Established state and a timer for <max-delay> seconds is started. During this mode BGP doesn't run any best-path or generate any updates to its peers. This mode continues until: 1. All the configured peers, except the shutdown peers, have sent explicit EOR (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached Established is considered an implicit-EOR. If the <establish-wait> optional value is given, then BGP will wait for peers to reach establish from the begining of the update-delay till the establish-wait period is over, i.e. the minimum set of established peers for which EOR is expected would be peers established during the establish-wait window, not necessarily all the configured neighbors. 2. max-delay period is over. On hitting any of the above two conditions, BGP resumes the decision process and generates updates to its peers. Default <max-delay> is 0, i.e. the feature is off by default. This feature can be useful in reducing CPU/network used as BGP restarts/clears. Particularly useful in the topologies where BGP learns a prefix from many peers. Intermediate bestpaths are possible for the same prefix as peers get established and start receiving updates at different times. This feature should offer a value-add if the network has a high number of such prefixes. IMPLEMENTATION OBJECTIVES: Given this is an optional feature, minimized the code-churn. Used existing constructs wherever possible (existing queue-plug/unplug were used to achieve delay and resume of best-paths/update-generation). As a result, no new data-structure(s) had to be defined and allocated. When the feature is disabled, the new node is not exercised for the most part. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
/* If update-delay processing is applicable, do the necessary. */
if (bgp_update_delay_configured(peer->bgp)
&& bgp_update_delay_applicable(peer->bgp))
bgp_update_delay_process_status_change(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s fd %d went from %s to %s for %s", peer->host, connection->fd,
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
lookup_msg(bgp_status_msg, connection->ostatus, NULL),
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
lookup_msg(bgp_status_msg, connection->status, NULL),
bgp_peer_get_connection_direction(connection));
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
}
bgpd: fd leak in bgpd * bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new' Clearing state. I've been seeing it from hold timer failures, but it can also be triggered by other things. When Hold_Timer_expired fires in Established state, a notify is sent and BGP_Stop event queued. The fsm then transitions into Clearing state. That is the problem; When the BGP_Stop event is serviced, the state table says to ignore it while in Clearing. Thus bgp_stop is not called and the fd leaks. Previously the peer would be in Idle state, which correctly handles the BGP_Stop event. Fix by making bgp_stop safe to call from Clearing state, without losing ClearingCompleted events, and then ensuring it is called prior to transition from Clearing->Idle.
2009-07-28 18:50:00 +02:00
/* Flush the event queue and ensure the peer is shut down */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_clearing_completed(struct peer_connection *connection)
bgpd: fd leak in bgpd * bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new' Clearing state. I've been seeing it from hold timer failures, but it can also be triggered by other things. When Hold_Timer_expired fires in Established state, a notify is sent and BGP_Stop event queued. The fsm then transitions into Clearing state. That is the problem; When the BGP_Stop event is serviced, the state table says to ignore it while in Clearing. Thus bgp_stop is not called and the fd leaks. Previously the peer would be in Idle state, which correctly handles the BGP_Stop event. Fix by making bgp_stop safe to call from Clearing state, without losing ClearingCompleted events, and then ensuring it is called prior to transition from Clearing->Idle.
2009-07-28 18:50:00 +02:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
enum bgp_fsm_state_progress rc = bgp_stop(connection);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
if (rc >= BGP_FSM_SUCCESS)
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
event_cancel_event_ready(bm->master, connection);
bgpd: fd leak in bgpd * bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new' Clearing state. I've been seeing it from hold timer failures, but it can also be triggered by other things. When Hold_Timer_expired fires in Established state, a notify is sent and BGP_Stop event queued. The fsm then transitions into Clearing state. That is the problem; When the BGP_Stop event is serviced, the state table says to ignore it while in Clearing. Thus bgp_stop is not called and the fd leaks. Previously the peer would be in Idle state, which correctly handles the BGP_Stop event. Fix by making bgp_stop safe to call from Clearing state, without losing ClearingCompleted events, and then ensuring it is called prior to transition from Clearing->Idle.
2009-07-28 18:50:00 +02:00
return rc;
}
Initial revision
2002-12-13 21:15:29 +01:00
/* Administrative BGP peer stop event. */
bgpd: fd leak in bgpd * bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new' Clearing state. I've been seeing it from hold timer failures, but it can also be triggered by other things. When Hold_Timer_expired fires in Established state, a notify is sent and BGP_Stop event queued. The fsm then transitions into Clearing state. That is the problem; When the BGP_Stop event is serviced, the state table says to ignore it while in Clearing. Thus bgp_stop is not called and the fd leaks. Previously the peer would be in Idle state, which correctly handles the BGP_Stop event. Fix by making bgp_stop safe to call from Clearing state, without losing ClearingCompleted events, and then ensuring it is called prior to transition from Clearing->Idle.
2009-07-28 18:50:00 +02:00
/* May be called multiple times for the same peer */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
enum bgp_fsm_state_progress bgp_stop(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
afi_t afi;
safi_t safi;
char orf_name[BUFSIZ];
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
enum bgp_fsm_state_progress ret = BGP_FSM_SUCCESS;
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
struct bgp *bgp = peer->bgp;
struct graceful_restart_info *gr_info = NULL;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
peer->nsf_af_count = 0;
bgpd: Do not delete BGP dynamic peers if graceful restart kicks in ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 *donatas-pc(192.168.10.17) 4 65002 8 12 0 0 0 00:01:35 2 14 N/A ``` Before shutting down 192.168.10.17: ``` ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Last update: Sat Jan 15 21:45:47 2022 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (Older Path) Last update: Sat Jan 15 21:25:19 2022 ``` After 192.168.10.17 is down: ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 donatas-pc(192.168.10.17) 4 65002 5 9 0 0 0 00:00:12 Active 0 N/A ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Community: llgr-stale Last update: Sat Jan 15 21:49:01 2022 Time until Long-lived stale route deleted: 16 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Sat Jan 15 21:25:19 2022 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-15 22:16:15 +01:00
if (peer_dynamic_neighbor_no_nsf(peer) &&
!(CHECK_FLAG(peer->flags, PEER_FLAG_DELETE))) {
2003-08-13 kunihiro <kunihiro@zebra.org> * bgpd/bgp{_fsm.c,_vty.c,d.c,d.h}: Add support for "bgp log-neighbor-changes" command.
2003-08-13 02:32:49 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s (dynamic neighbor) deleted (%s) for %s", __func__,
peer->host, bgp_peer_get_connection_direction(connection));
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
peer_delete(peer);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE_AND_DELETE;
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
}
2003-08-13 kunihiro <kunihiro@zebra.org> * bgpd/bgp{_fsm.c,_vty.c,d.c,d.h}: Add support for "bgp log-neighbor-changes" command.
2003-08-13 02:32:49 +02:00
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* Can't do this in Clearing; events are used for state transitions */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if (connection->status != Clearing) {
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* Delete all existing events of the peer */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
event_cancel_event_ready(bm->master, connection);
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Increment Dropped count. */
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
if (peer_established(connection)) {
Initial revision
2002-12-13 21:15:29 +01:00
peer->dropped++;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Do not try to uninstall BFD session if the peer is not established Having something like: ``` neighbor 192.168.1.222 ebgp-multihop 32 neighbor 192.168.1.222 update-source 192.168.1.5 neighbor 192.168.1.222 bfd ``` Won't work and the result is (empty): ``` $ show bfd peers BFD Peers: ``` bgp_stop() is called in BGP FSM multiple times (even at startup) that causes intermediate session interruption when update-source/ebgp-multihop is triggered. With this fix, the ordering does not matter and the BFD session's parameters are updated correctly. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-11 15:49:22 +01:00
if (peer->bfd_config && (peer->last_reset == PEER_DOWN_UPDATE_SOURCE_CHANGE ||
peer->last_reset == PEER_DOWN_MULTIHOP_CHANGE))
bfd_sess_uninstall(peer->bfd_config->session);
bgpd: Notify BGP conditional advertisement thread when the peer goes down Also, make sure we check if the advertisement table changed using FROM peer, not TO peer. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-10-20 10:21:51 +02:00
/* Notify BGP conditional advertisement process */
peer->advmap_table_change = true;
2003-08-13 kunihiro <kunihiro@zebra.org> * bgpd/bgp{_fsm.c,_vty.c,d.c,d.h}: Add support for "bgp log-neighbor-changes" command.
2003-08-13 02:32:49 +02:00
/* bgp log-neighbor-changes of neighbor Down */
bgpd: Replace bgp_flag_* to [UN]SET/CHECK_FLAG macros Most of the code uses macros, thus let's keep the code unified. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-06 15:37:20 +01:00
if (CHECK_FLAG(peer->bgp->flags,
BGP_FLAG_LOG_NEIGHBOR_CHANGES)) {
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
struct vrf *vrf = vrf_lookup_by_id(peer->bgp->vrf_id);
bgpd: Adding BGP GR Per Neighbor show commands. * Added new show command to show the graceful restart information for each neighbor. Cmd: show bgp [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|WORD>] graceful-restart * Changes to show neighbors commands for displaying graceful restart information. Cmd :show [ip] bgp [<view|vrf> VIEWVRFNAME] [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X| Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 12:02:48 +02:00
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
zlog_info(
bgpd: Add `%pBP` printfrr() extension to print `IP(hostname)` for BGP peer Replace existing bgp_peer_hostname() function. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-31 14:59:06 +02:00
"%%ADJCHANGE: neighbor %pBP in vrf %s Down %s",
peer,
bgpd: make name of default vrf/bgp instance consistent Problems were reported with the name of the default vrf and the default bgp instance being different, creating confusion. This fix changes both to "default" for consistency. Ticket: CM-21791 Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: CCR-7658 Testing: manual testing and automated tests before pushing
2018-07-20 17:02:15 +02:00
vrf ? ((vrf->vrf_id != VRF_DEFAULT)
bgpd: Print hostname along with IP for most useful debug messages Examples: ``` %ADJCHANGE: neighbor 192.168.0.1(exit1-debian-11) in vrf default Up 192.168.0.1(exit1-debian-11) graceful restart stalepath timer expired 192.168.0.1(exit1-debian-11) sending route-refresh (BoRR) for IPv4/unicast 192.168.0.1(exit1-debian-11) graceful restart timer started for 120 sec 192.168.0.1(exit1-debian-11) graceful restart stalepath timer started for 120 sec 192.168.0.1(exit1-debian-11) graceful restart timer stopped %MAXPFXEXCEED: No. of IPv4 Unicast prefix received from 192.168.0.1(exit1-debian-11) 9 exceed, limit 1 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-22 20:45:47 +01:00
? vrf->name
: VRF_DEFAULT_NAME)
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
: "",
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
peer_down_str[(int)peer->last_reset]);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* graceful restart */
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
if (connection->t_gr_stale) {
EVENT_OFF(connection->t_gr_stale);
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP graceful restart stalepath timer stopped for %s",
peer, bgp_peer_get_connection_direction(connection));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
if (CHECK_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT)) {
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer)) {
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP graceful restart timer started for %d sec for %s",
peer, peer->v_gr_restart,
bgp_peer_get_connection_direction(connection));
zlog_debug("%pBP graceful restart stalepath timer started for %d sec for %s",
peer, peer->bgp->stalepath_time,
bgp_peer_get_connection_direction(connection));
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
BGP_TIMER_ON(connection->t_gr_restart,
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
bgp_graceful_restart_timer_expire,
peer->v_gr_restart);
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
BGP_TIMER_ON(connection->t_gr_stale,
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
bgp_graceful_stale_timer_expire,
peer->bgp->stalepath_time);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
} else {
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_MODE);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
FOREACH_AFI_SAFI_NSF (afi, safi)
peer->nsf[afi][safi] = 0;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: Implement enhanced route refresh capability 16:40:49 BGP: 192.168.0.2: sending route-refresh (BoRR) for IPv4/unicast 16:40:51 BGP: 192.168.0.2: sending route-refresh (EoRR) for IPv4/unicast Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-10-01 22:08:06 +02:00
/* Stop route-refresh stalepath timer */
if (peer->t_refresh_stalepath) {
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(peer->t_refresh_stalepath);
bgpd: Implement enhanced route refresh capability 16:40:49 BGP: 192.168.0.2: sending route-refresh (BoRR) for IPv4/unicast 16:40:51 BGP: 192.168.0.2: sending route-refresh (EoRR) for IPv4/unicast Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-10-01 22:08:06 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP route-refresh restart stalepath timer stopped for %s",
peer, bgp_peer_get_connection_direction(connection));
bgpd: Implement enhanced route refresh capability 16:40:49 BGP: 192.168.0.2: sending route-refresh (BoRR) for IPv4/unicast 16:40:51 BGP: 192.168.0.2: sending route-refresh (EoRR) for IPv4/unicast Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-10-01 22:08:06 +02:00
}
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
/* If peer reset before receiving EOR, decrement EOR count and
* cancel the selection deferral timer if there are no
* pending EOR messages to be received
*/
if (BGP_PEER_GRACEFUL_RESTART_CAPABLE(peer)) {
FOREACH_AFI_SAFI (afi, safi) {
bgpd: Cleanup some bad formating Some recent commits got some bad formating. Clean this up. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-01-31 15:19:24 +01:00
if (!peer->afc_nego[afi][safi]
|| CHECK_FLAG(peer->af_sflags[afi][safi],
PEER_STATUS_EOR_RECEIVED))
continue;
gr_info = &bgp->gr_info[afi][safi];
if (!gr_info)
continue;
if (gr_info->eor_required)
gr_info->eor_required--;
if (BGP_DEBUG(update, UPDATE_OUT))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("peer %s, EOR_required %d for %s", peer->host,
gr_info->eor_required,
bgp_peer_get_connection_direction(connection));
bgpd: Cleanup some bad formating Some recent commits got some bad formating. Clean this up. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-01-31 15:19:24 +01:00
/* There is no pending EOR message */
if (gr_info->eor_required == 0) {
bgpd: Cleanup memory leaks associated with t_deferral_timer We are allocating temporary memory for information about what to process in this thread, which is not being cleaned up on thread cancelling. Signed-off-by: Samanvitha B Bhargav <bsmanvitha@vmware.com>
2022-09-21 12:18:06 +02:00
if (gr_info->t_select_deferral) {
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
void *info = EVENT_ARG(
bgpd: Cleanup memory leaks associated with t_deferral_timer We are allocating temporary memory for information about what to process in this thread, which is not being cleaned up on thread cancelling. Signed-off-by: Samanvitha B Bhargav <bsmanvitha@vmware.com>
2022-09-21 12:18:06 +02:00
gr_info->t_select_deferral);
XFREE(MTYPE_TMP, info);
}
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(gr_info->t_select_deferral);
bgpd: Cleanup some bad formating Some recent commits got some bad formating. Clean this up. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-01-31 15:19:24 +01:00
gr_info->eor_received = 0;
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
}
}
2003-08-13 kunihiro <kunihiro@zebra.org> * bgpd/bgp{_fsm.c,_vty.c,d.c,d.h}: Add support for "bgp log-neighbor-changes" command.
2003-08-13 02:32:49 +02:00
/* set last reset time */
bgpd: Convert from bgp_clock() to monotime() Let's convert to our actual library call instead of using yet another abstraction that makes it fun for people to switch daemons. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-08-18 00:27:54 +02:00
peer->resettime = peer->uptime = monotime(NULL);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
if (BGP_DEBUG(update_groups, UPDATE_GROUPS))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s remove from all update group for %s", peer->host,
bgp_peer_get_connection_direction(connection));
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
update_group_remove_peer_afs(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* bgp_nexthop.c: Improve debug. * bgpd.[ch], bgp_nexthop.c, bgp_snmp.c: Remove useless bgp_get_master() function. * bgp_packet.c: MP AFI_IP update and withdraw parsing. * bgp_fsm.c: Reset peer synctime in bgp_stop(). bgp_fsm_change_status() is better place to log about peer status change than bgp_event(). Log in bgp_connect_success(). * bgp_vty.c: Fix typo in comment. * bgp_attr.c: Better log about unknown attribute. [merge from GNU Zebra]
2005-02-01 21:13:16 +01:00
/* Reset peer synctime */
peer->synctime = 0;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
/* stop keepalives */
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_off(connection);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
/* Stop read and write threads. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_writes_off(connection);
bgp_reads_off(connection);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
bgpd: t_connect_check_r and w move to peer connection These two event pointers belong in the peer_connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:39:35 +02:00
EVENT_OFF(connection->t_connect_check_r);
EVENT_OFF(connection->t_connect_check_w);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Fix wrong pthread event cancelling 0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 1 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 2 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 3 0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 4 0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258 5 <signal handler called> 6 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 7 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 8 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 9 0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79 11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470 14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355 15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610 16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152 17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639 18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111 19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252 20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214 21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180 22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) f 12 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 1428 assert(m->owner == pthread_self()); In this decode the attempt to cancel the connection's events from the wrong thread is causing the crash. Modify the code to create an event on the bm->master to cancel the events for the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-10-24 23:44:31 +02:00
EVENT_OFF(connection->t_stop_with_notify);
bgpd: graceful restart for vpnv4 address family This patch enable the support of graceful restart for routes sets with vpnv4 address family format. In this specific case, data model is slightly different and some additional processing must be done when accessing bgp tables and nodes. The clearing stale algorithm takes into account the specificity where the 2 node level for MPLS has to be reached. Signed-off-by: Julien Courtat <julien.courtat@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2016-05-25 17:28:31 +02:00
/* Stop all timers. */
bgpd: move t_start into peer_connection The t_start event pointer belongs on the peer_connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:28:39 +02:00
EVENT_OFF(connection->t_start);
bgpd: t_connect conversion from peer to peer_connect Move t_connect into struct peer_connect Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:13:56 +02:00
EVENT_OFF(connection->t_connect);
bgpd: t_holdtime move to peer_connection The t_holdtime event pointer belongs in the peer connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:36:34 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: move t_routeadv to peer_connection The t_routeadv belongs to the peer_connection data structure Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:44:23 +02:00
EVENT_OFF(connection->t_routeadv);
bgpd: Pass a connection struct directly for EVENT_OFF() Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-07-24 14:30:43 +02:00
EVENT_OFF(connection->t_delayopen);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Clear input and output buffer. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
frr_with_mutex (&connection->io_mtx) {
if (connection->ibuf)
stream_fifo_clean(connection->ibuf);
if (connection->obuf)
stream_fifo_clean(connection->obuf);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if (connection->ibuf_work)
ringbuf_wipe(connection->ibuf_work);
bgpd: implement buffered reads * Move and modify all network input related code to bgp_io.c * Add a real input buffer to `struct peer` * Move connection initialization to its own thread.c task instead of piggybacking off of bgp_read() * Tons of little fixups Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch]. Changes made elsewhere are almost exclusively refactoring peer->ibuf to peer->curr since peer->ibuf is now the true FIFO packet input buffer while peer->curr represents the packet currently being processed by the main pthread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-05-02 02:37:45 +02:00
if (peer->curr) {
stream_free(peer->curr);
peer->curr = NULL;
}
bgpd: move packet writes into dedicated pthread * BGP_WRITE_ON() removed * BGP_WRITE_OFF() removed * peer_writes_on() added * peer_writes_off() added * bgp_write_proceed_actions() removed Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-02-07 00:39:06 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* Close of file descriptor. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if (connection->fd >= 0) {
close(connection->fd);
connection->fd = -1;
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
connection->dir = UNKNOWN;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
bgpd: Clear capabilities field when resetting a bgp neighbor Currently, the following sequence of events between peers could result in erroneous capability reports on the peer with enabled dont-capability-negotiate option: - having some of the capabilities advertised to a bgp neighbor, - then disabling capability negotiation to that neighbor, - then resetting connection to it, - and no capabilities are actually sent to the neighbor, - but "show bgp neighbors" on the host still displays them as advertised to the neighbor. There are two possibilities for establishing a new connection - the established connection was initiated by us with bgp_start(), - the connection was initiated on the neighbor side and processed by us via bgp_accept() in bgp_network.c. The former case results in "show bgp neighbors" displaying only "received" in capabilities, as the peer's cap is initiated to zero in bgp_start(). In the latter case, if bgp_accept() happens before bgp_start() is called, then new peer capabilities are being transferred from its previous record before being zeroed in bgp_start(). This results in "show bgp neighbors" still displaying "advertised and received" in capabilities. Following the logic of a similar af_cap field clearing, treated correctly in both cases, we - reset peer's capability during bgp_stop() - don't pass it over to a new peer structure in bgp_accept(). This fix prevents transferring of the previous capabilities record to a new peer instance in arbitrary reconnect scenario. Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
2021-07-14 22:43:37 +02:00
/* Reset capabilities. */
peer->cap = 0;
bgpd: Add RFC9234 implementation RFC9234 is a way to establish correct connection roles (Customer/ Provider, Peer or with RS) between bgp speakers. This patch: - Add a new configuration/terminal option to set the appropriate local role; - Add a mechanism for checking used roles, implemented by exchanging the corresponding capabilities in OPEN messages; - Add strict mode to force other party to use this feature; - Add basic support for a new transitive optional bgp attribute - OTC (Only to Customer); - Add logic for default setting OTC attribute and filtering routes with this attribute by the edge speakers, if the appropriate conditions are met; - Add two test stands to check role negotiation and route filtering during role usage. Signed-off-by: Eugene Bogomazov <eb@qrator.net>
2022-06-17 12:14:46 +02:00
/* Resetting neighbor role to the default value */
bgpd: Add patches for RFC9234 implementation This commit fixes some issues that were noted by the reviewer Signed-off-by: Eugene Bogomazov <eb@qrator.net>
2022-06-20 14:39:03 +02:00
peer->remote_role = ROLE_UNDEFINED;
bgpd: Add RFC9234 implementation RFC9234 is a way to establish correct connection roles (Customer/ Provider, Peer or with RS) between bgp speakers. This patch: - Add a new configuration/terminal option to set the appropriate local role; - Add a mechanism for checking used roles, implemented by exchanging the corresponding capabilities in OPEN messages; - Add strict mode to force other party to use this feature; - Add basic support for a new transitive optional bgp attribute - OTC (Only to Customer); - Add logic for default setting OTC attribute and filtering routes with this attribute by the edge speakers, if the appropriate conditions are met; - Add two test stands to check role negotiation and route filtering during role usage. Signed-off-by: Eugene Bogomazov <eb@qrator.net>
2022-06-17 12:14:46 +02:00
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
FOREACH_AFI_SAFI (afi, safi) {
/* Reset all negotiated variables */
peer->afc_nego[afi][safi] = 0;
peer->afc_adv[afi][safi] = 0;
peer->afc_recv[afi][safi] = 0;
/* peer address family capability flags*/
peer->af_cap[afi][safi] = 0;
/* peer address family status flags*/
peer->af_sflags[afi][safi] = 0;
/* Received ORF prefix-filter */
peer->orf_plist[afi][safi] = NULL;
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if ((connection->status == OpenConfirm) ||
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
peer_established(connection)) {
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
/* ORF received prefix-filter pnt */
*: manually remove some more sprintf Take care of some more complicated cases by hand Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-04-20 23:59:31 +02:00
snprintf(orf_name, sizeof(orf_name), "%s.%d.%d",
peer->host, afi, safi);
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
prefix_bgp_orf_remove_all(afi, orf_name);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Merge graceful restart capability display and some small fixes from Zebra repository by Rivo Nurges.
2004-05-21 11:31:30 +02:00
/* Reset keepalive and holdtime */
bgpd: Implement group-overrides for peer timers This commit implements BGP peer-group overrides for the timer flags, which control the value of the hold, keepalive, advertisement-interval and connect connect timers. It was kept separated on purpose as the whole timer implementation is quite complex and merging this commit together with with the other flag implementations did not seem right. Basically three new peer flags were introduced, namely *PEER_FLAG_ROUTEADV*, *PEER_FLAG_TIMER* and *PEER_FLAG_TIMER_CONNECT*. The overrides work exactly the same way as they did before, but introducing these flags made a few conditionals simpler as they no longer had to compare internal data structures against eachother. Last but not least, the test suite has been adjusted accordingly to test the newly implemented flag overrides. Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-06-13 02:34:43 +02:00
if (CHECK_FLAG(peer->flags, PEER_FLAG_TIMER)) {
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
peer->v_keepalive = peer->keepalive;
peer->v_holdtime = peer->holdtime;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
} else {
lib: straighten out ORF prefix list support BGP ORF prefix lists are in a separate namespace; this was previously hooked up with a special-purpose AFI value. This is a little kludgy for extension, hence this splits it off. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2015-04-13 10:21:35 +02:00
peer->v_keepalive = peer->bgp->default_keepalive;
peer->v_holdtime = peer->bgp->default_holdtime;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* Reset DelayOpenTime */
if (CHECK_FLAG(peer->flags, PEER_FLAG_TIMER_DELAYOPEN))
peer->v_delayopen = peer->delayopen;
else
peer->v_delayopen = peer->bgp->default_delayopen;
Initial revision
2002-12-13 21:15:29 +01:00
peer->update_time = 0;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (!CHECK_FLAG(peer->flags, PEER_FLAG_CONFIG_NODE)
&& !(CHECK_FLAG(peer->flags, PEER_FLAG_DELETE))) {
peer_delete(peer);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
ret = BGP_FSM_FAILURE_AND_DELETE;
'neighbor <if-name> interface' config support in BGP including RA/Zebra changes. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:40 +02:00
} else {
bgpd: Move the peer->su to connection->su The sockunion is per connection. So let's move it over. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-08 18:02:05 +02:00
bgp_peer_conf_if_to_su_update(connection);
'neighbor <if-name> interface' config support in BGP including RA/Zebra changes. Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:40 +02:00
}
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
return ret;
Initial revision
2002-12-13 21:15:29 +01:00
}
/* BGP peer is stoped by the error. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_stop_with_error(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
Initial revision
2002-12-13 21:15:29 +01:00
/* Double start timer. */
peer->v_start *= 2;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Overflow check. */
if (peer->v_start >= (60 * 2))
peer->v_start = (60 * 2);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Do not delete BGP dynamic peers if graceful restart kicks in ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 *donatas-pc(192.168.10.17) 4 65002 8 12 0 0 0 00:01:35 2 14 N/A ``` Before shutting down 192.168.10.17: ``` ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Last update: Sat Jan 15 21:45:47 2022 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (Older Path) Last update: Sat Jan 15 21:25:19 2022 ``` After 192.168.10.17 is down: ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 donatas-pc(192.168.10.17) 4 65002 5 9 0 0 0 00:00:12 Active 0 N/A ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Community: llgr-stale Last update: Sat Jan 15 21:49:01 2022 Time until Long-lived stale route deleted: 16 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Sat Jan 15 21:25:19 2022 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-15 22:16:15 +01:00
if (peer_dynamic_neighbor_no_nsf(peer)) {
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s (dynamic neighbor) deleted (%s) for %s", __func__,
peer->host, bgp_peer_get_connection_direction(connection));
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
peer_delete(peer);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
return bgp_stop(connection);
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
/* something went wrong, send notify and tear down */
bgpd: Send "Send Hold Timer Expired" on such events notification This is required by the current (latest/-02 draft). IANA has registered code 8 for "Send Hold Timer Expired" in the "BGP Error (Notification) Codes" sub-registry under the "Border Gateway Protocol (BGP) Parameters" registry. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-sendholdtimer Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-29 14:37:53 +01:00
enum bgp_fsm_state_progress
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
bgp_stop_with_notify(struct peer_connection *connection, uint8_t code,
uint8_t sub_code)
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
{
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
struct peer *peer = connection->peer;
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
/* Send notify to remote peer */
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
bgp_notify_send(connection, code, sub_code);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Do not delete BGP dynamic peers if graceful restart kicks in ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 *donatas-pc(192.168.10.17) 4 65002 8 12 0 0 0 00:01:35 2 14 N/A ``` Before shutting down 192.168.10.17: ``` ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Last update: Sat Jan 15 21:45:47 2022 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (Older Path) Last update: Sat Jan 15 21:25:19 2022 ``` After 192.168.10.17 is down: ``` ~# vtysh -c 'show bgp ipv4 unicast summary' | grep 192.168.10.17 donatas-pc(192.168.10.17) 4 65002 5 9 0 0 0 00:00:12 Active 0 N/A ~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32' BGP routing table entry for 100.100.100.100/32, version 7 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: home-spine1.donatas.net(192.168.0.2) 65002, (stale) 192.168.10.17 from donatas-pc(192.168.10.17) (0.0.0.0) Origin incomplete, valid, external Community: llgr-stale Last update: Sat Jan 15 21:49:01 2022 Time until Long-lived stale route deleted: 16 65001 192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (2.2.2.2) Origin incomplete, metric 0, valid, external, best (First path received) Last update: Sat Jan 15 21:25:19 2022 ``` Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-15 22:16:15 +01:00
if (peer_dynamic_neighbor_no_nsf(peer)) {
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s (dynamic neighbor) deleted (%s) for %s", __func__,
peer->host, bgp_peer_get_connection_direction(connection));
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
peer_delete(peer);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
}
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
/* Clear start timer value to default. */
peer->v_start = BGP_INIT_START_TIMER;
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
return bgp_stop(connection);
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
}
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
/**
* Determines whether a TCP session has successfully established for a peer and
* events as appropriate.
*
* This function is called when setting up a new session. After connect() is
bgpd: fix bgp active open At some point when rearranging FSM code, bgpd lost the ability to perform active opens because it was only paying attention to POLLIN and not POLLOUT, when the latter is used to signify a successful connection in the active case. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-25 04:18:15 +02:00
* called on the peer's socket (in bgp_start()), the fd is passed to poll()
* to wait for connection success or failure. When poll() returns, this
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
* function is called to evaluate the result.
bgpd: fix bgp active open At some point when rearranging FSM code, bgpd lost the ability to perform active opens because it was only paying attention to POLLIN and not POLLOUT, when the latter is used to signify a successful connection in the active case. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-25 04:18:15 +02:00
*
* Due to differences in behavior of poll() on Linux and BSD - specifically,
* the value of .revents in the case of a closed connection - this function is
* scheduled both for a read and a write event. The write event is triggered
* when the connection is established. A read event is triggered when the
* connection is closed. Thus we need to cancel whichever one did not occur.
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
*/
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
static void bgp_connect_check(struct event *thread)
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
{
int status;
socklen_t slen;
int ret;
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
struct peer *peer = connection->peer;
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
assert(!CHECK_FLAG(connection->thread_flags, PEER_THREAD_READS_ON));
assert(!CHECK_FLAG(connection->thread_flags, PEER_THREAD_WRITES_ON));
assert(!connection->t_read);
assert(!connection->t_write);
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
EVENT_OFF(connection->t_connect_check_r);
EVENT_OFF(connection->t_connect_check_w);
bgpd: correctly schedule select() at session startup On TCP connection failure during session setup, bgp_stop() checks whether peer->t_read is non-null to know whether or not to unschedule select() on peer->fd before calling close() on it. Using the API exposed by thread.c instead of bgpd's wrapper macro BGP_READ_ON() results in this thread value never being set, which causes bgp_stop() to skip the cancellation of select() before calling close(). Subsequent calls to select() on that fd crash the daemon. Use the macro instead. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-04-07 01:45:57 +02:00
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
/* Check file descriptor. */
slen = sizeof(status);
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
ret = getsockopt(connection->fd, SOL_SOCKET, SO_ERROR, (void *)&status,
&slen);
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
/* If getsockopt is fail, this is fatal error. */
if (ret < 0) {
BGP: Rectifying the log messages. This change addresses the following: 1) Ensures logs under DEBUG macro checks are categorized as zlog_debug instead of zlog_info. 2) Error logs are categorized as zlog_err instead of zlog_info. 3) Rephrasing certain logs to make them appear more intuitive. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2019-08-21 05:16:20 +02:00
zlog_err("can't get sockopt for nonblocking connect: %d(%s)",
bgpd: Cleanup messages from getsockopt The handling of the return codes for getsockopt was slightly wrong. getsockopt returns -1 on error and errno is set. What to do with the return code at that point is dependent on what sockopt you are asking about. In this case status holds the error returned for SO_ERROR. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-05-11 13:34:24 +02:00
errno, safe_strerror(errno));
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
BGP_EVENT_ADD(connection, TCP_fatal_error);
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
return;
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
}
/* When status is 0 then TCP connection is established. */
if (status == 0) {
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
if (CHECK_FLAG(peer->flags, PEER_FLAG_TIMER_DELAYOPEN))
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
BGP_EVENT_ADD(connection,
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
TCP_connection_open_w_delay);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
else
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
BGP_EVENT_ADD(connection, TCP_connection_open);
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
return;
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
} else {
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [Event] Connect failed %d(%s) for connection %s", peer->host,
status, safe_strerror(status),
bgp_peer_get_connection_direction(connection));
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
BGP_EVENT_ADD(connection, TCP_connection_open_failed);
*: Change thread->func to return void instead of int The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-02-23 01:04:25 +01:00
return;
bgpd: move bgp_connect_check() to bgp_fsm.c Prior to this change, after initiating a nonblocking connection to the remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the peer's socket. This resulted in a call to select(), so that when some event (either a connection success or failure) occurred on the socket, one of bgp_read() or bgp_write() would run. At the beginning of each of those functions was a hook into bgp_connect_check(), which checked the socket status and issued the correct connection event onto the BGP FSM. This code is better suited for bgp_fsm.c. Placing it there avoids scheduling packet reads or writes when we don't know if the socket has established a connection yet, and the specific functionality is a better fit for the responsibility scope of this unit. This change also helps isolate the responsibilities of the packet-writing kernel thread. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-03-24 20:05:56 +01:00
}
}
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* TCP connection open. Next we send open message to remote peer. And
add read thread for reading open message. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_connect_success(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
if (connection->fd < 0) {
bgpd: changes for code maintainability these changes are for improving the code maintainability Signed-off-by: sri-mohan1 <sri.mohan@samsung.com>
2022-09-01 20:55:16 +02:00
flog_err(EC_BGP_CONNECT, "%s peer's fd is negative value %d",
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
__func__, connection->fd);
return bgp_stop(connection);
Initial revision
2002-12-13 21:15:29 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
if (bgp_getsockname(connection) < 0) {
*: LIB_[ERR|WARN] -> EC_LIB Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 21:34:28 +02:00
flog_err_sys(EC_LIB_SOCKET,
*: rename ferr_zlog -> flog_err_sys Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-08-06 18:36:50 +02:00
"%s: bgp_getsockname(): failed for peer %s, fd %d",
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
__func__, peer->host, connection->fd);
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
bgp_notify_send(connection, BGP_NOTIFY_FSM_ERR,
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_fsm_error_subcode(connection->status));
bgp_writes_on(connection);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Allow nht to work when connection succeeds Originally commit: 8761cd6ddb5437767625f58c8e9cc3ccda7887ab implemented the ability for LL nexthop tracking to be interface based. During some more testing the code to make the interface event happen was noticed to not properly run in some cases. This was because it was originally assumed that the connect could not succeed. Testing has shown that the connect can succeed and FRR needs to handle the nht tracking in this case too. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-18 20:29:16 +02:00
/*
* If we are doing nht for a peer that ls v6 LL based
* massage the event system to make things happy
*/
bgp_nht_interface_events(peer);
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_reads_on(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer)) {
* bgp_nexthop.c: Improve debug. * bgpd.[ch], bgp_nexthop.c, bgp_snmp.c: Remove useless bgp_get_master() function. * bgp_packet.c: MP AFI_IP update and withdraw parsing. * bgp_fsm.c: Reset peer synctime in bgp_stop(). bgp_fsm_change_status() is better place to log about peer status change than bgp_event(). Log in bgp_connect_success(). * bgp_vty.c: Fix typo in comment. * bgp_attr.c: Better log about unknown attribute. [merge from GNU Zebra]
2005-02-01 21:13:16 +01:00
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s open active, local address %pSU for %s", peer->host,
connection->su_local,
bgp_peer_get_connection_direction(connection));
* bgp_nexthop.c: Improve debug. * bgpd.[ch], bgp_nexthop.c, bgp_snmp.c: Remove useless bgp_get_master() function. * bgp_packet.c: MP AFI_IP update and withdraw parsing. * bgp_fsm.c: Reset peer synctime in bgp_stop(). bgp_fsm_change_status() is better place to log about peer status change than bgp_event(). Log in bgp_connect_success(). * bgp_vty.c: Fix typo in comment. * bgp_attr.c: Better log about unknown attribute. [merge from GNU Zebra]
2005-02-01 21:13:16 +01:00
else
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s passive open for %s", peer->host,
bgp_peer_get_connection_direction(connection));
* bgp_nexthop.c: Improve debug. * bgpd.[ch], bgp_nexthop.c, bgp_snmp.c: Remove useless bgp_get_master() function. * bgp_packet.c: MP AFI_IP update and withdraw parsing. * bgp_fsm.c: Reset peer synctime in bgp_stop(). bgp_fsm_change_status() is better place to log about peer status change than bgp_event(). Log in bgp_connect_success(). * bgp_vty.c: Fix typo in comment. * bgp_attr.c: Better log about unknown attribute. [merge from GNU Zebra]
2005-02-01 21:13:16 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* Send an open message */
bgpd: bgp_open_send is connection oriented not peer oriented The bgp_open_send function should use a connection oriented pointer for it's basis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:31:54 +02:00
bgp_open_send(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* TCP connection open with RFC 4271 optional session attribute DelayOpen flag
* set.
*/
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
static enum bgp_fsm_state_progress
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_connect_success_w_delayopen(struct peer_connection *connection)
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
if (connection->fd < 0) {
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
flog_err(EC_BGP_CONNECT, "%s: peer's fd is negative value %d",
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
__func__, connection->fd);
return bgp_stop(connection);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
}
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
if (bgp_getsockname(connection) < 0) {
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
flog_err_sys(EC_LIB_SOCKET,
"%s: bgp_getsockname(): failed for peer %s, fd %d",
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
__func__, peer->host, connection->fd);
bgpd: bgp_getsockname should use connection Let's use the connection associated with the peer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:31:19 +01:00
bgp_notify_send(connection, BGP_NOTIFY_FSM_ERR,
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_fsm_error_subcode(connection->status));
bgp_writes_on(connection);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
}
bgpd: Allow nht to work when connection succeeds Originally commit: 8761cd6ddb5437767625f58c8e9cc3ccda7887ab implemented the ability for LL nexthop tracking to be interface based. During some more testing the code to make the interface event happen was noticed to not properly run in some cases. This was because it was originally assumed that the connect could not succeed. Testing has shown that the connect can succeed and FRR needs to handle the nht tracking in this case too. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-18 20:29:16 +02:00
/*
* If we are doing nht for a peer that ls v6 LL based
* massage the event system to make things happy
*/
bgp_nht_interface_events(peer);
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_reads_on(connection);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
if (bgp_debug_neighbor_events(peer)) {
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s open active, local address %pSU for %s", peer->host,
connection->su_local,
bgp_peer_get_connection_direction(connection));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
else
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s passive open for %s", peer->host,
bgp_peer_get_connection_direction(connection));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
}
/* set the DelayOpenTime to the inital value */
peer->v_delayopen = peer->delayopen;
/* Start the DelayOpenTimer if it is not already running */
bgpd: move t_delayopen from peer to peer_connection This belongs in peer_connection let's move it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:24:00 +02:00
if (!peer->connection->t_delayopen)
BGP_TIMER_ON(peer->connection->t_delayopen, bgp_delayopen_timer,
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
peer->v_delayopen);
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] BGP OPEN message delayed for %d seconds for connection %s",
peer->host, peer->delayopen,
bgp_peer_get_connection_direction(connection));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
/* TCP connect fail */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_connect_fail(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: fix dynamic peer graceful restart race condition bgp_llgr topotest sometimes fails at step 8: > topo: STEP 8: 'Check if we can see 172.16.1.2/32 after R4 (dynamic peer) was killed' R4 neighbor is deleted on R2 because it fails to re-connect: > 14:33:40.128048 BGP: [HKWM3-ZC5QP] 192.168.3.1 fd -1 went from Established to Clearing > 14:33:40.128154 BGP: [MJ1TJ-HEE3V] 192.168.3.1(r4) graceful restart timer expired > 14:33:40.128158 BGP: [ZTA2J-YRKGY] 192.168.3.1(r4) graceful restart stalepath timer stopped > 14:33:40.128162 BGP: [H917J-25EWN] 192.168.3.1(r4) Long-lived stale timer (IPv4 Unicast) started for 20 sec > 14:33:40.128168 BGP: [H5X66-NXP9S] 192.168.3.1(r4) Long-lived set stale community (LLGR_STALE) for: 172.16.1.2/32 > 14:33:40.128220 BGP: [H5X66-NXP9S] 192.168.3.1(r4) Long-lived set stale community (LLGR_STALE) for: 192.168.3.0/24 > [...] > 14:33:41.138869 BGP: [RGGAC-RJ6WG] 192.168.3.1 [Event] Connect failed 111(Connection refused) > 14:33:41.138906 BGP: [ZWCSR-M7FG9] 192.168.3.1 [FSM] TCP_connection_open_failed (Connect->Active), fd 23 > 14:33:41.138912 BGP: [JA9RP-HSD1K] 192.168.3.1 (dynamic neighbor) deleted (bgp_connect_fail) > 14:33:41.139126 BGP: [P98A2-2RDFE] 192.168.3.1(r4) graceful restart stalepath timer stopped af8496af08 ("bgpd: Do not delete BGP dynamic peers if graceful restart kicks in") forgot to modify bgp_connect_fail() Do not delete the peer in bgp_connect_fail() if Non-Stop-Forwarding is in progress. Fixes: af8496af08 ("bgpd: Do not delete BGP dynamic peers if graceful restart kicks in") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-05-16 15:08:09 +02:00
if (peer_dynamic_neighbor_no_nsf(peer)) {
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s (dynamic neighbor) deleted (%s) for %s", __func__,
peer->host, bgp_peer_get_connection_direction(connection));
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
peer_delete(peer);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE_AND_DELETE;
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Switch LL nexthop tracking to be interface based bgp is currently registering v6 LL as nexthops to be tracked from zebra. This presents several problems. a) zebra does not properly track multiple prefixes that match the same route properly at this point in time. b) BGP was receiving nexthops that were just incorrect because of (a). c) When a nexthop changed that really didn't affect the v6 LL we were responding incorrectly because of this Modify the code such that bgp nexthop tracking notices that we are trying to register a v6 LL. When we do so, shortcut and watch interface up/down events for this v6 LL and do the work when an interface goes up / down for this type of tracking. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-17 15:46:30 +01:00
/*
* If we are doing nht for a peer that ls v6 LL based
* massage the event system to make things happy
*/
bgp_nht_interface_events(peer);
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
return bgp_stop(connection);
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: fix addressing information of non established outgoing sessions When trying to connect to a BGP peer that does not respons, the 'show bgp neighbors' command does not give any indication on the local and remote addresses used: > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:04, Waiting for peer OPEN (n/a) > Internal BGP neighbor may be up to 255 hops away. > BGP Connect Retry Timer in Seconds: 120 > Next connect timer due in 117 seconds > Read thread: off Write thread: off FD used: 27 The addressing information (address and port) are only available when TCP session is established, whereas this information is present at the system level: > root@ubuntu2204:~# netstat -pan | grep 192.0.2.1 > tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV - > tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd Add the display for outgoing BGP session, as the information in the getsockname() API provides information for connected streams. When getpeername() API does not give any information, use the peer configuration (destination port is encoded in peer->port). > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:16, Waiting for peer OPEN (n/a) > Local host: 192.0.2.1, Local port: 46084 > Foreign host: 192.0.2.150, Foreign port: 179 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-05 09:55:05 +02:00
/* after connect is called(), getpeername is able to return
* port and address on non established streams
*/
bgpd: Modify bgp_connect_in_progress_update_connection to use connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:25:20 +01:00
static void bgp_connect_in_progress_update_connection(struct peer_connection *connection)
bgpd: fix addressing information of non established outgoing sessions When trying to connect to a BGP peer that does not respons, the 'show bgp neighbors' command does not give any indication on the local and remote addresses used: > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:04, Waiting for peer OPEN (n/a) > Internal BGP neighbor may be up to 255 hops away. > BGP Connect Retry Timer in Seconds: 120 > Next connect timer due in 117 seconds > Read thread: off Write thread: off FD used: 27 The addressing information (address and port) are only available when TCP session is established, whereas this information is present at the system level: > root@ubuntu2204:~# netstat -pan | grep 192.0.2.1 > tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV - > tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd Add the display for outgoing BGP session, as the information in the getsockname() API provides information for connected streams. When getpeername() API does not give any information, use the peer configuration (destination port is encoded in peer->port). > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:16, Waiting for peer OPEN (n/a) > Local host: 192.0.2.1, Local port: 46084 > Foreign host: 192.0.2.150, Foreign port: 179 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-05 09:55:05 +02:00
{
bgpd: Modify bgp_connect_in_progress_update_connection to use connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:25:20 +01:00
struct peer *peer = connection->peer;
bgpd: su_remote and su_local are properties of the connection su_local and su_remote in the peer can change based upon if we are initiating the remote connection or receiving it. As such we need to treat it as a property of the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-17 21:56:19 +01:00
if (!connection->su_remote && !BGP_CONNECTION_SU_UNSPEC(connection)) {
bgpd: fix 'nexthop_set failed' error message often displayed The 'nexthop_set failed, resetting connection - intf' log message is often seen when peering with BGP peers. This message has been displayed by introducing a recent fix that extracts the IP/port information of outgoing connections when peering is not yet established. Fix this by separating the update of the socket information from the call to bgp_zebra_nexthop_set(). Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-09-12 16:11:52 +02:00
/* if connect initiated, then dest port and dest addresses are well known */
bgpd: su_remote and su_local are properties of the connection su_local and su_remote in the peer can change based upon if we are initiating the remote connection or receiving it. As such we need to treat it as a property of the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-17 21:56:19 +01:00
connection->su_remote = sockunion_dup(&connection->su);
if (sockunion_family(connection->su_remote) == AF_INET)
connection->su_remote->sin.sin_port = htons(peer->port);
else if (sockunion_family(connection->su_remote) == AF_INET6)
connection->su_remote->sin6.sin6_port = htons(peer->port);
bgpd: fix addressing information of non established outgoing sessions When trying to connect to a BGP peer that does not respons, the 'show bgp neighbors' command does not give any indication on the local and remote addresses used: > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:04, Waiting for peer OPEN (n/a) > Internal BGP neighbor may be up to 255 hops away. > BGP Connect Retry Timer in Seconds: 120 > Next connect timer due in 117 seconds > Read thread: off Write thread: off FD used: 27 The addressing information (address and port) are only available when TCP session is established, whereas this information is present at the system level: > root@ubuntu2204:~# netstat -pan | grep 192.0.2.1 > tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV - > tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd Add the display for outgoing BGP session, as the information in the getsockname() API provides information for connected streams. When getpeername() API does not give any information, use the peer configuration (destination port is encoded in peer->port). > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:16, Waiting for peer OPEN (n/a) > Local host: 192.0.2.1, Local port: 46084 > Foreign host: 192.0.2.150, Foreign port: 179 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-05 09:55:05 +02:00
}
}
Initial revision
2002-12-13 21:15:29 +01:00
/* This function is the first starting point of all BGP connection. It
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
* try to connect to remote peer with non-blocking IO.
*/
bgpd: Cleanup bgp_start declarations Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:55:40 +02:00
static enum bgp_fsm_state_progress bgp_start(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: bgp_connect should return an `enum connect_result` This function when it is run by bgp_start is expected to return a `enum connect_result`. But instead the function returns a variety of values that are not really being checked for. Consolidate to a correct choice. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-20 15:18:39 +01:00
enum connect_result status;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Move the peer->su to connection->su The sockunion is per connection. So let's move it over. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-08 18:02:05 +02:00
bgp_peer_conf_if_to_su_update(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Move the peer->su to connection->su The sockunion is per connection. So let's move it over. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-08 18:02:05 +02:00
if (connection->su.sa.sa_family == AF_UNSPEC) {
BGP: Do not get out of bgp_start() if peer's IP address isn't known Ticket: CM-7140 Reviewed By: CCR-3412 Testing Done: bgpsmoke, Atul verified fix BGP Unnumbered and Interface based peering can interact in some strange ways. One of them is when there's an IPv4 address on a link on which BGP Unnumbered session is beng attempted, but the IPv4 address is not a /30 or /31. As per the bug report, we end up attempting to start the BGP FSM on receiving a notification that an IPv4 address is present on an interface. To avoid attempting to go past BGP's start state in the absence of a valid peer address is the right thing to do. And this simple patch does just that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
2015-10-21 07:01:49 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Unable to get neighbor's IP address, waiting... for %s",
peer->host, bgp_peer_get_connection_direction(connection));
bgpd: Add a new command to only show failed peerings In a data center, having 32-128 peers is not uncommon. In such a situation, to find a peer that has failed and why is several commands. This hinders both the automatability of failure detection and the ease/speed with which the reason can be found. To simplify this process of catching a failure and its cause quicker, this patch does the following: 1. Created a new function, bgp_show_failed_summary to display the failed summary output for JSON and vty 2. Created a new function to display the reset code/subcode. This is now used in the failed summary code and in the show neighbors code 3. Added a new variable failedPeers in all the JSON outputs, including the vanilla "show bgp summary" family. This lists the failed session count. 4. Display peer, dropped count, estd count, uptime and the reason for failure as the output of "show bgp summary failed" family of commands 5. Added three resset codes for the case where we're waiting for NHT, waiting for peer IPv6 addr, waiting for VRF to init. This also counts the case where only one peer has advertised an AFI/SAFI. The new command has the optional keyword "failed" added to the classical summary command. The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr, the output of that command will show a "waiting for NHT" etc. as the last reset reason. This patch includes update to the documentation too. Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
2019-08-31 18:24:49 +02:00
peer->last_reset = PEER_DOWN_NBR_ADDR;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
BGP: Do not get out of bgp_start() if peer's IP address isn't known Ticket: CM-7140 Reviewed By: CCR-3412 Testing Done: bgpsmoke, Atul verified fix BGP Unnumbered and Interface based peering can interact in some strange ways. One of them is when there's an IPv4 address on a link on which BGP Unnumbered session is beng attempted, but the IPv4 address is not a /30 or /31. As per the bug report, we end up attempting to start the BGP FSM on receiving a notification that an IPv4 address is present on an interface. To avoid attempting to go past BGP's start state in the absence of a valid peer address is the right thing to do. And this simple patch does just that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
2015-10-21 07:01:49 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
if (BGP_PEER_START_SUPPRESSED(peer)) {
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: BGP_[WARN|ERR] -> EC_BGP Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 20:23:42 +02:00
flog_err(EC_BGP_FSM,
*: un-split strings across lines Remove mid-string line breaks, cf. workflow doc: .. [#tool_style_conflicts] For example, lines over 80 characters are allowed for text strings to make it possible to search the code for them: please see `Linux kernel style (breaking long lines and strings) <https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_ and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_. Scripted commit, idempotent to running: ``` python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'` ``` Signed-off-by: David Lamparter <equinox@diac24.net>
2020-03-27 12:35:23 +01:00
"%s [FSM] Trying to start suppressed peer - this is never supposed to happen!",
*: style for EC replacements Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 21:38:57 +02:00
peer->host);
bgpd: Show the reason when the session is killed due to RTT Simulated latency with: ``` tc qdisc add dev eth3 root netem delay 100ms ``` ``` donatas-laptop# sh ip bgp summary failed IPv4 Unicast Summary (VRF default): BGP router identifier 192.0.2.252, local AS number 65000 vrf-id 0 BGP table version 28 RIB entries 0, using 0 bytes of memory Peers 1, using 724 KiB of memory Neighbor EstdCnt DropCnt ResetTime Reason 192.168.10.65 2 2 00:00:17 Admin. shutdown (RTT) Displayed neighbors 1 Total number of neighbors 1 donatas-laptop# ``` Another end received: ``` %NOTIFICATION: received from neighbor 192.168.10.17 6/2 (Cease/Administrative Shutdown) "shutdown due to high round-trip-time (104ms > 5ms, hit 21 times)" ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-11-04 14:40:52 +01:00
if (CHECK_FLAG(peer->sflags, PEER_STATUS_RTT_SHUTDOWN))
peer->last_reset = PEER_DOWN_RTT_SHUTDOWN;
else if (CHECK_FLAG(peer->flags, PEER_FLAG_SHUTDOWN))
bgpd: Show the real reason why the peer is failed If the peer was shutdown locally, it doesn't show up as admin. shutdown. Instead it's treated as "Waiting for peer OPEN". The same applies to when the peer reaches maximum-prefix count. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-14 22:21:55 +01:00
peer->last_reset = PEER_DOWN_USER_SHUTDOWN;
bgpd: bgp instance administrative shutdown. * Fixed integration in FSM and packet handling. * Added CLI "show" output, incl. JSON. * For review and testing only. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-08-14 10:23:34 +02:00
else if (CHECK_FLAG(peer->bgp->flags, BGP_FLAG_SHUTDOWN))
peer->last_reset = PEER_DOWN_USER_SHUTDOWN;
bgpd: Show the real reason why the peer is failed If the peer was shutdown locally, it doesn't show up as admin. shutdown. Instead it's treated as "Waiting for peer OPEN". The same applies to when the peer reaches maximum-prefix count. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-14 22:21:55 +01:00
else if (CHECK_FLAG(peer->sflags, PEER_STATUS_PREFIX_OVERFLOW))
peer->last_reset = PEER_DOWN_PFX_COUNT;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
[bgpd] Fix crash on shutdown of peer 2006-07-02 Paul Jakma <paul.jakma@sun.com> * bgp_fsm.c: (bgp_{stop,start}) Move clear/free of certain bits of state from stop to start, as they may be used via peer references on clearing queues..
2006-07-02 13:01:50 +02:00
/* Clear remote router-id. */
*: Replace s_addr 0 => INADDR_ANY Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-06 07:49:02 +01:00
peer->remote_id.s_addr = INADDR_ANY;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
[bgpd] Fix crash on shutdown of peer 2006-07-02 Paul Jakma <paul.jakma@sun.com> * bgp_fsm.c: (bgp_{stop,start}) Move clear/free of certain bits of state from stop to start, as they may be used via peer references on clearing queues..
2006-07-02 13:01:50 +02:00
/* Clear peer capability flag. */
peer->cap = 0;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: cleanup special checks for views bgp->vrf_id is always VRF_DEFAULT for views. All these special checks are not necessary. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2021-09-03 16:36:40 +02:00
if (peer->bgp->vrf_id == VRF_UNKNOWN) {
bgpd: bgp support for netns The change contained in this commit does the following: - discovery of vrf id from zebra daemon, and adaptation of bgp contexts with BGP. The list of network addresses contain a reference to the bgp context supporting the vrf. The bgp context contains a vrf pointer that gives information about the netns path in case the vrf is a netns path. Only some contexts are impacted, namely socket creation, and retrieval of local IP settings. ( this requires vrf identifier). Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2017-12-20 12:37:18 +01:00
if (bgp_debug_neighbor_events(peer))
*: rename zlog_fer -> flog_err Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-08-03 20:03:29 +02:00
flog_err(
bgpd: BGP_[WARN|ERR] -> EC_BGP Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 20:23:42 +02:00
EC_BGP_FSM,
bgpd: bgp support for netns The change contained in this commit does the following: - discovery of vrf id from zebra daemon, and adaptation of bgp contexts with BGP. The list of network addresses contain a reference to the bgp context supporting the vrf. The bgp context contains a vrf pointer that gives information about the netns path in case the vrf is a netns path. Only some contexts are impacted, namely socket creation, and retrieval of local IP settings. ( this requires vrf identifier). Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2017-12-20 12:37:18 +01:00
"%s [FSM] In a VRF that is not initialised yet",
peer->host);
bgpd: Add a new command to only show failed peerings In a data center, having 32-128 peers is not uncommon. In such a situation, to find a peer that has failed and why is several commands. This hinders both the automatability of failure detection and the ease/speed with which the reason can be found. To simplify this process of catching a failure and its cause quicker, this patch does the following: 1. Created a new function, bgp_show_failed_summary to display the failed summary output for JSON and vty 2. Created a new function to display the reset code/subcode. This is now used in the failed summary code and in the show neighbors code 3. Added a new variable failedPeers in all the JSON outputs, including the vanilla "show bgp summary" family. This lists the failed session count. 4. Display peer, dropped count, estd count, uptime and the reason for failure as the output of "show bgp summary failed" family of commands 5. Added three resset codes for the case where we're waiting for NHT, waiting for peer IPv6 addr, waiting for VRF to init. This also counts the case where only one peer has advertised an AFI/SAFI. The new command has the optional keyword "failed" added to the classical summary command. The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr, the output of that command will show a "waiting for NHT" etc. as the last reset reason. This patch includes update to the documentation too. Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
2019-08-31 18:24:49 +02:00
peer->last_reset = PEER_DOWN_VRF_UNINIT;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
bgpd: bgp support for netns The change contained in this commit does the following: - discovery of vrf id from zebra daemon, and adaptation of bgp contexts with BGP. The list of network addresses contain a reference to the bgp context supporting the vrf. The bgp context contains a vrf pointer that gives information about the netns path in case the vrf is a netns path. Only some contexts are impacted, namely socket creation, and retrieval of local IP settings. ( this requires vrf identifier). Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2017-12-20 12:37:18 +01:00
}
bgpd: Fix nexthop reg for IPv4 route exchange using GUA IPv6 peering In the case of IPv4 route exchange using GUA IPv6 peering, the route install into the FIB involves mapping the immediate next hop to an IPv4 link-local address and installing neighbor entries for this next hop address. To accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop or peer must also have this enabled) and the RAs are dynamically initiated based on next hop resolution. However, in the case of a passive connection where the local system has not initiated anything, no NHT entry is created for the peer, hence RAs were not getting triggered. Address this by ensuring that a NHT entry is created even in this situation. This is done at the time the connection becomes established because the code has other assumptions that a NHT entry will be present only for the "configured" peer. The API to create the entry ensures there are no duplicates. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
2019-08-19 07:12:06 +02:00
/* Register peer for NHT. If next hop is already resolved, proceed
* with connection setup, else wait.
*/
if (!bgp_peer_reg_with_nht(peer)) {
bgpd: Respect ability to reach nexthop if available When bgp is thinking about opening a connection to a peer, if we are connected to zebra, allow that to influence our decision to start the connection. Found Scenario: Both bgp and zebra are started up at the same time. Zebra is being used to create the connected route through which bgp will establish a peering relationship. The machine is a bit loaded due to other startup conditions and as such bgp gets to the connection stage here before zebra has installed the route. If bgp does not respect zebra data when it does have a connection then we will attempt to connect. The connect will fail because there is no route. At that time we will go into the connect timeout(2 minutes) and delay connection. What this does. If we have established a zebra connection and we do not have a clear path to the destination at this point do not allow the connection to proceed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-05-11 13:40:55 +02:00
if (bgp_zebra_num_connects()) {
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Waiting for NHT, no path to neighbor present for %s",
peer->host,
bgp_peer_get_connection_direction(connection));
bgpd: Add a new command to only show failed peerings In a data center, having 32-128 peers is not uncommon. In such a situation, to find a peer that has failed and why is several commands. This hinders both the automatability of failure detection and the ease/speed with which the reason can be found. To simplify this process of catching a failure and its cause quicker, this patch does the following: 1. Created a new function, bgp_show_failed_summary to display the failed summary output for JSON and vty 2. Created a new function to display the reset code/subcode. This is now used in the failed summary code and in the show neighbors code 3. Added a new variable failedPeers in all the JSON outputs, including the vanilla "show bgp summary" family. This lists the failed session count. 4. Display peer, dropped count, estd count, uptime and the reason for failure as the output of "show bgp summary failed" family of commands 5. Added three resset codes for the case where we're waiting for NHT, waiting for peer IPv6 addr, waiting for VRF to init. This also counts the case where only one peer has advertised an AFI/SAFI. The new command has the optional keyword "failed" added to the classical summary command. The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr, the output of that command will show a "waiting for NHT" etc. as the last reset reason. This patch includes update to the documentation too. Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
2019-08-31 18:24:49 +02:00
peer->last_reset = PEER_DOWN_WAITING_NHT;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_EVENT_ADD(connection, TCP_connection_open_failed);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
bgpd: Respect ability to reach nexthop if available When bgp is thinking about opening a connection to a peer, if we are connected to zebra, allow that to influence our decision to start the connection. Found Scenario: Both bgp and zebra are started up at the same time. Zebra is being used to create the connected route through which bgp will establish a peering relationship. The machine is a bit loaded due to other startup conditions and as such bgp gets to the connection stage here before zebra has installed the route. If bgp does not respect zebra data when it does have a connection then we will attempt to connect. The connect will fail because there is no route. At that time we will go into the connect timeout(2 minutes) and delay connection. What this does. If we have established a zebra connection and we do not have a clear path to the destination at this point do not allow the connection to proceed. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-05-11 13:40:55 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
assert(!connection->t_write);
assert(!connection->t_read);
assert(!CHECK_FLAG(connection->thread_flags, PEER_THREAD_WRITES_ON));
assert(!CHECK_FLAG(connection->thread_flags, PEER_THREAD_READS_ON));
bgpd: bgp_connect is struct peer_connection oriented Make it so. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-08 18:18:07 +02:00
status = bgp_connect(connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
2004-05-01 Paul Jakma <paul@dishone.st> * Revert the attempted clean-up of the dummy peer hack, reverts patchsets 435 (see 2004-02-17 below) and 456.
2004-05-01 10:44:08 +02:00
switch (status) {
Initial revision
2002-12-13 21:15:29 +01:00
case connect_error:
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Connect error for %s", peer->host,
bgp_peer_get_connection_direction(connection));
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_EVENT_ADD(connection, TCP_connection_open_failed);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
Initial revision
2002-12-13 21:15:29 +01:00
case connect_success:
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Connect immediately success, fd %d for %s", peer->host,
connection->fd, bgp_peer_get_connection_direction(connection));
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
BGP_EVENT_ADD(connection, TCP_connection_open);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
Initial revision
2002-12-13 21:15:29 +01:00
case connect_in_progress:
/* To check nonblocking connect, we wait until socket is
readable or writable. */
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Non blocking connect waiting result, fd %d for %s",
peer->host, connection->fd,
bgp_peer_get_connection_direction(connection));
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if (connection->fd < 0) {
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_BGP_FSM, "%s peer's fd is negative value %d",
bgpd: Convert `struct peer_connection` to dynamically allocated As part of the conversion to a `struct peer_connection` it will be desirable to have 2 pointers one for when we open a connection and one for when we receive a connection. Start this actual conversion over to this in `struct peer`. If this sounds confusing take a look at the bgp state machine for connections and how it resolves the processing of this router opening -vs- this router receiving an open. At some point in time the state machine decides that we are keeping one of the two connections. Future commits will allow us to untangle the peer/doppelganger duality with this abstraction. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 05:43:46 +02:00
__func__, peer->connection->fd);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
bgpd: Modify bgp_connect_in_progress_update_connection to use connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 20:25:20 +01:00
bgp_connect_in_progress_update_connection(connection);
bgpd: fix addressing information of non established outgoing sessions When trying to connect to a BGP peer that does not respons, the 'show bgp neighbors' command does not give any indication on the local and remote addresses used: > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:04, Waiting for peer OPEN (n/a) > Internal BGP neighbor may be up to 255 hops away. > BGP Connect Retry Timer in Seconds: 120 > Next connect timer due in 117 seconds > Read thread: off Write thread: off FD used: 27 The addressing information (address and port) are only available when TCP session is established, whereas this information is present at the system level: > root@ubuntu2204:~# netstat -pan | grep 192.0.2.1 > tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV - > tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd Add the display for outgoing BGP session, as the information in the getsockname() API provides information for connected streams. When getpeername() API does not give any information, use the peer configuration (destination port is encoded in peer->port). > # show bgp neighbors > BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link > Local Role: undefined > Remote Role: undefined > BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1 > BGP state = Connect > [..] > Connections established 0; dropped 0 > Last reset 00:00:16, Waiting for peer OPEN (n/a) > Local host: 192.0.2.1, Local port: 46084 > Foreign host: 192.0.2.150, Foreign port: 179 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-05 09:55:05 +02:00
bgpd, tests: comment formatting Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-08 17:51:12 +02:00
/*
bgpd: fix bgp active open At some point when rearranging FSM code, bgpd lost the ability to perform active opens because it was only paying attention to POLLIN and not POLLOUT, when the latter is used to signify a successful connection in the active case. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-25 04:18:15 +02:00
* - when the socket becomes ready, poll() will signify POLLOUT
* - if it fails to connect, poll() will signify POLLHUP
* - POLLHUP is handled as a 'read' event by thread.c
*
* therefore, we schedule both a read and a write event with
* bgp_connect_check() as the handler for each and cancel the
* unused event in that function.
bgpd, tests: comment formatting Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-08 17:51:12 +02:00
*/
bgpd: modify bgp_connect_check to use a connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:30:08 +02:00
event_add_read(bm->master, bgp_connect_check, connection,
connection->fd, &connection->t_connect_check_r);
event_add_write(bm->master, bgp_connect_check, connection,
connection->fd, &connection->t_connect_check_w);
Initial revision
2002-12-13 21:15:29 +01:00
break;
}
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
/* Connect retry timer is expired when the peer status is Connect. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_reconnect(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
enum bgp_fsm_state_progress ret;
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
ret = bgp_stop(connection);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
if (ret < BGP_FSM_SUCCESS)
return ret;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
/* Send graceful restart capabilty */
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
BGP_GR_ROUTER_DETECT_AND_SEND_CAPABILITY_TO_ZEBRA(peer->bgp,
peer->bgp->peer);
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
return bgp_start(connection);
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_open(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* If DelayOpen is active, we may still need to send an open message */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
if ((connection->status == Connect) || (connection->status == Active))
bgpd: bgp_open_send is connection oriented not peer oriented The bgp_open_send function should use a connection oriented pointer for it's basis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:31:54 +02:00
bgp_open_send(connection);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Send keepalive and make keepalive timer */
bgpd: Convert bgp_keepalive_send to use a connection The peer is going to eventually have a incoming and outgoing connection. Let's send the data based upon the connection not the peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 19:00:43 +01:00
bgp_keepalive_send(connection);
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
/* FSM error, unexpected event. This is error of BGP connection. So cut the
peer and change to Idle status. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_event_error(struct peer_connection *connection)
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
*: style for EC replacements Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 21:38:57 +02:00
flog_err(EC_BGP_FSM, "%s [FSM] unexpected packet received in state %s",
bgpd: Move status and ostatus to `struct peer_connection` The status and ostatus are a function of the `struct peer_connection` move it into that data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-06-03 23:13:52 +02:00
peer->host,
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
lookup_msg(bgp_status_msg, connection->status, NULL));
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
return bgp_stop_with_notify(connection, BGP_NOTIFY_FSM_ERR,
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_fsm_error_subcode(connection->status));
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
/* Hold timer expire. This is error of BGP connection. So cut the
peer and change to Idle status. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_holdtime_expire(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] Hold timer expire for %s", peer->host,
bgp_peer_get_connection_direction(connection));
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Activate Graceful-Restart when receiving CEASE/HOLDTIME notifications If we receive CEASE Notification or HOLDTIME notification, retain STALE routes if it's not a CEASE/Hard Reset. When doing `clear ip bgp PEER`, we can control if this would be CEASE/Hard Reset or not by using `bgp hard-administrative-reset` knob. When `bgp graceful-restart notification` is disabled, STALE routes won't be retained when receiving Notification message. Co-authored-by: Biswajit Sadhu <biswajit.sadhu@gmail.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-05-11 18:42:53 +02:00
/* RFC8538 updates RFC 4724 by defining an extension that permits
* the Graceful Restart procedures to be performed when the BGP
* speaker receives a BGP NOTIFICATION message or the Hold Time expires.
*/
bgpd: peer_established should be connection oriented The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:11:07 +02:00
if (peer_established(connection) &&
bgpd: Activate Graceful-Restart when receiving CEASE/HOLDTIME notifications If we receive CEASE Notification or HOLDTIME notification, retain STALE routes if it's not a CEASE/Hard Reset. When doing `clear ip bgp PEER`, we can control if this would be CEASE/Hard Reset or not by using `bgp hard-administrative-reset` knob. When `bgp graceful-restart notification` is disabled, STALE routes won't be retained when receiving Notification message. Co-authored-by: Biswajit Sadhu <biswajit.sadhu@gmail.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-05-11 18:42:53 +02:00
bgp_has_graceful_restart_notification(peer))
if (CHECK_FLAG(peer->sflags, PEER_STATUS_NSF_MODE))
SET_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT);
bgpd: convert bgp_stop_with_notify to connection based The bgp_stop_with_notify function should use a peer_connection pointer as the basis instead of a peer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:25:32 +02:00
return bgp_stop_with_notify(connection, BGP_NOTIFY_HOLD_ERR, 0);
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* RFC 4271 DelayOpenTimer_Expires event */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
static enum bgp_fsm_state_progress
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_fsm_delayopen_timer_expire(struct peer_connection *connection)
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{
/* Stop the DelayOpenTimer */
bgpd: bgp_open_send is connection oriented not peer oriented The bgp_open_send function should use a connection oriented pointer for it's basis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:31:54 +02:00
EVENT_OFF(connection->t_delayopen);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* Send open message to peer */
bgpd: bgp_open_send is connection oriented not peer oriented The bgp_open_send function should use a connection oriented pointer for it's basis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:31:54 +02:00
bgp_open_send(connection);
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
/* Set the HoldTimer to a large value (4 minutes) */
bgpd: bgp_open_send is connection oriented not peer oriented The bgp_open_send function should use a connection oriented pointer for it's basis. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:31:54 +02:00
connection->peer->v_holdtime = 245;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
}
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
/* Start the selection deferral timer thread for the specified AFI, SAFI */
static int bgp_start_deferral_timer(struct bgp *bgp, afi_t afi, safi_t safi,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
struct graceful_restart_info *gr_info)
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
{
struct afi_safi_info *thread_info;
/* If the deferral timer is active, then increment eor count */
if (gr_info->t_select_deferral) {
gr_info->eor_required++;
return 0;
}
/* Start the deferral timer when the first peer enabled for the graceful
* restart is established
*/
if (gr_info->eor_required == 0) {
thread_info = XMALLOC(MTYPE_TMP, sizeof(struct afi_safi_info));
thread_info->afi = afi;
thread_info->safi = safi;
thread_info->bgp = bgp;
*: Convert thread_add_XXX functions to event_add_XXX Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-20 20:19:08 +02:00
event_add_timer(bm->master, bgp_graceful_deferral_timer_expire,
thread_info, bgp->select_defer_time,
&gr_info->t_select_deferral);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
gr_info->eor_required++;
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
/* Send message to RIB indicating route update pending */
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
if (gr_info->af_enabled == false) {
gr_info->af_enabled = true;
gr_info->route_sync = false;
bgp->gr_route_sync_pending = true;
lib, bgpd: Add more debugs to GR Capability exchange a) Make it legible what type of message is being passed back and forth instead of having to guess it from the insufficient debugs b) Make it explicit which bgp instance is sending this data c) Cleanup bgp_zebra_update to have a cleaner api Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-09 14:36:51 +01:00
bgp_zebra_update(bgp, afi, safi,
bgpd: Adding bgp peer route processing and EOR state Signalling from BGPD to Zebra. * While the Deferral timer is running, signal route update pending (ZEBRA_CLIENT_ROUTE_UPDATE_PENDING) from BGPD to Zebra. * After expiry of the Deferral timer, the deferred routes are processed. When the deferred route_list becomes empty, End-of-Rib is send to the peer and route processing complete message (ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE) is sent to Zebra. So that Zebra would delete any stale routes still present in the rib. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-26 18:40:33 +02:00
ZEBRA_CLIENT_ROUTE_UPDATE_PENDING);
}
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
if (BGP_DEBUG(update, UPDATE_OUT))
zlog_debug("Started the deferral timer for %s eor_required %d",
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
get_afi_safi_str(afi, safi, false),
gr_info->eor_required);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
return 0;
}
/* Update the graceful restart information for the specified AFI, SAFI */
static int bgp_update_gr_info(struct peer *peer, afi_t afi, safi_t safi)
{
struct graceful_restart_info *gr_info;
struct bgp *bgp = peer->bgp;
int ret = 0;
if ((afi < AFI_IP) || (afi >= AFI_MAX)) {
if (BGP_DEBUG(update, UPDATE_OUT))
zlog_debug("%s : invalid afi %d", __func__, afi);
return -1;
}
if ((safi < SAFI_UNICAST) || (safi > SAFI_MPLS_VPN)) {
if (BGP_DEBUG(update, UPDATE_OUT))
zlog_debug("%s : invalid safi %d", __func__, safi);
return -1;
}
/* Restarting router */
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
if (BGP_PEER_GRACEFUL_RESTART_CAPABLE(peer)
&& BGP_PEER_RESTARTING_MODE(peer)) {
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
/* Check if the forwarding state is preserved */
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
if (bgp_gr_is_forwarding_preserved(bgp)) {
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
gr_info = &(bgp->gr_info[afi][safi]);
ret = bgp_start_deferral_timer(bgp, afi, safi, gr_info);
}
}
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
return ret;
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
bgpd: transfer packets from peer stub to actual peer During transition from OpenConfirm -> Established, we wipe the peer stub's output buffer. Because thread.c prioritizes I/O operations over regular background threads and events, in a single threaded environment this ordering meant that the output buffer would be happily empty at wipe time. In MT-land, this convenient coincidence is no longer true; thus we need to make sure that any packets remaining on the peer stub get transferred over to the peer proper. Also removes misleading comment indicating that bgp_establish() sends a keepalive packet. It does not. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-04-06 03:09:33 +02:00
/**
* Transition to Established state.
*
* Convert peer from stub to full fledged peer, set some timers, and generate
* initial updates.
*/
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_establish(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
afi_t afi;
safi_t safi;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
int nsf_af_count = 0;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
enum bgp_fsm_state_progress ret = BGP_FSM_SUCCESS;
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
struct peer *other;
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
int status;
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: Add peers back to peer hash when peer_xfer_conn fails It was noticed that occassionally peering failed in a testbed upon investigation it was found that the peer was not in the peer hash and we saw these failure messages: Aug 25 21:31:15 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: %NOTIFICATION: sent to neighbor 2001:cafe:1ead:4::4 4/0 (Hold Timer Expired) 0 bytes Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] Can't get remote address and port: Transport endpoint is not connected Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] %bgp_getsockname() failed for peer 2001:cafe:1ead:4::4 fd 27 (from_peer fd -1) Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 33554464] %Neighbor failed in xfer_conn root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# vtysh -c 'show bgp peerhash' | grep 2001:cafe:1ead:4::4 root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# Upon looking at the code the peer_xfer_conn function can fail and the bgp_establish code will then return before adding the peer back to the peerhash. This is only part of the failure. The peer also appears to be in a state where it is no longer initiating connection attempts but that will be another commited fix when we figure that one out. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-30 13:25:06 +02:00
struct peer *orig = peer;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
other = peer->doppelganger;
bgpd: Hash release before we change the underlying hash assumptions The bgp->peerhash is made up of the sockunion and the CONFIG_NODE flag. If the CONFIG_NODE flag is moved around or changed then we get into a situation where both the doppelganger and the peer actually hash to the exact same thing. Leading to wrongful deletion and pointers being used after freed. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-02 18:51:34 +01:00
hash_release(peer->bgp->peerhash, peer);
if (other)
hash_release(peer->bgp->peerhash, other);
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
peer = peer_xfer_conn(peer);
if (!peer) {
bgpd: BGP_[WARN|ERR] -> EC_BGP Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-09-13 20:23:42 +02:00
flog_err(EC_BGP_CONNECT, "%%Neighbor failed in xfer_conn");
bgpd: Add peers back to peer hash when peer_xfer_conn fails It was noticed that occassionally peering failed in a testbed upon investigation it was found that the peer was not in the peer hash and we saw these failure messages: Aug 25 21:31:15 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: %NOTIFICATION: sent to neighbor 2001:cafe:1ead:4::4 4/0 (Hold Timer Expired) 0 bytes Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] Can't get remote address and port: Transport endpoint is not connected Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 100663299] %bgp_getsockname() failed for peer 2001:cafe:1ead:4::4 fd 27 (from_peer fd -1) Aug 25 21:31:22 doca-hbn-service-bf3-s06-1-ipmi bgpd[3048]: [EC 33554464] %Neighbor failed in xfer_conn root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# vtysh -c 'show bgp peerhash' | grep 2001:cafe:1ead:4::4 root@doca-hbn-service-bf3-s06-1-ipmi:/var/log/hbn/frr# Upon looking at the code the peer_xfer_conn function can fail and the bgp_establish code will then return before adding the peer back to the peerhash. This is only part of the failure. The peer also appears to be in a state where it is no longer initiating connection attempts but that will be another commited fix when we figure that one out. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-30 13:25:06 +02:00
/*
* A failure of peer_xfer_conn but not putting the peers
* back in the hash ends up with a situation where incoming
* connections are rejected, as that the peer is not found
* when a lookup is done
*/
(void)hash_get(orig->bgp->peerhash, orig, hash_alloc_intern);
if (other)
(void)hash_get(other->bgp->peerhash, other,
hash_alloc_intern);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_FAILURE;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
/*
* At this point the connections have been possibly swapped
* let's reset it.
*/
connection = peer->connection;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (other == peer)
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
ret = BGP_FSM_SUCCESS_STATE_TRANSFER;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Reset capability open status flag. */
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_CAPABILITY_OPEN))
SET_FLAG(peer->sflags, PEER_STATUS_CAPABILITY_OPEN);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Clear start timer value to default. */
peer->v_start = BGP_INIT_START_TIMER;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Increment established count. */
peer->established++;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_fsm_change_status(connection, Established);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Do not show "Waiting for OPEN" as last reset This is actually not reset, and should be ignored showing it as last reset under `show bgp neighbor`. Fixes: 1e91f1d1193003cb325a2bf595c8a9273740e2f0 ("bgpd: Update failed reason to distinguish some NHT scenario") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-18 13:16:06 +01:00
if (peer->last_reset == PEER_DOWN_WAITING_OPEN)
peer->last_reset = 0;
2003-08-13 kunihiro <kunihiro@zebra.org> * bgpd/bgp{_fsm.c,_vty.c,d.c,d.h}: Add support for "bgp log-neighbor-changes" command.
2003-08-13 02:32:49 +02:00
/* bgp log-neighbor-changes of neighbor Up */
bgpd: Replace bgp_flag_* to [UN]SET/CHECK_FLAG macros Most of the code uses macros, thus let's keep the code unified. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-02-06 15:37:20 +01:00
if (CHECK_FLAG(peer->bgp->flags, BGP_FLAG_LOG_NEIGHBOR_CHANGES)) {
bgpd: Fix ADJCHANGE message to include more info When bgp logs ADJCHANGE messages include the hostname and vrf that this change is being made in. Ticket: CM-10922 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2016-11-15 16:16:52 +01:00
struct vrf *vrf = vrf_lookup_by_id(peer->bgp->vrf_id);
bgpd: Add `%pBP` printfrr() extension to print `IP(hostname)` for BGP peer Replace existing bgp_peer_hostname() function. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-31 14:59:06 +02:00
zlog_info("%%ADJCHANGE: neighbor %pBP in vrf %s Up", peer,
bgpd: Print hostname along with IP for most useful debug messages Examples: ``` %ADJCHANGE: neighbor 192.168.0.1(exit1-debian-11) in vrf default Up 192.168.0.1(exit1-debian-11) graceful restart stalepath timer expired 192.168.0.1(exit1-debian-11) sending route-refresh (BoRR) for IPv4/unicast 192.168.0.1(exit1-debian-11) graceful restart timer started for 120 sec 192.168.0.1(exit1-debian-11) graceful restart stalepath timer started for 120 sec 192.168.0.1(exit1-debian-11) graceful restart timer stopped %MAXPFXEXCEED: No. of IPv4 Unicast prefix received from 192.168.0.1(exit1-debian-11) 9 exceed, limit 1 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-22 20:45:47 +01:00
vrf ? ((vrf->vrf_id != VRF_DEFAULT)
? vrf->name
: VRF_DEFAULT_NAME)
: "");
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
/* assign update-group/subgroup */
update_group_adjust_peer_afs(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
/* graceful restart */
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT);
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
if (bgp_debug_neighbor_events(peer)) {
if (BGP_PEER_RESTARTING_MODE(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP BGP_RESTARTING_MODE %s", peer,
bgp_peer_get_connection_direction(connection));
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
else if (BGP_PEER_HELPER_MODE(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP BGP_HELPER_MODE %s", peer,
bgp_peer_get_connection_direction(connection));
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
FOREACH_AFI_SAFI_NSF (afi, safi) {
if (peer->afc_nego[afi][safi] &&
CHECK_FLAG(peer->cap, PEER_CAP_RESTART_ADV) &&
CHECK_FLAG(peer->af_cap[afi][safi],
PEER_CAP_RESTART_AF_RCV)) {
if (peer->nsf[afi][safi] &&
!CHECK_FLAG(peer->af_cap[afi][safi],
PEER_CAP_RESTART_AF_PRESERVE_RCV))
bgp_clear_stale_route(peer, afi, safi);
peer->nsf[afi][safi] = 1;
nsf_af_count++;
} else {
if (peer->nsf[afi][safi])
bgp_clear_stale_route(peer, afi, safi);
peer->nsf[afi][safi] = 0;
}
/* Update the graceful restart information */
if (peer->afc_nego[afi][safi]) {
if (!BGP_SELECT_DEFER_DISABLE(peer->bgp)) {
status = bgp_update_gr_info(peer, afi, safi);
if (status < 0)
zlog_err(
"Error in updating graceful restart for %s",
get_afi_safi_str(afi, safi,
false));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
} else {
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
if (BGP_PEER_GRACEFUL_RESTART_CAPABLE(peer) &&
BGP_PEER_RESTARTING_MODE(peer) &&
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
bgp_gr_is_forwarding_preserved(peer->bgp))
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
peer->bgp->gr_info[afi][safi]
.eor_required++;
bgpd: Adding Selection Deferral Timer handler changes. * Selection Deferral Timer for Graceful Restart. * Added selection deferral timer handling function. * Route marking as selection defer when update message is received. * Staggered processing of routes which are pending best selection. * Fix for multi-path test case. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 20:14:51 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
*: Add FOREACH_AFI_SAFI_NSF(afi, safi) macro to reduce nesting Used for graceful-restart mostly. Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi() Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2022-01-12 21:43:52 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: GR fixes 1) When a session comes up for a peer and if the peer has not adverised the GR capabilities, BGP sends a request to Zebra to clear any stale routes that might exist from that peer. 2) When OPEN message is received from the peer, clear the previously advertised GR capability by the peer, if the lastest received OPEN message does not contain the GR capability. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2020-06-16 14:20:41 +02:00
if (!CHECK_FLAG(peer->cap, PEER_CAP_RESTART_RCV)) {
if ((bgp_peer_gr_mode_get(peer) == PEER_GR)
|| ((bgp_peer_gr_mode_get(peer) == PEER_GLOBAL_INHERIT)
&& (bgp_global_gr_mode_get(peer->bgp) == GLOBAL_GR))) {
FOREACH_AFI_SAFI (afi, safi)
/* Send route processing complete
message to RIB */
bgp_zebra_update(
lib, bgpd: Add more debugs to GR Capability exchange a) Make it legible what type of message is being passed back and forth instead of having to guess it from the insufficient debugs b) Make it explicit which bgp instance is sending this data c) Cleanup bgp_zebra_update to have a cleaner api Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-09 14:36:51 +01:00
peer->bgp, afi, safi,
bgpd: GR fixes 1) When a session comes up for a peer and if the peer has not adverised the GR capabilities, BGP sends a request to Zebra to clear any stale routes that might exist from that peer. 2) When OPEN message is received from the peer, clear the previously advertised GR capability by the peer, if the lastest received OPEN message does not contain the GR capability. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2020-06-16 14:20:41 +02:00
ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE);
}
} else {
/* Peer sends R-bit. In this case, we need to send
* ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE to Zebra. */
bgpd: Implement CEASE/Hard Reset notification Also, add N-Bit (Notification) flag for Graceful Restart. This is a preparation for RFC8538. More information: https://datatracker.ietf.org/doc/html/rfc8538 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-04-30 22:04:58 +02:00
if (CHECK_FLAG(peer->cap,
PEER_CAP_GRACEFUL_RESTART_R_BIT_RCV)) {
bgpd: GR fixes 1) When a session comes up for a peer and if the peer has not adverised the GR capabilities, BGP sends a request to Zebra to clear any stale routes that might exist from that peer. 2) When OPEN message is received from the peer, clear the previously advertised GR capability by the peer, if the lastest received OPEN message does not contain the GR capability. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2020-06-16 14:20:41 +02:00
FOREACH_AFI_SAFI (afi, safi)
/* Send route processing complete
message to RIB */
bgp_zebra_update(
lib, bgpd: Add more debugs to GR Capability exchange a) Make it legible what type of message is being passed back and forth instead of having to guess it from the insufficient debugs b) Make it explicit which bgp instance is sending this data c) Cleanup bgp_zebra_update to have a cleaner api Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-09 14:36:51 +01:00
peer->bgp, afi, safi,
bgpd: GR fixes 1) When a session comes up for a peer and if the peer has not adverised the GR capabilities, BGP sends a request to Zebra to clear any stale routes that might exist from that peer. 2) When OPEN message is received from the peer, clear the previously advertised GR capability by the peer, if the lastest received OPEN message does not contain the GR capability. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
2020-06-16 14:20:41 +02:00
ZEBRA_CLIENT_ROUTE_UPDATE_COMPLETE);
}
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
peer->nsf_af_count = nsf_af_count;
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
if (nsf_af_count)
SET_FLAG(peer->sflags, PEER_STATUS_NSF_MODE);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
else {
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_MODE);
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
if (connection->t_gr_stale) {
EVENT_OFF(connection->t_gr_stale);
Overhual BGP debugs Summary of changes - added an option to enable keepalive debugs for a specific peer - added an option to enable inbound and/or outbound updates debugs for a specific peer - added an option to enable update debugs for a specific prefix - added an option to enable zebra debugs for a specific prefix - combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer. - merged "deb bgp filters" into "deb bgp update" - moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer. - Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols. - Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols. - Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing. The new parse tree for BGP debugging is: deb bgp as4 deb bgp as4 segment deb bgp keepalives [A.B.C.D|WORD|X:X::X:X] deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X] deb bgp nht deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X] deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M] deb bgp zebra deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
2015-05-20 02:58:12 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP graceful restart stalepath timer stopped for %s",
peer, bgp_peer_get_connection_direction(connection));
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
* bgp_fsm.c, bgp_open.c, bgp_packet.c, bgp_route.[ch], bgp_vty.c, bgpd.[ch]: Add BGP_INFO_STALE flag and end-of-rib support. "bgp graceful-restart" commands added. Show numbers of individual messages in "show ip bgp neighbor" command. Final pieces of graceful restart. [merge from GNU Zebra]
2005-02-02 15:40:33 +01:00
bgpd: move t_gr_restart and _stale into peer_connection The t_gr_restart and t_gr_stale event pointers belong into the peer_connection pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:16:29 +02:00
if (connection->t_gr_restart) {
EVENT_OFF(connection->t_gr_restart);
*: use hooks for sending SNMP traps This means there are no ties into the SNMP code anymore other than the init call at startup. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2016-06-12 17:32:23 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP graceful restart timer stopped for %s", peer,
bgp_peer_get_connection_direction(connection));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: batched i/o Instead of reading a packet header and the rest of the packet in two separate i/o cycles, instead read a chunk of data at one time and then parse as many packets as possible out of the chunk. Also changes bgp_packet.c to batch process packets. To avoid thrashing on useless mutex locks, the scheduling call for bgp_process_packet has been changed to always succeed at the cost of no longer being cancel-able. In this case this is acceptable; following the pattern of other event-based callbacks, an additional check in bgp_process_packet to ignore stray events is sufficient. Before deleting the peer all events are cleared which provides the requisite ordering. XXX: chunk hardcoded to 5, should use something similar to wpkt_quanta Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-06-02 03:52:39 +02:00
/* Reset uptime, turn on keepalives, send current table. */
if (!peer->v_holdtime)
bgpd: make bgp_keepalives_on|off connection oriented The bgp_keepalives_on|off functions should use a peer_connection as a basis for it's operation. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 03:34:59 +02:00
bgp_keepalives_on(connection);
bgpd: batched i/o Instead of reading a packet header and the rest of the packet in two separate i/o cycles, instead read a chunk of data at one time and then parse as many packets as possible out of the chunk. Also changes bgp_packet.c to batch process packets. To avoid thrashing on useless mutex locks, the scheduling call for bgp_process_packet has been changed to always succeed at the cost of no longer being cancel-able. In this case this is acceptable; following the pattern of other event-based callbacks, an additional check in bgp_process_packet to ignore stray events is sufficient. Before deleting the peer all events are cleared which provides the requisite ordering. XXX: chunk hardcoded to 5, should use something similar to wpkt_quanta Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-06-02 03:52:39 +02:00
bgpd: Convert from bgp_clock() to monotime() Let's convert to our actual library call instead of using yet another abstraction that makes it fun for people to switch daemons. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-08-18 00:27:54 +02:00
peer->uptime = monotime(NULL);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Stop LLGR timer when the connection is established When the connection goes up, the timer is not stopped and if we have a subsequent GR event we have an old timer which is not as we expect. Before: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 95 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:27:53 2022 Time until Long-lived stale route deleted: 23 <<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 08:43:29 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:43:30 2022 Time until Long-lived stale route deleted: 17 <<<<<<<<<<<<<<< ``` After: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 79 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (0.0.0.0) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:18 2022 Time until Long-lived stale route deleted: 24 <<<<<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 09:05:25 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:29 2022 Time until Long-lived stale route deleted: 29 <<<<<<<<<<<<<< ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-28 10:41:35 +02:00
/* Send route-refresh when ORF is enabled.
* Stop Long-lived Graceful Restart timers.
*/
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
FOREACH_AFI_SAFI (afi, safi) {
bgpd: Stop LLGR timer when the connection is established When the connection goes up, the timer is not stopped and if we have a subsequent GR event we have an old timer which is not as we expect. Before: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 95 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:27:53 2022 Time until Long-lived stale route deleted: 23 <<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 08:43:29 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:43:30 2022 Time until Long-lived stale route deleted: 17 <<<<<<<<<<<<<<< ``` After: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 79 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (0.0.0.0) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:18 2022 Time until Long-lived stale route deleted: 24 <<<<<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 09:05:25 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:29 2022 Time until Long-lived stale route deleted: 29 <<<<<<<<<<<<<< ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-28 10:41:35 +02:00
if (peer->t_llgr_stale[afi][safi]) {
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
EVENT_OFF(peer->t_llgr_stale[afi][safi]);
bgpd: Stop LLGR timer when the connection is established When the connection goes up, the timer is not stopped and if we have a subsequent GR event we have an old timer which is not as we expect. Before: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 95 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:27:53 2022 Time until Long-lived stale route deleted: 23 <<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 08:43:29 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:43:30 2022 Time until Long-lived stale route deleted: 17 <<<<<<<<<<<<<<< ``` After: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 79 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (0.0.0.0) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:18 2022 Time until Long-lived stale route deleted: 24 <<<<<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 09:05:25 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:29 2022 Time until Long-lived stale route deleted: 29 <<<<<<<<<<<<<< ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-28 10:41:35 +02:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%pBP Long-lived stale timer stopped for afi/safi: %d/%d for %s",
peer, afi, safi,
bgp_peer_get_connection_direction(connection));
bgpd: Stop LLGR timer when the connection is established When the connection goes up, the timer is not stopped and if we have a subsequent GR event we have an old timer which is not as we expect. Before: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 95 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:27:53 2022 Time until Long-lived stale route deleted: 23 <<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 08:43:29 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 103 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 08:43:30 2022 Time until Long-lived stale route deleted: 17 <<<<<<<<<<<<<<< ``` After: ``` spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 79 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (0.0.0.0) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:18 2022 Time until Long-lived stale route deleted: 24 <<<<<<<<<<<<<<< spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default) Advertised to non peer-group peers: 192.168.0.1 65001 47583 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Last update: Mon Mar 28 09:05:25 2022 spine1-debian-11# sh ip bgp 192.168.100.1/32 BGP routing table entry for 192.168.100.1/32, version 87 Paths: (1 available, best #1, table default, mark routes to be retained for a longer time. Requires support for Long-lived BGP Graceful Restart) Not advertised to any peer 65001 47583, (stale) 192.168.0.1 from 192.168.0.1 (100.100.200.100) Origin incomplete, valid, external, best (First path received) Community: llgr-stale Last update: Mon Mar 28 09:05:29 2022 Time until Long-lived stale route deleted: 29 <<<<<<<<<<<<<< ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-03-28 10:41:35 +02:00
}
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
if (CHECK_FLAG(peer->af_cap[afi][safi],
PEER_CAP_ORF_PREFIX_SM_ADV)) {
Initial revision
2002-12-13 21:15:29 +01:00
if (CHECK_FLAG(peer->af_cap[afi][safi],
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
PEER_CAP_ORF_PREFIX_RM_RCV))
bgpd: Implement enhanced route refresh capability 16:40:49 BGP: 192.168.0.2: sending route-refresh (BoRR) for IPv4/unicast 16:40:51 BGP: 192.168.0.2: sending route-refresh (EoRR) for IPv4/unicast Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-10-01 22:08:06 +02:00
bgp_route_refresh_send(
peer, afi, safi, ORF_TYPE_PREFIX,
REFRESH_IMMEDIATE, 0,
BGP_ROUTE_REFRESH_NORMAL);
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
}
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* First update is deferred until ORF or ROUTE-REFRESH is received */
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
FOREACH_AFI_SAFI (afi, safi) {
if (CHECK_FLAG(peer->af_cap[afi][safi],
PEER_CAP_ORF_PREFIX_RM_ADV))
Initial revision
2002-12-13 21:15:29 +01:00
if (CHECK_FLAG(peer->af_cap[afi][safi],
bgpd: Deprecate Prestandard Outbound Route Filtering capability https://www.rfc-editor.org/rfc/rfc8810.html Not relevant anymore. Use RFC'd version of ORF. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-07-07 22:39:44 +02:00
PEER_CAP_ORF_PREFIX_SM_RCV))
bgpd: use FOREACH_AFI_SAFI where possible Improves consistency and readability. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-11-21 19:02:06 +01:00
SET_FLAG(peer->af_sflags[afi][safi],
PEER_STATUS_ORF_WAIT_REFRESH);
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
BGP: Add dynamic update group support This patch implements the 'update-groups' functionality in BGP. This is a function that can significantly improve BGP performance for Update generation and resultant network convergence. BGP Updates are formed for "groups" of peers and then replicated and sent out to each peer rather than being formed for each peer. Thus major BGP operations related to outbound policy application, adj-out maintenance and actual Update packet formation are optimized. BGP update-groups dynamically groups peers together based on configuration as well as run-time criteria. Thus, it is more flexible than update-formation based on peer-groups, which relies on operator configuration. [Note that peer-group based update formation has been introduced into BGP by Cumulus but is currently intended only for specific releases.] From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001 Subject: [PATCH] updgrp commits
2015-05-20 03:03:47 +02:00
bgp_announce_peer(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/* Start the route advertisement timer to send updates to the peer - if
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* BGP
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
* is not in read-only mode. If it is, the timer will be started at the
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
* end
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
* of read-only mode.
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
*/
bgpd: bgpd-mrai.patch BGP: Event-driven route announcement taking into account min route advertisement interval ISSUE BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec when a peer is established. From then on, the timer expires periodically based on the configured MRAI value (default: 30sec for EBGP, 5sec for IBGP). At the expiry, the write thread is triggered that takes the routes from peer's sync FIFO (adj-rib-out) and sends UPDATEs. This has a few drawbacks: (1) Delay in new route announcement: Even when the last UPDATE message was sent a while back, the next route change will necessarily have to wait for routeadv expiry (2) CPU usage: The timer is always armed. If the operator chooses to configure a lower value of MRAI (zero second is a preferred choice in many deployments) for better convergence, it leads to high CPU usage for BGP process, even at the times of no network churn. PATCH Make the route advertisement event-driven - When routes are added to peer's sync FIFO, check if the routeadv timer needs to be adjusted (or started). Conversely, do not arm the routeadv timer unconditionally. The patch also addresses route announcements during read-only mode (update-delay). During read-only mode operation, the routeadv timer is not started. When BGP comes out of read-only mode and all the routes are processed, the timer is started for all peers with zero expiry, so that the UPDATEs can be sent all at once. This leads to (near-)optimal UPDATE packing. Finally, the patch makes the "max # packets to write to peer socket at a time" configurable. Currently it is hard-coded to 10. The command is at the top router-bgp mode and is called "write-quanta <number>". It is a useful convergence parameter to tweak. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
if (!bgp_update_delay_active(peer->bgp)) {
bgpd: move t_routeadv to peer_connection The t_routeadv belongs to the peer_connection data structure Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:44:23 +02:00
EVENT_OFF(peer->connection->t_routeadv);
BGP_TIMER_ON(peer->connection->t_routeadv, bgp_routeadv_timer,
0);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Move status and ostatus to `struct peer_connection` The status and ostatus are a function of the `struct peer_connection` move it into that data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-06-03 23:13:52 +02:00
if (peer->doppelganger &&
bgpd: Convert `struct peer_connection` to dynamically allocated As part of the conversion to a `struct peer_connection` it will be desirable to have 2 pointers one for when we open a connection and one for when we receive a connection. Start this actual conversion over to this in `struct peer`. If this sounds confusing take a look at the bgp state machine for connections and how it resolves the processing of this router opening -vs- this router receiving an open. At some point in time the state machine decides that we are keeping one of the two connections. Future commits will allow us to untangle the peer/doppelganger duality with this abstraction. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 05:43:46 +02:00
(peer->doppelganger->connection->status != Deleted)) {
Initial revision
2002-12-13 21:15:29 +01:00
if (bgp_debug_neighbor_events(peer))
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("[Event] Deleting stub connection for peer %s for %s", peer->host,
bgp_peer_get_connection_direction(peer->doppelganger->connection));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Convert `struct peer_connection` to dynamically allocated As part of the conversion to a `struct peer_connection` it will be desirable to have 2 pointers one for when we open a connection and one for when we receive a connection. Start this actual conversion over to this in `struct peer`. If this sounds confusing take a look at the bgp state machine for connections and how it resolves the processing of this router opening -vs- this router receiving an open. At some point in time the state machine decides that we are keeping one of the two connections. Future commits will allow us to untangle the peer/doppelganger duality with this abstraction. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 05:43:46 +02:00
if (peer->doppelganger->connection->status > Active)
bgpd: bgp_notify_send use peer_connection instead of peer The bgp_notify_send function should use a peer_connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-26 23:30:10 +02:00
bgp_notify_send(peer->doppelganger->connection,
BGP_NOTIFY_CEASE,
Initial revision
2002-12-13 21:15:29 +01:00
BGP_NOTIFY_CEASE_COLLISION_RESOLUTION);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
else
Initial revision
2002-12-13 21:15:29 +01:00
peer_delete(peer->doppelganger);
}
bgpd: Do a bit better job of tracking the bgp->peerhash When we add/remove peers we need to do a bit better job of tracking them in the bgp->peerhash. 1) When we have the doppelganger take over, make sure the winner is the one represented in the peerhash. 2) When creating the doppelganger, leave the current one in place instead of blindly replacing it. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-10-08 02:34:31 +02:00
/*
* If we are replacing the old peer for a doppelganger
* then switch it around in the bgp->peerhash
* the doppelgangers su and this peer's su are the same
* so the hash_release is the same for either.
*/
*: remove the checking returned value for hash_get() Firstly, *keep no change* for `hash_get()` with NULL `alloc_func`. Only focus on cases with non-NULL `alloc_func` of `hash_get()`. Since `hash_get()` with non-NULL `alloc_func` parameter shall not fail, just ignore the returned value of it. The returned value must not be NULL. So in this case, remove the unnecessary checking NULL or not for the returned value and add `void` in front of it. Importantly, also *keep no change* for the two cases with non-NULL `alloc_func` - 1) Use `assert(<returned_data> == <searching_data>)` to ensure it is a created node, not a found node. Refer to `isis_vertex_queue_insert()` of isisd, there are many examples of this case in isid. 2) Use `<returned_data> != <searching_data>` to judge it is a found node, then free <searching_data>. Refer to `aspath_intern()` of bgpd, there are many examples of this case in bgpd. Here, <returned_data> is the returned value from `hash_get()`, and <searching_data> is the data, which is to be put into hash table. Signed-off-by: anlan_cs <vic.lan@pica8.com>
2022-04-21 08:37:12 +02:00
(void)hash_get(peer->bgp->peerhash, peer, hash_alloc_intern);
bgpd: Do a bit better job of tracking the bgp->peerhash When we add/remove peers we need to do a bit better job of tracking them in the bgp->peerhash. 1) When we have the doppelganger take over, make sure the winner is the one represented in the peerhash. 2) When creating the doppelganger, leave the current one in place instead of blindly replacing it. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-10-08 02:34:31 +02:00
bgpd: rework BFD integration Remove old BFD API usage and replace it with the new one. Highlights: - More shared code: the daemon gets notified with callbacks instead of having to roll its own code to find the notified sessions. - Less code to integrate with BFD. - Remove hidden commands to configure single / multi hop. Use protocol data instead. BGP can determine if a peer is single/multi hop according to the following criteria: a. If the IP address is a link-local address (single hop) b. The network is shared with peer (single hop) c. BGP is configured for eBGP multi hop / TTL security (multi hop) - Respect the configuration hierarchy: a. Peer configuration take precendence over peer-group configuration. b. When peer group configuration is removed, reset peer BFD configurations to defaults (unless peer had specific configs). Example: neighbor foo peer-group neighbor foo bfd profile X neighbor 192.168.0.2 peer-group foo neighbor 192.168.0.2 bfd ! If peer-group is removed the profile configuration gets ! removed from peer 192.168.0.2, but BFD will still enabled ! because of the neighbor specific bfd configuration. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2021-02-26 20:50:51 +01:00
/* Start BFD peer if not already running. */
if (peer->bfd_config)
bgp_peer_bfd_update_source(peer);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
return ret;
Initial revision
2002-12-13 21:15:29 +01:00
}
/* Keepalive packet is received. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_keepalive(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: t_holdtime move to peer_connection The t_holdtime event pointer belongs in the peer connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:36:34 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
/* Update packet is received. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_update(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: t_holdtime move to peer_connection The t_holdtime event pointer belongs in the peer connection Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 01:36:34 +02:00
EVENT_OFF(connection->t_holdtime);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
/* This is empty event. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress bgp_ignore(struct peer_connection *connection)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_BGP_FSM,
"%s [FSM] Ignoring event %s in state %s, prior events %s, %s, fd %d",
peer->host, bgp_event_str[peer->cur_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
lookup_msg(bgp_status_msg, connection->status, NULL),
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
bgp_event_str[peer->last_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_event_str[peer->last_major_event], connection->fd);
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
return BGP_FSM_SUCCESS;
Initial revision
2002-12-13 21:15:29 +01:00
}
*: nuke ^L (page feed) Quagga sources have inherited a slew of Page Feed (^L, \xC) characters from ancient history. Among other things, these break patchwork's XML-RPC API because \xC is not a valid character in XML documents. Nuke them from high orbit. Patches can be adapted simply by: sed -e 's%^L%%' -i filename.patch (you can type page feeds in some environments with Ctrl-V Ctrl-L) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2014-06-04 06:53:35 +02:00
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
/* This is to handle unexpected events.. */
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
static enum bgp_fsm_state_progress
bgp_fsm_exception(struct peer_connection *connection)
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
{
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
struct peer *peer = connection->peer;
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_BGP_FSM,
"%s [FSM] Unexpected event %s in state %s, prior events %s, %s, fd %d",
peer->host, bgp_event_str[peer->cur_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
lookup_msg(bgp_status_msg, connection->status, NULL),
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
bgp_event_str[peer->last_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_event_str[peer->last_major_event], connection->fd);
return bgp_stop(connection);
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
}
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
void bgp_fsm_nht_update(struct peer_connection *connection, struct peer *peer,
bool has_valid_nexthops)
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
{
if (!peer)
return;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
switch (connection->status) {
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
case Idle:
bgpd: rename bgp_fsm_event_update This function is poorly named; it's really used to allow the FSM to decide the next valid state based on whether a peer has valid / reachable nexthops as determined by NHT or BFD. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-09-17 18:38:12 +02:00
if (has_valid_nexthops)
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
BGP_EVENT_ADD(connection, BGP_Start);
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
break;
case Connect:
bgpd: rename bgp_fsm_event_update This function is poorly named; it's really used to allow the FSM to decide the next valid state based on whether a peer has valid / reachable nexthops as determined by NHT or BFD. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-09-17 18:38:12 +02:00
if (!has_valid_nexthops) {
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
EVENT_OFF(connection->t_connect);
BGP_EVENT_ADD(connection, TCP_fatal_error);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
break;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
case Active:
bgpd: rename bgp_fsm_event_update This function is poorly named; it's really used to allow the FSM to decide the next valid state based on whether a peer has valid / reachable nexthops as determined by NHT or BFD. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-09-17 18:38:12 +02:00
if (has_valid_nexthops) {
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
EVENT_OFF(connection->t_connect);
BGP_EVENT_ADD(connection, ConnectRetry_timer_expired);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
}
break;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
case OpenSent:
case OpenConfirm:
case Established:
bgpd: rename bgp_fsm_event_update This function is poorly named; it's really used to allow the FSM to decide the next valid state based on whether a peer has valid / reachable nexthops as determined by NHT or BFD. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-09-17 18:38:12 +02:00
if (!has_valid_nexthops
bgpd: BGP knob to teardown session immediately when peer is unreachable When BGP is notified by RIB that peer address is unreachable then BGP session must be brought down immediately and not wait for the hold-timer expiry. Today single-hop EBGP already behaves this way but need to change for iBGP and multi-hop EBGP sessions. Signed-off-by: Prerana G.B <prerana@vmware.com>, Pushpasis Sarkar <spushpasis@vmware.com>
2021-08-06 17:17:04 +02:00
&& (peer->gtsm_hops == BGP_GTSM_HOPS_CONNECTED
|| peer->bgp->fast_convergence))
bgpd: Convert bgp_fsm_nht_update to take a connection Convert this function over to using a connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-28 16:47:41 +02:00
BGP_EVENT_ADD(connection, TCP_fatal_error);
build: add -Wimplicit-fallthrough Also: - replace all /* fallthrough */ comments with portable fallthrough; pseudo keyword to accomodate both gcc and clang - add missing break; statements as required by older versions of gcc - cleanup some code to remove unnecessary fallthrough Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2023-10-10 23:15:32 +02:00
break;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
case Clearing:
case Deleted:
bgpd: Add missing enum's to case statement Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-01-30 16:05:41 +01:00
case BGP_STATUS_MAX:
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
break;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
}
}
Initial revision
2002-12-13 21:15:29 +01:00
/* Finite State Machine structure */
[bgpd/cleanup] Make BGP FSM table read-only static The finite state machine table is immutable.
2009-05-15 19:02:27 +02:00
static const struct {
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
enum bgp_fsm_state_progress (*func)(struct peer_connection *);
bgpd: Convert status defines to enum Convert some status defines for the fsm to an enum so that we cannot mix and match them in the future. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-03-20 14:03:08 +01:00
enum bgp_fsm_status next_state;
Initial revision
2002-12-13 21:15:29 +01:00
} FSM[BGP_STATUS_MAX - 1][BGP_EVENTS_MAX - 1] = {
{
/* Idle state: In Idle state, all events other than BGP_Start is
ignored. With BGP_Start event, finite state machine calls
bgp_start(). */
{bgp_start, Connect}, /* BGP_Start */
{bgp_stop, Idle}, /* BGP_Stop */
{bgp_stop, Idle}, /* TCP_connection_open */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_stop, Idle}, /* TCP_connection_open_w_delay */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_stop, Idle}, /* TCP_connection_closed */
{bgp_ignore, Idle}, /* TCP_connection_open_failed */
{bgp_stop, Idle}, /* TCP_fatal_error */
{bgp_ignore, Idle}, /* ConnectRetry_timer_expired */
{bgp_ignore, Idle}, /* Hold_Timer_expired */
{bgp_ignore, Idle}, /* KeepAlive_timer_expired */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_ignore, Idle}, /* DelayOpen_timer_expired */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_ignore, Idle}, /* Receive_OPEN_message */
{bgp_ignore, Idle}, /* Receive_KEEPALIVE_message */
{bgp_ignore, Idle}, /* Receive_UPDATE_message */
{bgp_ignore, Idle}, /* Receive_NOTIFICATION_message */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_ignore, Idle}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
{
/* Connect */
{bgp_ignore, Connect}, /* BGP_Start */
{bgp_stop, Idle}, /* BGP_Stop */
{bgp_connect_success, OpenSent}, /* TCP_connection_open */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_connect_success_w_delayopen,
Connect}, /* TCP_connection_open_w_delay */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_stop, Idle}, /* TCP_connection_closed */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_connect_fail, Active}, /* TCP_connection_open_failed */
{bgp_connect_fail, Idle}, /* TCP_fatal_error */
{bgp_reconnect, Connect}, /* ConnectRetry_timer_expired */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Hold_Timer_expired */
{bgp_fsm_exception, Idle}, /* KeepAlive_timer_expired */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_fsm_delayopen_timer_expire,
OpenSent}, /* DelayOpen_timer_expired */
{bgp_fsm_open, OpenConfirm}, /* Receive_OPEN_message */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Receive_KEEPALIVE_message */
{bgp_fsm_exception, Idle}, /* Receive_UPDATE_message */
{bgp_stop, Idle}, /* Receive_NOTIFICATION_message */
{bgp_fsm_exception, Idle}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
{
/* Active, */
{bgp_ignore, Active}, /* BGP_Start */
{bgp_stop, Idle}, /* BGP_Stop */
{bgp_connect_success, OpenSent}, /* TCP_connection_open */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_connect_success_w_delayopen,
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
Active}, /* TCP_connection_open_w_delay */
{bgp_stop, Idle}, /* TCP_connection_closed */
{bgp_ignore, Active}, /* TCP_connection_open_failed */
{bgp_fsm_exception, Idle}, /* TCP_fatal_error */
{bgp_start, Connect}, /* ConnectRetry_timer_expired */
{bgp_fsm_exception, Idle}, /* Hold_Timer_expired */
{bgp_fsm_exception, Idle}, /* KeepAlive_timer_expired */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_fsm_delayopen_timer_expire,
OpenSent}, /* DelayOpen_timer_expired */
{bgp_fsm_open, OpenConfirm}, /* Receive_OPEN_message */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Receive_KEEPALIVE_message */
{bgp_fsm_exception, Idle}, /* Receive_UPDATE_message */
{bgp_fsm_exception, Idle}, /* Receive_NOTIFICATION_message */
{bgp_fsm_exception, Idle}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
{
/* OpenSent, */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_ignore, OpenSent}, /* BGP_Start */
{bgp_stop, Idle}, /* BGP_Stop */
{bgp_stop, Active}, /* TCP_connection_open */
{bgp_fsm_exception, Idle}, /* TCP_connection_open_w_delay */
{bgp_stop, Active}, /* TCP_connection_closed */
{bgp_stop, Active}, /* TCP_connection_open_failed */
{bgp_stop, Active}, /* TCP_fatal_error */
{bgp_fsm_exception, Idle}, /* ConnectRetry_timer_expired */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_fsm_holdtime_expire, Idle}, /* Hold_Timer_expired */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* KeepAlive_timer_expired */
{bgp_fsm_exception, Idle}, /* DelayOpen_timer_expired */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_fsm_open, OpenConfirm}, /* Receive_OPEN_message */
bgpd: stricter packet handling in OpenSent Keepalives and updates are not expected in OpenSent, prior to receiving the peer's open message. Terminate the session with the proper notification. From: Leonid Rosenboim <lrosenbo@wrs.com> [split off FSM changes, some reordering & cleanup. read handling needs to be separately addressed] Signed-off-by: David Lamparter <equinox@diac24.net>
2013-07-30 20:14:25 +02:00
{bgp_fsm_event_error, Idle}, /* Receive_KEEPALIVE_message */
{bgp_fsm_event_error, Idle}, /* Receive_UPDATE_message */
bgpd: Send notification to the peer on FSM error We should send a NOTIFICATION message with the Error Code Finite State Machine Error if we receive NOTIFICATION in OpenSent state as defined in https://tools.ietf.org/html/rfc4271#section-8.2.2 Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2019-12-30 16:11:04 +01:00
{bgp_fsm_event_error, Idle}, /* Receive_NOTIFICATION_message */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
{
/* OpenConfirm, */
{bgp_ignore, OpenConfirm}, /* BGP_Start */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_stop, Idle}, /* BGP_Stop */
{bgp_stop, Idle}, /* TCP_connection_open */
{bgp_fsm_exception, Idle}, /* TCP_connection_open_w_delay */
{bgp_stop, Idle}, /* TCP_connection_closed */
{bgp_stop, Idle}, /* TCP_connection_open_failed */
{bgp_stop, Idle}, /* TCP_fatal_error */
{bgp_fsm_exception, Idle}, /* ConnectRetry_timer_expired */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_fsm_holdtime_expire, Idle}, /* Hold_Timer_expired */
{bgp_ignore, OpenConfirm}, /* KeepAlive_timer_expired */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* DelayOpen_timer_expired */
{bgp_fsm_exception, Idle}, /* Receive_OPEN_message */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_establish, Established}, /* Receive_KEEPALIVE_message */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Receive_UPDATE_message */
Initial revision
2002-12-13 21:15:29 +01:00
{bgp_stop_with_error, Idle}, /* Receive_NOTIFICATION_message */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
{
/* Established, */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_ignore, Established}, /* BGP_Start */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_stop, Clearing}, /* BGP_Stop */
{bgp_stop, Clearing}, /* TCP_connection_open */
{bgp_fsm_exception, Idle}, /* TCP_connection_open_w_delay */
{bgp_stop, Clearing}, /* TCP_connection_closed */
{bgp_stop, Clearing}, /* TCP_connection_open_failed */
{bgp_stop, Clearing}, /* TCP_fatal_error */
{bgp_stop, Clearing}, /* ConnectRetry_timer_expired */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_fsm_holdtime_expire, Clearing}, /* Hold_Timer_expired */
bgpd: put BGP keepalives in a pthread This patch, in tandem with moving packet writes into a dedicated kernel thread, fixes session flaps caused by long-running internal operations starving the (old) userspace write thread. BGP keepalives are now produced by a kernel thread and placed onto the peer's output queue. These are then consumed by the write thread. Both of these tasks are concurrent with the rest of bgpd, obviating the session flaps described above. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-01-06 00:13:16 +01:00
{bgp_ignore, Established}, /* KeepAlive_timer_expired */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_fsm_exception, Idle}, /* DelayOpen_timer_expired */
{bgp_stop, Clearing}, /* Receive_OPEN_message */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_fsm_keepalive,
Established}, /* Receive_KEEPALIVE_message */
{bgp_fsm_update, Established}, /* Receive_UPDATE_message */
{bgp_stop_with_error,
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
Clearing}, /* Receive_NOTIFICATION_message */
{bgp_fsm_exception, Idle}, /* Clearing_Completed */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
},
{
/* Clearing, */
{bgp_ignore, Clearing}, /* BGP_Start */
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
{bgp_stop, Clearing}, /* BGP_Stop */
{bgp_stop, Clearing}, /* TCP_connection_open */
{bgp_stop, Clearing}, /* TCP_connection_open_w_delay */
{bgp_stop, Clearing}, /* TCP_connection_closed */
{bgp_stop, Clearing}, /* TCP_connection_open_failed */
{bgp_stop, Clearing}, /* TCP_fatal_error */
{bgp_stop, Clearing}, /* ConnectRetry_timer_expired */
{bgp_stop, Clearing}, /* Hold_Timer_expired */
{bgp_stop, Clearing}, /* KeepAlive_timer_expired */
{bgp_stop, Clearing}, /* DelayOpen_timer_expired */
{bgp_stop, Clearing}, /* Receive_OPEN_message */
{bgp_stop, Clearing}, /* Receive_KEEPALIVE_message */
{bgp_stop, Clearing}, /* Receive_UPDATE_message */
{bgp_stop, Clearing}, /* Receive_NOTIFICATION_message */
bgpd: fd leak in bgpd * bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new' Clearing state. I've been seeing it from hold timer failures, but it can also be triggered by other things. When Hold_Timer_expired fires in Established state, a notify is sent and BGP_Stop event queued. The fsm then transitions into Clearing state. That is the problem; When the BGP_Stop event is serviced, the state table says to ignore it while in Clearing. Thus bgp_stop is not called and the fd leaks. Previously the peer would be in Idle state, which correctly handles the BGP_Stop event. Fix by making bgp_stop safe to call from Clearing state, without losing ClearingCompleted events, and then ensuring it is called prior to transition from Clearing->Idle.
2009-07-28 18:50:00 +02:00
{bgp_clearing_completed, Idle}, /* Clearing_Completed */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
},
{
/* Deleted, */
{bgp_ignore, Deleted}, /* BGP_Start */
{bgp_ignore, Deleted}, /* BGP_Stop */
{bgp_ignore, Deleted}, /* TCP_connection_open */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_ignore, Deleted}, /* TCP_connection_open_w_delay */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_ignore, Deleted}, /* TCP_connection_closed */
{bgp_ignore, Deleted}, /* TCP_connection_open_failed */
{bgp_ignore, Deleted}, /* TCP_fatal_error */
{bgp_ignore, Deleted}, /* ConnectRetry_timer_expired */
{bgp_ignore, Deleted}, /* Hold_Timer_expired */
{bgp_ignore, Deleted}, /* KeepAlive_timer_expired */
bgpd: RFC 4271 DelayOpenTimer Changes implement the DelayOpenTimer functionality proposed in RFC 4271. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-10-20 16:49:58 +02:00
{bgp_ignore, Deleted}, /* DelayOpen_timer_expired */
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states 2006-09-14 Paul Jakma <paul.jakma@sun.com> * (general) Fix some niggly issues around 'shutdown' and clearing by adding a Clearing FSM wait-state and a hidden 'Deleted' FSM state, to allow deleted peers to 'cool off' and hit 0 references. This introduces a slow memory leak of struct peer, however that's more a testament to the fragility of the reference counting than a bug in this patch, cleanup of reference counting to fix this is to follow. * bgpd.h: Add Clearing, Deleted states and Clearing_Completed and event. * bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and Deleted. * bgp_fsm.h: Don't allow timer/event threads to set anything for Deleted peers. * bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted needs to stop everything. (bgp_stop) Remove explicit fsm_change_status call, the general framework handles the transition. (bgp_start) Log a warning if a start is attempted on a peer that should stay down, trying to start a peer. (struct .. FSM) Add Clearing_Completed events, has little influence except when in state Clearing to signal wait-state can end. Add Clearing and Deleted states, former is a wait-state, latter is a placeholder state to allow peers to disappear quietly once refcounts settle. (bgp_event) Try reduce verbosity of FSM state-change debug, changes to same state are not interesting (Established->Established) Allow NULL action functions in FSM. * bgp_packet.c: (bgp_write) Use FSM events, rather than trying to twiddle directly with FSM state behind the back of FSM. (bgp_write_notify) ditto. (bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else this patch crashes, now it leaks instead. * bgp_route.c: (bgp_clear_node_complete) Clearing_Completed event, to end clearing. (bgp_clear_route) See extensive comments. * bgpd.c: (peer_free) should only be called while in Deleted, peer refcounting controls when peer_free is called. bgp_sync_delete should be here, not in peer_delete. (peer_delete) Initiate delete. Transition to Deleted state manually. When removing peer from indices that provide visibility of it, take great care to be idempotent wrt the reference counting of struct peer through those indices. Use bgp_timer_set, rather than replicating. Call to bgp_sync_delete isn't appropriate here, sync can be referenced while shutting down and finishing deletion. (peer_group_bind) Take care to be idempotent wrt list references indexing peers.
2006-09-14 04:58:49 +02:00
{bgp_ignore, Deleted}, /* Receive_OPEN_message */
{bgp_ignore, Deleted}, /* Receive_KEEPALIVE_message */
{bgp_ignore, Deleted}, /* Receive_UPDATE_message */
{bgp_ignore, Deleted}, /* Receive_NOTIFICATION_message */
{bgp_ignore, Deleted}, /* Clearing_Completed */
Initial revision
2002-12-13 21:15:29 +01:00
},
};
/* Execute event process. */
*: Rename `struct thread` to `struct event` Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-03-01 22:18:12 +01:00
void bgp_event(struct event *thread)
Initial revision
2002-12-13 21:15:29 +01:00
{
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer_connection *connection = EVENT_ARG(thread);
bgpd: Convert #define of bgp fsm events to an enum In PR #6052 which fixes issue #5963 the bgp fsm events were confused with the bgp fsm status leading to a bug. Let's start separating those out so these types of failures cannot just easily occur. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-03-20 01:19:50 +01:00
enum bgp_fsm_events event;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer *peer = connection->peer;
Initial revision
2002-12-13 21:15:29 +01:00
*: Convert THREAD_XXX macros to EVENT_XXX macros Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-25 16:26:52 +01:00
event = EVENT_VAL(thread);
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Fix several use after free's in bgp for the peer Three fixes: a) When calling bgp_fsm_change_status with `Deleted` do not add a new event to the peer's t_event because we are already in the process of deleting everything b) When bgp_stop decides to delete a peer return a notification that it is happening to bgp_event_update so that it does not set the peer state back to idle or do other processing. c) bgp_event_update can cause a peer deletion, because the peer can be deleted in the fsm function but the peer data structure is still pointed to and used after words. So lock the peer before entering and prevent a use after free. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-01 19:12:40 +01:00
peer_lock(peer);
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_event_update(connection, event);
bgpd: Fix several use after free's in bgp for the peer Three fixes: a) When calling bgp_fsm_change_status with `Deleted` do not add a new event to the peer's t_event because we are already in the process of deleting everything b) When bgp_stop decides to delete a peer return a notification that it is happening to bgp_event_update so that it does not set the peer state back to idle or do other processing. c) bgp_event_update can cause a peer deletion, because the peer can be deleted in the fsm function but the peer data structure is still pointed to and used after words. So lock the peer before entering and prevent a use after free. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-01 19:12:40 +01:00
peer_unlock(peer);
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
int bgp_event_update(struct peer_connection *connection,
enum bgp_fsm_events event)
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
{
bgpd: Convert status defines to enum Convert some status defines for the fsm to an enum so that we cannot mix and match them in the future. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2020-03-20 14:03:08 +01:00
enum bgp_fsm_status next;
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
enum bgp_fsm_state_progress ret = 0;
bgpd: bgp_event_update mixes enum's with a non-enum Straighten out the code to not mix the two. Especially since bgp was assigning non enum values to the enum. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:03:14 +02:00
int fsm_result = FSM_PEER_NOOP;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
int passive_conn = 0;
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
int dyn_nbr;
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
struct peer *peer = connection->peer;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
passive_conn =
(CHECK_FLAG(peer->sflags, PEER_STATUS_ACCEPT_PEER)) ? 1 : 0;
This patch adds support for allowing BGP to create and bring up neighbor sessions dynamically. The operator configures a range of neighbor addresses to which peering is allowed. The ranges are configured as subnets and multiple ranges are allowed. Each range is associated with a peer-group so that additional parameters can be configured. BGP neighbor sessions are dynamically created when connections are initiated by remote neighbors whose addresses fall within a configured range. The sessions are deleted when the BGP connection terminates. A limit on the number of neighbors allowed from each range of addresses can be specified. IPv4 and IPv6 peering is supported. Over the peering, any of the address families configured for the peer-group can be negotiated.
2015-05-20 03:03:47 +02:00
dyn_nbr = peer_dynamic_neighbor(peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Logging this event. */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
next = FSM[connection->status - 1][event - 1].next_state;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (bgp_debug_neighbor_events(peer) && connection->status != next)
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
zlog_debug("%s [FSM] %s (%s->%s), fd %d for %s", peer->host, bgp_event_str[event],
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
lookup_msg(bgp_status_msg, connection->status, NULL),
bgpd: Add connection direction to debug logs Currently the incoming and outgoing connections mix up their logs and there is absolutely no way to tell which way is being talked about when both are operating. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-02-16 00:47:21 +01:00
lookup_msg(bgp_status_msg, next, NULL), connection->fd,
bgp_peer_get_connection_direction(connection));
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
When unexpected events are received, do not silently transition to Idle state through bgp_ignore() as that may not do required cleanup. Instead, define a new event handler to handle such cases, which will go through bgp_stop(). A similar change is also done to handle the case where an event handler fails. Also add a couple of variables to keep track of events for a peer.
2015-05-20 03:04:12 +02:00
peer->last_event = peer->cur_event;
peer->cur_event = event;
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
Initial revision
2002-12-13 21:15:29 +01:00
/* Call function. */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (FSM[connection->status - 1][event - 1].func)
ret = (*(FSM[connection->status - 1][event - 1].func))(
connection);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: bgp_event_update switch to a switch The return code from a event handling perspective is an enum. Let's intentionally make it a switch so that all cases are ensured to be covered now and in the future. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:28:02 +02:00
switch (ret) {
case BGP_FSM_SUCCESS:
case BGP_FSM_SUCCESS_STATE_TRANSFER:
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
if (ret == BGP_FSM_SUCCESS_STATE_TRANSFER &&
next == Established) {
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
/* The case when doppelganger swap accurred in
bgp_establish.
Update the peer pointer accordingly */
bgpd: bgp_event_update mixes enum's with a non-enum Straighten out the code to not mix the two. Especially since bgp was assigning non enum values to the enum. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:03:14 +02:00
fsm_result = FSM_PEER_TRANSFERRED;
bgpd: bgpd-fsm-fix.patch BGP: Fix FSM to handle active/passive connections better The existing code didn't work well when dual connections resulted between peers during session bringup. This patch fixes that. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
}
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
/* If status is changed. */
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
if (next != connection->status) {
bgp_fsm_change_status(connection, next);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd, tests: comment formatting Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-08 17:51:12 +02:00
/*
* If we're going to ESTABLISHED then we executed a
* peer transfer. In this case we can either return
* FSM_PEER_TRANSITIONED or FSM_PEER_TRANSFERRED.
* Opting for TRANSFERRED since transfer implies
* session establishment.
*/
bgpd: bgp_event_update mixes enum's with a non-enum Straighten out the code to not mix the two. Especially since bgp was assigning non enum values to the enum. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:03:14 +02:00
if (fsm_result != FSM_PEER_TRANSFERRED)
fsm_result = FSM_PEER_TRANSITIONED;
bgpd: fix bgp_packet.c / bgp_fsm.c organization Despaghettification of bgp_packet.c and bgp_fsm.c Sometimes we call bgp_event_update() inline packet parsing. Sometimes we post events instead. Sometimes we increment packet counters in the FSM. Sometimes we do it in packet routines. Sometimes we update EOR's in FSM. Sometimes we do it in packet routines. Fix the madness. bgp_process_packet() is now the centralized place to: - Update message counters - Execute FSM events in response to incoming packets FSM events are now executed directly from this function instead of being queued on the thread_master. This is to ensure that the FSM contains the proper state after each packet is parsed. Otherwise there could be race conditions where two packets are parsed in succession without the appropriate FSM update in between, leading to session closure due to receiving inappropriate messages for the current FSM state. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-06-10 03:01:56 +02:00
}
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
/* Make sure timer is set. */
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
bgp_timer_set(connection);
bgpd: bgp_event_update switch to a switch The return code from a event handling perspective is an enum. Let's intentionally make it a switch so that all cases are ensured to be covered now and in the future. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:28:02 +02:00
break;
case BGP_FSM_FAILURE:
bgpd, tests: comment formatting Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-09-08 17:51:12 +02:00
/*
* If we got a return value of -1, that means there was an
* error, restart the FSM. Since bgp_stop() was called on the
* peer. only a few fields are safe to access here. In any case
* we need to indicate that the peer was stopped in the return
* code.
*/
bgpd: Change fsm to use an enum for passing state The BGP fsm uses return codes to pass event success/fail as well as some extra data to the bgp_event_update function. Convert this to use a enum instead of an int to track the changes. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-12-05 16:10:36 +01:00
if (!dyn_nbr && !passive_conn && peer->bgp &&
ret != BGP_FSM_FAILURE_AND_DELETE) {
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
flog_err(EC_BGP_FSM,
"%s [FSM] Failure handling event %s in state %s, prior events %s, %s, fd %d, last reset: %s",
peer->host, bgp_event_str[peer->cur_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
lookup_msg(bgp_status_msg, connection->status,
NULL),
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
bgp_event_str[peer->last_event],
bgp_event_str[peer->last_major_event],
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
connection->fd,
bgpd: Start abstraction of `struct peer_connection` BGP tracks connections based upon the peer. But the problem with this is that the doppelganger structure for it is being created. This has introduced a bunch of fragileness in that the peer exists independently of the connections to it. The whole point of the doppelganger structure was to allow BGP to both accept and initiate tcp connections and then when we get one to a `good` state we collapse into the appropriate one. The problem with this is that having 2 peer structures for this creates a situation where we have to make sure we are configing the `right` one and also make sure that we collapse the two independent peer structures into 1 acting peer. This makes no sense let's abstract out the peer into having 2 connection one for incoming connections and one for outgoing connections then we can easily collapse down without having to do crazy stuff. In addition people adding new features don't need to have to go touch a million places in the code. This is the start of this abstraction. In this commit we'll just pull out the fd and input/output buffers into a connection data structure. Future commits will abstract further. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-04-30 20:55:40 +02:00
peer_down_str[peer->last_reset]);
bgpd: Convert FSM to use `struct peer_connection` The BGP FSM was using the peer as the unit of work but the FSM is connection focused. So let's switch it over to using that. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-08-10 06:52:53 +02:00
bgp_stop(connection);
bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADD Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 00:07:04 +02:00
bgp_fsm_change_status(connection, Idle);
bgpd: make bgp_timer_set use a peer_connection instead The bgp_timer_set function should use a peer_connection pointer instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-27 02:56:20 +02:00
bgp_timer_set(connection);
bgpd: misc fsm fixes * Keepalive on/off calls are necessary in certain cases due to screwy fsm flow not turning them on after transferring a passive peer connection in peer_xfer_conn * Missed a case bgp_event_update() that resulted in a return code of -1 instead of BGP_Stop, which confuses the packet processing routine Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-06-12 04:53:42 +02:00
}
bgpd: bgp_event_update mixes enum's with a non-enum Straighten out the code to not mix the two. Especially since bgp was assigning non enum values to the enum. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:03:14 +02:00
fsm_result = FSM_PEER_STOPPED;
bgpd: Prevent use after free When bgp_stop finishes and it deletes the peer it is sending back a return code stating that the peer was deleted, but the code was operating like it was not deleted and continued to access the data structure. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:43:56 +02:00
break;
case BGP_FSM_FAILURE_AND_DELETE:
fsm_result = FSM_PEER_STOPPED;
bgpd: bgp_event_update switch to a switch The return code from a event handling perspective is an enum. Let's intentionally make it a switch so that all cases are ensured to be covered now and in the future. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:28:02 +02:00
break;
2005-06-01 Paul Jakma <paul.jakma@sun.com> * bgpd/(general) refcount struct peer and bgp_info, hence allowing us add work_queues for bgp_process. * bgpd/bgp_route.h: (struct bgp_info) Add 'lock' field for refcount. Add bgp_info_{lock,unlock} helper functions. Add bgp_info_{add,delete} helpers, to remove need for users managing locking/freeing of bgp_info and bgp_node's. * bgpd/bgp_table.h: (struct bgp_node) Add a flags field, and BGP_NODE_PROCESS_SCHEDULED to merge redundant processing of nodes. * bgpd/bgp_fsm.h: Make the ON/OFF/ADD/REMOVE macros lock and unlock peer reference as appropriate. * bgpd/bgp_damp.c: Remove its internal prototypes for bgp_info_delete/free. Just use bgp_info_delete. * bgpd/bgpd.h: (struct bgp_master) Add work_queue pointers. (struct peer) Add reference count 'lock' (peer_lock,peer_unlock) New helpers to take/release reference on struct peer. * bgpd/bgp_advertise.c: (general) Add peer and bgp_info refcounting and balance how references are taken and released. (bgp_advertise_free) release bgp_info reference, if appropriate (bgp_adj_out_free) unlock peer (bgp_advertise_clean) leave the adv references alone, or else call bgp_advertise_free cant unlock them. (bgp_adj_out_set) lock the peer on new adj's, leave the reference alone otherwise. lock the new bgp_info reference. (bgp_adj_in_set) lock the peer reference (bgp_adj_in_remove) and unlock it here (bgp_sync_delete) make hash_free on peer conditional, just in case. * bgpd/bgp_fsm.c: (general) document that the timers depend on bgp_event to release a peer reference. (bgp_fsm_change_status) moved up the file, unchanged. (bgp_stop) Decrement peer lock as many times as cancel_event canceled - shouldnt be needed but just in case. stream_fifo_clean of obuf made conditional, just in case. (bgp_event) always unlock the peer, regardless of return value of bgp_fsm_change_status. * bgpd/bgp_packet.c: (general) change several bgp_stop's to BGP_EVENT's. (bgp_read) Add a mysterious extra peer_unlock for ACCEPT_PEERs along with a comment on it. * bgpd/bgp_route.c: (general) Add refcounting of bgp_info, cleanup some of the resource management around bgp_info. Refcount peer. Add workqueues for bgp_process and clear_table. (bgp_info_new) make static (bgp_info_free) Ditto, and unlock the peer reference. (bgp_info_lock,bgp_info_unlock) new exported functions (bgp_info_add) Add a bgp_info to a bgp_node in correct fashion, taking care of reference counts. (bgp_info_delete) do the opposite of bgp_info_add. (bgp_process_rsclient) Converted into a work_queue work function. (bgp_process_main) ditto. (bgp_processq_del) process work queue item deconstructor (bgp_process_queue_init) process work queue init (bgp_process) call init function if required, set up queue item and add to queue, rather than calling process functions directly. (bgp_rib_remove) let bgp_info_delete manage bgp_info refcounts (bgp_rib_withdraw) ditto (bgp_update_rsclient) let bgp_info_add manage refcounts (bgp_update_main) ditto (bgp_clear_route_node) clear_node_queue work function, does per-node aspects of what bgp_clear_route_table did previously (bgp_clear_node_queue_del) clear_node_queue item delete function (bgp_clear_node_complete) clear_node_queue completion function, it unplugs the process queues, which have to be blocked while clear_node_queue is being processed to prevent a race. (bgp_clear_node_queue_init) init function for clear_node_queue work queues (bgp_clear_route_table) Sets up items onto a workqueue now, rather than clearing each node directly. Plugs both process queues to avoid potential race. (bgp_static_withdraw_rsclient) let bgp_info_{add,delete} manage bgp_info refcounts. (bgp_static_update_rsclient) ditto (bgp_static_update_main) ditto (bgp_static_update_vpnv4) ditto, remove unneeded cast. (bgp_static_withdraw) see bgp_static_withdraw_rsclient (bgp_static_withdraw_vpnv4) ditto (bgp_aggregate_{route,add,delete}) ditto (bgp_redistribute_{add,delete,withdraw}) ditto * bgpd/bgp_vty.c: (peer_rsclient_set_vty) lock rsclient list peer reference (peer_rsclient_unset_vty) ditto, but unlock same reference * bgpd/bgpd.c: (peer_free) handle frees of info to be kept for lifetime of struct peer. (peer_lock,peer_unlock) peer refcount helpers (peer_new) add initial refcounts (peer_create,peer_create_accept) lock peer as appropriate (peer_delete) unlock as appropriate, move out some free's to peer_free. (peer_group_bind,peer_group_unbind) peer refcounting as appropriate. (bgp_create) check CALLOC return value. (bgp_terminate) free workqueues too. * lib/memtypes.c: Add MTYPE_BGP_PROCESS_QUEUE and MTYPE_BGP_CLEAR_NODE_QUEUE
2005-06-01 13:17:05 +02:00
}
bgpd: misc fsm fixes * Keepalive on/off calls are necessary in certain cases due to screwy fsm flow not turning them on after transferring a passive peer connection in peer_xfer_conn * Missed a case bgp_event_update() that resulted in a return code of -1 instead of BGP_Stop, which confuses the packet processing routine Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2017-06-12 04:53:42 +02:00
bgpd: bgp_event_update mixes enum's with a non-enum Straighten out the code to not mix the two. Especially since bgp was assigning non enum values to the enum. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-25 16:03:14 +02:00
return fsm_result;
Initial revision
2002-12-13 21:15:29 +01:00
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
/* BGP GR Code */
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
static inline void
bgp_peer_inherit_global_gr_mode(struct peer *peer,
enum global_mode global_gr_mode)
{
switch (global_gr_mode) {
case GLOBAL_HELPER:
BGP_PEER_GR_HELPER_ENABLE(peer);
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
break;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
case GLOBAL_GR:
BGP_PEER_GR_ENABLE(peer);
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
break;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
case GLOBAL_DISABLE:
BGP_PEER_GR_DISABLE(peer);
bgpd: Refine restarter operation - R-bit & F-bit Introduce BGP-wide flags to denote if BGP has started gracefully and GR is in progress or not. Use this for setting of the R-bit in the GR capability, and not a timer which is set for any new instance creation. Mark graceful restart is complete when the deferred path selection has been done and route sync with zebra as well as deferred EOR advertisement has been initiated. Introduce a function to check on F-bit setting rather than just base it on configuration. Subsequent commits will extend these functionalities. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-26 01:05:48 +01:00
break;
case GLOBAL_INVALID:
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
default:
zlog_err("Unexpected Global GR mode %d", global_gr_mode);
}
}
static void bgp_gr_update_mode_of_all_peers(struct bgp *bgp,
enum global_mode global_new_state)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
{
struct peer *peer = {0};
struct listnode *node = {0};
struct listnode *nnode = {0};
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
enum peer_mode peer_old_state = PEER_INVALID;
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
struct peer_group *group;
struct peer *member;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
for (ALL_LIST_ELEMENTS(bgp->peer, node, nnode, peer)) {
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_GROUP)) {
peer_old_state = bgp_peer_gr_mode_get(peer);
if (peer_old_state != PEER_GLOBAL_INHERIT)
continue;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
bgp_peer_inherit_global_gr_mode(peer, global_new_state);
bgp_peer_gr_flags_update(peer);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
zlog_debug("%pBP: Inherited Global GR mode, GR flags 0x%x peer flags 0x%" PRIx64
"...resetting session",
peer, peer->peer_gr_new_status_flag, peer->flags);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
peer->last_reset = PEER_DOWN_CAPABILITY_CHANGE;
bgpd: Keep the last reset reason before we reset the peer If we send a notification, there is no point setting the last_reset, because bgp_notify_send() sets last_reset to PEER_DOWN_NOTIFY_SEND (almost everywhere). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-07-25 12:22:27 +02:00
bgpd: Fix pattern of usage in bgp_notify_config_change if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status)) peer_notify_config_change(peer->connection); else bgp_session_reset_safe(peer, &nnode); Let's add a bool return to peer_notify_config_change of whether or not it should call the peer session reset. This simplifies the code a bunch. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 14:24:28 +01:00
if (!peer_notify_config_change(peer->connection))
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
bgp_session_reset_safe(peer, &nnode);
} else {
group = peer->group;
for (ALL_LIST_ELEMENTS(group->peer, node, nnode, member)) {
peer_old_state = bgp_peer_gr_mode_get(member);
if (peer_old_state != PEER_GLOBAL_INHERIT)
continue;
bgp_peer_inherit_global_gr_mode(member, global_new_state);
bgp_peer_gr_flags_update(member);
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
zlog_debug("%pBP: Inherited Global GR mode, GR flags 0x%x peer flags 0x%" PRIx64
"...resetting session",
member, member->peer_gr_new_status_flag,
member->flags);
member->last_reset = PEER_DOWN_CAPABILITY_CHANGE;
bgpd: Fix pattern of usage in bgp_notify_config_change if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status)) peer_notify_config_change(peer->connection); else bgp_session_reset_safe(peer, &nnode); Let's add a bool return to peer_notify_config_change of whether or not it should call the peer session reset. This simplifies the code a bunch. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 14:24:28 +01:00
if (!peer_notify_config_change(member->connection))
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
bgp_session_reset(member);
}
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
}
bgpd: Fix format overflow for graceful-restart debug logs Use enum instead of int, and make the compiler happy when using -format-overflow. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-01-24 07:57:56 +01:00
int bgp_gr_update_all(struct bgp *bgp, enum global_gr_command global_gr_cmd)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
{
enum global_mode global_new_state = GLOBAL_INVALID;
enum global_mode global_old_state = GLOBAL_INVALID;
global_old_state = bgp_global_gr_mode_get(bgp);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
global_new_state = bgp->GLOBAL_GR_FSM[global_old_state][global_gr_cmd];
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
zlog_debug("%s: Handle GR command %s, current GR state %s, new GR state %s",
bgp->name_pretty, print_global_gr_cmd(global_gr_cmd),
print_global_gr_mode(global_old_state),
print_global_gr_mode(global_new_state));
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (global_old_state == GLOBAL_INVALID)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_ERR_GR_OPERATION_FAILED;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (global_new_state == GLOBAL_INVALID)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_ERR_GR_INVALID_CMD;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (global_new_state == global_old_state)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_GR_NO_OPERATION;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
/* Update global GR mode and process all peers in instance. */
bgp->global_gr_present_state = global_new_state;
bgp_gr_update_mode_of_all_peers(bgp, global_new_state);
return BGP_GR_SUCCESS;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
const char *print_peer_gr_mode(enum peer_mode pr_mode)
{
switch (pr_mode) {
case PEER_HELPER:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_HELPER";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_GR:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_GR";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_DISABLE:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_DISABLE";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_INVALID:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_INVALID";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_GLOBAL_INHERIT:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_GLOBAL_INHERIT";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return NULL;
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
const char *print_peer_gr_cmd(enum peer_gr_command pr_gr_cmd)
{
switch (pr_gr_cmd) {
case PEER_GR_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case NO_PEER_GR_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "NO_PEER_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_DISABLE_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_DISABLE_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case NO_PEER_DISABLE_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "NO_PEER_DISABLE_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case PEER_HELPER_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "PEER_HELPER_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case NO_PEER_HELPER_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "NO_PEER_HELPER_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return NULL;
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
const char *print_global_gr_mode(enum global_mode gl_mode)
{
switch (gl_mode) {
case GLOBAL_HELPER:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_HELPER";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case GLOBAL_GR:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_GR";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case GLOBAL_DISABLE:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_DISABLE";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case GLOBAL_INVALID:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_INVALID";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "???";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
const char *print_global_gr_cmd(enum global_gr_command gl_gr_cmd)
{
switch (gl_gr_cmd) {
case GLOBAL_GR_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case NO_GLOBAL_GR_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "NO_GLOBAL_GR_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case GLOBAL_DISABLE_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "GLOBAL_DISABLE_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
case NO_GLOBAL_DISABLE_CMD:
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return "NO_GLOBAL_DISABLE_CMD";
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
*: clang-SA friendly switch-enum-return-string clang-19's SA complains about unused initializers for this kind of "switch (enum) { return string }" kind of code. Use direct string return values to avoid the issue. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2024-10-16 12:23:23 +02:00
return NULL;
bgpd: BGP Garaceful Restart debug logs. Reorganizing bgp gr debug logs and code review comments. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-11-25 16:18:15 +01:00
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
enum global_mode bgp_global_gr_mode_get(struct bgp *bgp)
{
return bgp->global_gr_present_state;
}
enum peer_mode bgp_peer_gr_mode_get(struct peer *peer)
{
return peer->peer_gr_present_state;
}
bgpd: Fix format overflow for graceful-restart debug logs Use enum instead of int, and make the compiler happy when using -format-overflow. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-01-24 07:57:56 +01:00
int bgp_neighbor_graceful_restart(struct peer *peer,
enum peer_gr_command peer_gr_cmd)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
{
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
enum peer_mode peer_new_state = PEER_INVALID;
enum peer_mode peer_old_state = PEER_INVALID;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
struct bgp_peer_gr gr_fsm;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
int result = BGP_GR_FAILURE;
peer_old_state = bgp_peer_gr_mode_get(peer);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
gr_fsm = peer->PEER_GR_FSM[peer_old_state][peer_gr_cmd];
peer_new_state = gr_fsm.next_state;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Print old/new states of graceful restart FSM To better debug what's going on before/after. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-04-30 12:38:54 +02:00
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
zlog_debug("%pBP: Handle GR command %s, current GR state %s, new GR state %s",
peer, print_peer_gr_cmd(peer_gr_cmd),
print_peer_gr_mode(peer_old_state),
print_peer_gr_mode(peer_new_state));
bgpd: Print old/new states of graceful restart FSM To better debug what's going on before/after. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-04-30 12:38:54 +02:00
if (peer_old_state == PEER_INVALID)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_ERR_GR_OPERATION_FAILED;
bgpd: Print old/new states of graceful restart FSM To better debug what's going on before/after. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-04-30 12:38:54 +02:00
if (peer_new_state == PEER_INVALID)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_ERR_GR_INVALID_CMD;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (peer_new_state == peer_old_state)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_GR_NO_OPERATION;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
result = gr_fsm.action_fun(peer, peer_old_state, peer_new_state);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return result;
}
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
static inline bool gr_mode_matches(enum peer_mode peer_gr_mode,
enum global_mode global_gr_mode)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
{
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if ((peer_gr_mode == PEER_HELPER && global_gr_mode == GLOBAL_HELPER) ||
(peer_gr_mode == PEER_GR && global_gr_mode == GLOBAL_GR) ||
(peer_gr_mode == PEER_DISABLE && global_gr_mode == GLOBAL_DISABLE))
return true;
return false;
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
unsigned int bgp_peer_gr_action(struct peer *peer, enum peer_mode old_state,
enum peer_mode new_state)
{
bgpd: global_gr_mode does not need to be set twice Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-08-22 19:32:20 +02:00
enum global_mode global_gr_mode;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bool session_reset = true;
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
struct peer_group *group;
struct peer *member;
struct listnode *node, *nnode;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (old_state == new_state)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_GR_NO_OPERATION;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if ((old_state == PEER_INVALID) || (new_state == PEER_INVALID))
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
return BGP_ERR_GR_INVALID_CMD;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
global_gr_mode = bgp_global_gr_mode_get(peer->bgp);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if ((old_state == PEER_GLOBAL_INHERIT) &&
(new_state != PEER_GLOBAL_INHERIT)) {
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
BGP_PEER_GR_GLOBAL_INHERIT_UNSET(peer);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (gr_mode_matches(new_state, global_gr_mode))
/* Peer was inheriting the global state and
* its new state still is the same, so a
* session reset is not needed.
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
*/
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
session_reset = false;
} else if ((new_state == PEER_GLOBAL_INHERIT) &&
(old_state != PEER_GLOBAL_INHERIT)) {
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
BGP_PEER_GR_GLOBAL_INHERIT_SET(peer);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (gr_mode_matches(old_state, global_gr_mode))
/* Peer is inheriting the global state and
* its old state was also the same, so a
* session reset is not needed.
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
*/
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
session_reset = false;
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
/* Ensure we move to the new state and update flags */
bgp_peer_move_to_gr_mode(peer, new_state);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (session_reset) {
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_GROUP)) {
peer->last_reset = PEER_DOWN_CAPABILITY_CHANGE;
bgpd: Keep the last reset reason before we reset the peer If we send a notification, there is no point setting the last_reset, because bgp_notify_send() sets last_reset to PEER_DOWN_NOTIFY_SEND (almost everywhere). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-07-25 12:22:27 +02:00
bgpd: Fix pattern of usage in bgp_notify_config_change if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status)) peer_notify_config_change(peer->connection); else bgp_session_reset_safe(peer, &nnode); Let's add a bool return to peer_notify_config_change of whether or not it should call the peer session reset. This simplifies the code a bunch. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 14:24:28 +01:00
if (!peer_notify_config_change(peer->connection))
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
bgp_session_reset(peer);
} else {
group = peer->group;
for (ALL_LIST_ELEMENTS(group->peer, node, nnode, member)) {
member->last_reset = PEER_DOWN_CAPABILITY_CHANGE;
bgp_peer_move_to_gr_mode(member, new_state);
bgpd: Fix pattern of usage in bgp_notify_config_change if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status)) peer_notify_config_change(peer->connection); else bgp_session_reset_safe(peer, &nnode); Let's add a bool return to peer_notify_config_change of whether or not it should call the peer session reset. This simplifies the code a bunch. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-06 14:24:28 +01:00
if (!peer_notify_config_change(member->connection))
bgpd: Fix graceful-restart for peer-groups Slipped somehow that peer-groups with GR is just completely broken, but it was working before. Strikes again, that we MUST have more and more topotests. Fixes: 15403f521a12b668e87ef8961c78e0ed97c6ff92 ("bgpd: Streamline GR config, act on change immediately") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 20:57:19 +01:00
bgp_session_reset(member);
}
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
return BGP_GR_SUCCESS;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
void bgp_peer_move_to_gr_mode(struct peer *peer, enum peer_mode new_state)
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
{
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
enum global_mode global_gr_mode = bgp_global_gr_mode_get(peer->bgp);
enum peer_mode old_state = bgp_peer_gr_mode_get(peer);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
switch (new_state) {
case PEER_HELPER:
BGP_PEER_GR_HELPER_ENABLE(peer);
break;
case PEER_GR:
BGP_PEER_GR_ENABLE(peer);
break;
case PEER_DISABLE:
BGP_PEER_GR_DISABLE(peer);
break;
case PEER_GLOBAL_INHERIT:
BGP_PEER_GR_GLOBAL_INHERIT_SET(peer);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bgp_peer_inherit_global_gr_mode(peer, global_gr_mode);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
break;
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
case PEER_INVALID:
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
default:
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
zlog_err(
"[BGP_GR] Default switch mode ::: SOMETHING IS WRONG !!!");
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
break;
}
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bgp_peer_gr_flags_update(peer);
peer->peer_gr_present_state = new_state;
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
zlog_debug("%pBP: Peer GR mode changed from %s to %s, GR flags 0x%x peer flags 0x%" PRIx64,
peer, print_peer_gr_mode(old_state),
print_peer_gr_mode(new_state),
peer->peer_gr_new_status_flag, peer->flags);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
void bgp_peer_gr_flags_update(struct peer *peer)
{
if (CHECK_FLAG(peer->peer_gr_new_status_flag,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
PEER_GRACEFUL_RESTART_NEW_STATE_HELPER))
SET_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART_HELPER);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
else
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
UNSET_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART_HELPER);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
if (CHECK_FLAG(peer->peer_gr_new_status_flag,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
PEER_GRACEFUL_RESTART_NEW_STATE_RESTART))
SET_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
else
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
UNSET_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
if (CHECK_FLAG(peer->peer_gr_new_status_flag,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
PEER_GRACEFUL_RESTART_NEW_STATE_INHERIT))
bgpd: Adding BGP GR Per Neighbor show commands. * Added new show command to show the graceful restart information for each neighbor. Cmd: show bgp [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|WORD>] graceful-restart * Changes to show neighbors commands for displaying graceful restart information. Cmd :show [ip] bgp [<view|vrf> VIEWVRFNAME] [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X| Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 12:02:48 +02:00
SET_FLAG(peer->flags,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
PEER_FLAG_GRACEFUL_RESTART_GLOBAL_INHERIT);
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
else
bgpd: Adding BGP GR Per Neighbor show commands. * Added new show command to show the graceful restart information for each neighbor. Cmd: show bgp [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|WORD>] graceful-restart * Changes to show neighbors commands for displaying graceful restart information. Cmd :show [ip] bgp [<view|vrf> VIEWVRFNAME] [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X| Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 12:02:48 +02:00
UNSET_FLAG(peer->flags,
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
PEER_FLAG_GRACEFUL_RESTART_GLOBAL_INHERIT);
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
if (BGP_DEBUG(graceful_restart, GRACEFUL_RESTART))
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
zlog_debug("%pBP: Peer flags updated to 0x%" PRIx64
", GR flags 0x%x, GR mode %s",
peer, peer->flags, peer->peer_gr_new_status_flag,
print_peer_gr_mode(bgp_peer_gr_mode_get(peer)));
bgpd: BGP tcp session failed to apply GR configuration on the transferred bgp tcp connection. When the BGP peer is configured between two bgp routes both routers would create peer structure , when they receive each other’s open message. In this event both speakers, open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. If BGP GR is enabled the old tcp session is dumped and the new session is retained. So while this transfer of connection is happening, if all the bgp gr config is not migrated to the new connection, the new bgp gr mode will never get applied. Fix Summary: 1. Replicate GR configuration from the old session to the new session in bgp_accept(). 2. Replicate GR configuration from stub to full-fledged peer in bgp_establish(). 3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers (if they are running) when the bgp GR mode is changed to “Disabled”. 4. Disable R-bit in cap, if it is not set the received open message. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-24 06:40:53 +02:00
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
/*
* If GR has been completely disabled for the peer and we were
* acting as the Helper for the peer (i.e., keeping stale routes
* and running the restart timer or stalepath timer), clear those
* states.
*/
if (!CHECK_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART) &&
!CHECK_FLAG(peer->flags, PEER_FLAG_GRACEFUL_RESTART_HELPER)) {
bgpd: BGP tcp session failed to apply GR configuration on the transferred bgp tcp connection. When the BGP peer is configured between two bgp routes both routers would create peer structure , when they receive each other’s open message. In this event both speakers, open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. If BGP GR is enabled the old tcp session is dumped and the new session is retained. So while this transfer of connection is happening, if all the bgp gr config is not migrated to the new connection, the new bgp gr mode will never get applied. Fix Summary: 1. Replicate GR configuration from the old session to the new session in bgp_accept(). 2. Replicate GR configuration from stub to full-fledged peer in bgp_establish(). 3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers (if they are running) when the bgp GR mode is changed to “Disabled”. 4. Disable R-bit in cap, if it is not set the received open message. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-24 06:40:53 +02:00
UNSET_FLAG(peer->sflags, PEER_STATUS_NSF_MODE);
bgpd, lib: fix style from BGP GR code This patch fixes the noncompliant style for the following commit range: 4a6e80fbf 2ba1fe695 efcb2ebbb 8c48b3b69 dc95985fe 0f0444fbd 85ef4179a eb451ee58 2d3dd828d 9e3b51a7f d6e3c15b6 34aa74486 6102cb7fe d7b3cda6f 2bb5d39b1 5f9c1aa29 5cce3f054 3a75afa4b f009ff269 cfd47646b 2986cac29 055679e91 034e185dc 794b37d52 b0965c44e 949b0f24f 63696f1d8 Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2020-01-31 19:04:00 +01:00
if (CHECK_FLAG(peer->sflags, PEER_STATUS_NSF_WAIT)) {
bgpd: Streamline GR config, act on change immediately Streamline the BGP graceful-restart configuration at the global and peer level some more. Similar to many other neighbor capability parameters like MP and ENHE, reset the session immediately upon a change to the configuration. This will be more aligned with the transactional UI model also and will not require a separate 'clear' command to be executed. Note: Peer-group graceful-restart configuration is not yet supported. Signed-off-by: Vivek Venkatraman <vivek@nvidia.com>
2020-10-25 19:31:42 +01:00
if (bgp_debug_neighbor_events(peer))
zlog_debug("%pBP: GR disabled, stopping NSF and clearing stale routes",
peer);
bgpd: BGP tcp session failed to apply GR configuration on the transferred bgp tcp connection. When the BGP peer is configured between two bgp routes both routers would create peer structure , when they receive each other’s open message. In this event both speakers, open duplicate TCP sessions and send OPEN messages on each socket simultaneously, the BGP Identifier is used to resolve which socket should be closed. If BGP GR is enabled the old tcp session is dumped and the new session is retained. So while this transfer of connection is happening, if all the bgp gr config is not migrated to the new connection, the new bgp gr mode will never get applied. Fix Summary: 1. Replicate GR configuration from the old session to the new session in bgp_accept(). 2. Replicate GR configuration from stub to full-fledged peer in bgp_establish(). 3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers (if they are running) when the bgp GR mode is changed to “Disabled”. 4. Disable R-bit in cap, if it is not set the received open message. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-24 06:40:53 +02:00
peer_nsf_stop(peer);
}
}
bgpd: Adding BGP GR Global & Per Neighbour FSM changes * Added FSM for peer and global configuration for graceful restart * Added debug option BGP_GRACEFUL_RESTART for logs specific to graceful restart processing Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-23 07:40:22 +02:00
}
bgpd: Fix wrong pthread event cancelling 0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 1 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 2 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 3 0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26 4 0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258 5 <signal handler called> 6 __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44 7 __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78 8 __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 9 0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79 11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470 14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355 15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610 16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152 17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639 18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111 19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252 20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214 21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180 22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) f 12 12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428 1428 assert(m->owner == pthread_self()); In this decode the attempt to cancel the connection's events from the wrong thread is causing the crash. Modify the code to create an event on the bm->master to cancel the events for the connection. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-10-24 23:44:31 +02:00
void bgp_event_stop_with_notify(struct event *event)
{
struct peer_connection *connection = EVENT_ARG(event);
bgp_stop_with_notify(connection, BGP_NOTIFY_SEND_HOLD_ERR, 0);
}
Copy permalink