matthieu/frr
1
0
Fork 0
forked from Mirror/frr
Code Pull requests Activity
frr/bgpd/bgp_advertise.h

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

166 lines
4.8 KiB
C
Raw Permalink 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 advertisement and adjacency
*: 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
* Copyright (C) 1996, 97, 98, 99, 2000 Kunihiro Ishiguro
*/
Initial revision
2002-12-13 21:15:29 +01:00
2005-05-23 Paul Jakma <paul@dishone.st> * bgp_fsm.h: Add extern qualifier to exported functions * bgp_nexthop.c: add static to nexthop specific globals * *.h: Add guard defines
2005-05-23 16:19:54 +02:00
#ifndef _QUAGGA_BGP_ADVERTISE_H
#define _QUAGGA_BGP_ADVERTISE_H
bgpd: replace ADV_FIFO with DECLARE_LIST The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-04-21 18:17:45 +02:00
#include "lib/typesafe.h"
lib, bgpd: Remove 'struct fifo' from lib/zebra.h The 'struct fifo' and it's accompanying #defines do not belong in lib/zebra.h. Move them into their own header. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> (cherry picked from commit b0d02889624eaafa0984873dcd78c086418bdf13)
2016-01-08 13:37:14 +01:00
bgpd: use DLIST for adv_fifo I mistakenly assumed that something called "FIFO" would primarily be used by removing items from the front. This isn't the case for the adv_fifo... so use a DLIST there to make sure deletions from the middle of the queue are fast. Signed-off-by: David Lamparter <equinox@diac24.net>
2019-05-20 23:41:16 +02:00
PREDECL_DLIST(bgp_adv_fifo);
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
bgpd: replace ADV_FIFO with DECLARE_LIST The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-04-21 18:17:45 +02:00
struct update_subgroup;
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
struct bgp_advertise;
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
PREDECL_DLIST(bgp_advertise_attr_fifo);
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
struct bgp_advertise_attr;
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
/* BGP advertise attribute. */
Initial revision
2002-12-13 21:15:29 +01:00
struct bgp_advertise {
/* FIFO for advertisement. */
bgpd: replace ADV_FIFO with DECLARE_LIST The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-04-21 18:17:45 +02:00
struct bgp_adv_fifo_item fifo;
Initial revision
2002-12-13 21:15:29 +01:00
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
/* FIFO for this item in the bgp_advertise_attr fifo */
struct bgp_advertise_attr_fifo_item item;
Initial revision
2002-12-13 21:15:29 +01:00
/* Prefix information. */
bgp: rename bgp_node to bgp_dest This is the bulk part extracted from "bgpd: Convert from `struct bgp_node` to `struct bgp_dest`". It should not result in any functional change. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2020-03-27 00:11:58 +01:00
struct bgp_dest *dest;
Initial revision
2002-12-13 21:15:29 +01:00
/* Reference pointer. */
struct bgp_adj_out *adj;
/* Advertisement attribute. */
struct bgp_advertise_attr *baa;
/* BGP info. */
bgpd: Convert binfo to path Convert the binfo variable to path. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-10-03 00:34:03 +02:00
struct bgp_path_info *pathi;
Initial revision
2002-12-13 21:15:29 +01:00
};
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
DECLARE_DLIST(bgp_advertise_attr_fifo, struct bgp_advertise, item);
bgpd: use DLIST for adv_fifo I mistakenly assumed that something called "FIFO" would primarily be used by removing items from the front. This isn't the case for the adv_fifo... so use a DLIST there to make sure deletions from the middle of the queue are fast. Signed-off-by: David Lamparter <equinox@diac24.net>
2019-05-20 23:41:16 +02:00
DECLARE_DLIST(bgp_adv_fifo, struct bgp_advertise, fifo);
bgpd: replace ADV_FIFO with DECLARE_LIST The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-04-21 18:17:45 +02:00
bgpd: Convert the bgp_advertise_attr->adv to a fifo BGP is storing outgoing updates in a couple of different fifo's. This is to ensure proper packet packing of all bgp_dests that happen to use the same attribute. How it's all put together currently: On initial update BGP walks through all the bgp_dest's in a table. For each path being sent a bgp_advertise is created. This bgp_advertise is placed in fifo order on the bgp_synchronize->update queue. The bgp_advertise has a pointer to the bgp_advertise_attr which is associated iwth the actual attribute that is being sent to it's peer. In turn this bgp_advertise is placed in a fifo off of the bgp_advertise_attr structure. As such as we have paths that share an attribute, the path/dest is placed on the bgp_syncrhonize->update fifo as well as being placed on the fifo associated with the advertised attribute. On actual creation of a packet. The first item in the bgp_synchronize->update fifo is popped. The bgp_advertise_attr pointer is grabbed, we fill out the nlri part of the bgp packet and then walk the bgp_advertise_attr fifo to place paths/dests in the packet. As each path/dest is placed in the packet it is removed from both the bgp_synchronize->update fifo and the bgp_advertise_attr fifo. The whole point of this change is to switch the *next, *prev pointers in the bgp_advertise structure with a typesafe data structure. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-06 18:48:38 +02:00
/* BGP advertise attribute. */
struct bgp_advertise_attr {
/* Head of advertisement pointer. */
struct bgp_advertise_attr_fifo_head fifo;
/* Reference counter. */
unsigned long refcnt;
/* Attribute pointer to be announced. */
struct attr *attr;
};
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP adjacency out. */
struct bgp_adj_out {
bgpd: Convert adj_out to a RB tree The adj_out data structure is a linked list of adjacencies 1 per update group. In a large scale env where we are not using peer groups, this list lookup starts to become rather costly. Convert to a better data structure for this. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-12-07 15:01:59 +01:00
/* RB Tree of adjacency entries */
RB_ENTRY(bgp_adj_out) adj_entry;
Initial revision
2002-12-13 21:15:29 +01: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
/* Advertised subgroup. */
struct update_subgroup *subgroup;
/* Threading that makes the adj part of subgroup's adj queue */
TAILQ_ENTRY(bgp_adj_out) subgrp_adj_train;
/* Prefix information. */
bgp: rename bgp_node to bgp_dest This is the bulk part extracted from "bgpd: Convert from `struct bgp_node` to `struct bgp_dest`". It should not result in any functional change. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2020-03-27 00:11:58 +01:00
struct bgp_dest *dest;
Initial revision
2002-12-13 21:15:29 +01:00
*: 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
uint32_t addpath_tx_id;
BGP: support for addpath TX Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com Ticket: CM-8014 This implements addpath TX with the first feature to use it being "neighbor x.x.x.x addpath-tx-all-paths". One change to show output is 'show ip bgp x.x.x.x'. If no addpath-tx features are configured for any peers then everything looks the same as it is today in that "Advertised to" is at the top and refers to which peers the bestpath was advertise to. root@superm-redxp-05[quagga-stash5]# vtysh -c 'show ip bgp 1.1.1.1' BGP routing table entry for 1.1.1.1/32 Paths: (6 available, best #6, table Default-IP-Routing-Table) Advertised to non peer-group peers: r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8) Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 8 Last update: Fri Oct 30 18:26:44 2015 [snip] but once you enable an addpath feature we must display "Advertised to" on a path-by-path basis: superm-redxp-05# show ip bgp 1.1.1.1/32 BGP routing table entry for 1.1.1.1/32 Paths: (6 available, best #6, table Default-IP-Routing-Table) Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 8 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:44 2015 Local, (Received from a RR-client) 34.34.34.34 (metric 20) from r3(10.0.0.3) (10.0.0.3) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 7 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 56.56.56.56 (metric 20) from r6(10.0.0.6) (10.0.0.6) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 6 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 56.56.56.56 (metric 20) from r5(10.0.0.5) (10.0.0.5) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 5 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 34.34.34.34 (metric 20) from r4(10.0.0.4) (10.0.0.4) Origin IGP, metric 0, localpref 100, valid, internal AddPath ID: RX 0, TX 4 Advertised to: r8(10.0.0.8) Last update: Fri Oct 30 18:26:39 2015 Local, (Received from a RR-client) 12.12.12.12 (metric 20) from r1(10.0.0.1) (10.0.0.1) Origin IGP, metric 0, localpref 100, valid, internal, best AddPath ID: RX 0, TX 3 Advertised to: r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8) Last update: Fri Oct 30 18:26:34 2015 superm-redxp-05#
2015-11-05 18:29:43 +01:00
bgpd: Optimize memory for bgp_adj_out struct ``` struct bgp_adj_out { struct rb_entry adj_entry; /* 0 32 */ /* XXX last struct has 4 bytes of padding */ struct update_subgroup * subgroup; /* 32 8 */ struct { struct bgp_adj_out * tqe_next; /* 40 8 */ struct bgp_adj_out * * tqe_prev; /* 48 8 */ } subgrp_adj_train; /* 40 16 */ struct bgp_dest * dest; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ uint32_t addpath_tx_id; /* 64 4 */ uint32_t attr_hash; /* 68 4 */ struct attr * attr; /* 72 8 */ struct bgp_advertise * adv; /* 80 8 */ /* size: 88, cachelines: 2, members: 8 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 24 bytes */ }; /* saved 8 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-09 16:18:22 +01:00
/* Attribute hash */
uint32_t attr_hash;
Initial revision
2002-12-13 21:15:29 +01:00
/* Advertised attribute. */
struct attr *attr;
bgpd: fix label in adj-rib-out After modifying the "label vpn export value", the vpn label information of the VRF is not updated to the peers. For example, the 192.168.0.0/24 prefix is announced to the peer with a label value of 222. > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4-vpn > neighbor 192.0.2.2 activate > exit-address-family > exit > router bgp 65500 vrf vrf2 > address-family ipv4 unicast > network 192.168.0.0/24 > label vpn export 222 > rd vpn export 444:444 > rt vpn both 53:100 > export vpn > import vpn > exit-address-family Changing the label with "label vpn export" does not update the label value to the peer unless the BGP sessions is re-established. No labels are stored are stored struct bgp_adj_out so that it is impossible to compare the current value with the previous value in adj-RIB-out. Reference the bgp_labels pointer in struct bgp_adj_out and compare the values when updating adj-RIB-out. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-02-23 15:38:11 +01:00
/* VPN label information */
struct bgp_labels *labels;
Initial revision
2002-12-13 21:15:29 +01:00
/* Advertisement information. */
struct bgp_advertise *adv;
};
bgpd: Convert adj_out to a RB tree The adj_out data structure is a linked list of adjacencies 1 per update group. In a large scale env where we are not using peer groups, this list lookup starts to become rather costly. Convert to a better data structure for this. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-12-07 15:01:59 +01:00
RB_HEAD(bgp_adj_out_rb, bgp_adj_out);
RB_PROTOTYPE(bgp_adj_out_rb, bgp_adj_out, adj_entry,
bgp_adj_out_compare);
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP adjacency in. */
struct bgp_adj_in {
/* Linked list pointer. */
struct bgp_adj_in *next;
struct bgp_adj_in *prev;
/* Received peer. */
struct peer *peer;
/* Received attribute. */
struct attr *attr;
Addpath does not work for soft-reconfiguration
2015-05-20 03:04:01 +02:00
bgpd: fix labels in adj-rib-in In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with 'soft-reconfiguration inbound'), after applying a deny route-map and removing it, the remote MPLS label information is lost. As a result, BGP is unable to re-install the related routes in the RIB. For example, > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4 vpn > neighbor 192.0.2.2 activate > neighbor 192.0.2.2 soft-reconfiguration inbound The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP RIB. > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Remote label: 102 A route-map now filter all incoming BGP updates: > route-map rmap deny 1 > router bgp 65500 > address-family ipv4 vpn > neighbor 192.0.2.2 route-map rmap in The prefix is now filtered: > # show bgp ipv4 vpn 192.168.0.0/24 > # The route-map is detached: > router bgp 65500 > address-family ipv4 vpn > no neighbor 192.168.0.1 route-map rmap in The BGP RIB entry is present but the remote label is lost: > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 The reason for the loose is that labels are stored within struct attr -> struct extra -> struct bgp_labels but not in the struct bgp_adj_in. Reference the bgp_labels pointer in struct bgp_adj_in and use its values when doing a soft reconfiguration of the BGP table. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-01-13 15:59:52 +01:00
/* VPN label information */
struct bgp_labels *labels;
bgpd: add timestamp to bgp_adj_in If we reject a received update in a filter, it never turns into a bgp_path_info but stays in adj_in. For that case, we don't have any timestamp for the update. Currently, this isn't visible anywhere; BMP will make use of this timestamp (and we can add a CLI option if we want.) Signed-off-by: David Lamparter <equinox@diac24.net>
2019-07-17 15:24:28 +02:00
/* timestamp (monotime) */
time_t uptime;
Addpath does not work for soft-reconfiguration
2015-05-20 03:04:01 +02:00
/* Addpath identifier */
*: 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
uint32_t addpath_rx_id;
Initial revision
2002-12-13 21:15:29 +01:00
};
/* BGP advertisement list. */
struct bgp_synchronize {
bgpd: replace ADV_FIFO with DECLARE_LIST The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2019-04-21 18:17:45 +02:00
struct bgp_adv_fifo_head update;
struct bgp_adv_fifo_head withdraw;
Initial revision
2002-12-13 21:15:29 +01:00
};
/* BGP adjacency linked list. */
bgpd: Convert BGP_INFO_XXX to BGP_PATH_XXX Search and replace all BGP_INFO_XXX to BGP_PATH_XXX Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-09-14 02:34:42 +02:00
#define BGP_PATH_INFO_ADD(N, A, TYPE) \
Initial revision
2002-12-13 21:15:29 +01:00
do { \
(A)->prev = NULL; \
(A)->next = (N)->TYPE; \
if ((N)->TYPE) \
(N)->TYPE->prev = (A); \
(N)->TYPE = (A); \
} while (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: Convert BGP_INFO_XXX to BGP_PATH_XXX Search and replace all BGP_INFO_XXX to BGP_PATH_XXX Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-09-14 02:34:42 +02:00
#define BGP_PATH_INFO_DEL(N, A, TYPE) \
Initial revision
2002-12-13 21:15:29 +01:00
do { \
if ((A)->next) \
(A)->next->prev = (A)->prev; \
if ((A)->prev) \
(A)->prev->next = (A)->next; \
else \
(N)->TYPE = (A)->next; \
} while (0)
bgpd: Convert BGP_INFO_XXX to BGP_PATH_XXX Search and replace all BGP_INFO_XXX to BGP_PATH_XXX Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-09-14 02:34:42 +02:00
#define BGP_ADJ_IN_ADD(N, A) BGP_PATH_INFO_ADD(N, A, adj_in)
#define BGP_ADJ_IN_DEL(N, A) BGP_PATH_INFO_DEL(N, A, adj_in)
Initial revision
2002-12-13 21:15:29 +01:00
/* Prototypes. */
bgpd: Align bgp_advertise.h to our standards bgp_advertise.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:53:01 +02:00
extern bool bgp_adj_out_lookup(struct peer *peer, struct bgp_dest *dest,
uint32_t addpath_tx_id);
extern void bgp_adj_in_set(struct bgp_dest *dest, struct peer *peer,
bgpd: fix labels in adj-rib-in In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with 'soft-reconfiguration inbound'), after applying a deny route-map and removing it, the remote MPLS label information is lost. As a result, BGP is unable to re-install the related routes in the RIB. For example, > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4 vpn > neighbor 192.0.2.2 activate > neighbor 192.0.2.2 soft-reconfiguration inbound The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP RIB. > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Remote label: 102 A route-map now filter all incoming BGP updates: > route-map rmap deny 1 > router bgp 65500 > address-family ipv4 vpn > neighbor 192.0.2.2 route-map rmap in The prefix is now filtered: > # show bgp ipv4 vpn 192.168.0.0/24 > # The route-map is detached: > router bgp 65500 > address-family ipv4 vpn > no neighbor 192.168.0.1 route-map rmap in The BGP RIB entry is present but the remote label is lost: > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 The reason for the loose is that labels are stored within struct attr -> struct extra -> struct bgp_labels but not in the struct bgp_adj_in. Reference the bgp_labels pointer in struct bgp_adj_in and use its values when doing a soft reconfiguration of the BGP table. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-01-13 15:59:52 +01:00
struct attr *attr, uint32_t addpath_id,
struct bgp_labels *labels);
bgpd: bgp_adj_in_unset needs to return the dest pointer This is incase it has been freed ( it wont due to locking ) and then we need to ensure that we can continue to use the pointer. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-10 15:27:51 +02:00
extern bool bgp_adj_in_unset(struct bgp_dest **dest, struct peer *peer,
bgpd: Align bgp_advertise.h to our standards bgp_advertise.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:53:01 +02:00
uint32_t addpath_id);
bgpd: bgp_clear_adj_in|remove dest may be freed dest will not be freed due to lock but coverity does not know that. Give it a hint. This change includes modifying bgp_dest_unlock_node to return the dest pointer so that we can determine if we should continue working on dest or not with an assert. Since this is lock based we should be ok. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-10 14:53:36 +02:00
extern void bgp_adj_in_remove(struct bgp_dest **dest, struct bgp_adj_in *bai);
bgpd: Align bgp_advertise.h to our standards bgp_advertise.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:53:01 +02:00
bgpd: Rename baa_new/baa_free/etc functions to be human-readable Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-07-25 15:37:17 +02:00
extern unsigned int bgp_advertise_attr_hash_key(const void *p);
extern bool bgp_advertise_attr_hash_cmp(const void *p1, const void *p2);
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
extern void bgp_advertise_add(struct bgp_advertise_attr *baa,
struct bgp_advertise *adv);
extern struct bgp_advertise *bgp_advertise_new(void);
extern void bgp_advertise_free(struct bgp_advertise *adv);
bgpd: Rename baa_new/baa_free/etc functions to be human-readable Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-07-25 15:37:17 +02:00
extern struct bgp_advertise_attr *bgp_advertise_attr_intern(struct hash *hash,
struct attr *attr);
extern struct bgp_advertise_attr *bgp_advertise_attr_new(void);
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
extern void bgp_advertise_delete(struct bgp_advertise_attr *baa,
struct bgp_advertise *adv);
bgpd: Rename baa_new/baa_free/etc functions to be human-readable Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-07-25 15:37:17 +02:00
extern void bgp_advertise_attr_unintern(struct hash *hash,
struct bgp_advertise_attr *baa);
extern void bgp_advertise_attr_free(struct bgp_advertise_attr *baa);
2005-05-23 Paul Jakma <paul@dishone.st> * bgp_fsm.h: Add extern qualifier to exported functions * bgp_nexthop.c: add static to nexthop specific globals * *.h: Add guard defines
2005-05-23 16:19:54 +02:00
#endif /* _QUAGGA_BGP_ADVERTISE_H */
Copy permalink