frr/bgpd/bgp_updgrp_adv.c

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

1150 lines
29 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/**
* bgp_updgrp_adv.c: BGP update group advertisement and adjacency
* maintenance
*
*
* @copyright Copyright (C) 2014 Cumulus Networks, Inc.
*
* @author Avneesh Sachdev <avneesh@sproute.net>
* @author Rajesh Varadarajan <rajesh@sproute.net>
* @author Pradosh Mohapatra <pradosh@sproute.net>
*/
#include <zebra.h>
#include "command.h"
#include "memory.h"
#include "prefix.h"
#include "hash.h"
#include "frrevent.h"
#include "queue.h"
#include "routemap.h"
#include "filter.h"
#include "bgpd/bgpd.h"
#include "bgpd/bgp_table.h"
#include "bgpd/bgp_debug.h"
#include "bgpd/bgp_route.h"
#include "bgpd/bgp_advertise.h"
#include "bgpd/bgp_attr.h"
#include "bgpd/bgp_aspath.h"
#include "bgpd/bgp_packet.h"
#include "bgpd/bgp_fsm.h"
#include "bgpd/bgp_mplsvpn.h"
#include "bgpd/bgp_updgrp.h"
#include "bgpd/bgp_advertise.h"
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
#include "bgpd/bgp_addpath.h"
/********************
* PRIVATE FUNCTIONS
********************/
static int bgp_adj_out_compare(const struct bgp_adj_out *o1,
const struct bgp_adj_out *o2)
{
if (o1->subgroup < o2->subgroup)
return -1;
if (o1->subgroup > o2->subgroup)
return 1;
if (o1->addpath_tx_id < o2->addpath_tx_id)
return -1;
if (o1->addpath_tx_id > o2->addpath_tx_id)
return 1;
return 0;
}
RB_GENERATE(bgp_adj_out_rb, bgp_adj_out, adj_entry, bgp_adj_out_compare);
static inline struct bgp_adj_out *adj_lookup(struct bgp_dest *dest,
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
struct update_subgroup *subgrp,
uint32_t addpath_tx_id)
{
struct bgp_adj_out lookup;
if (!dest || !subgrp)
return NULL;
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
/* update-groups that do not support addpath will pass 0 for
* addpath_tx_id. */
lookup.subgroup = subgrp;
lookup.addpath_tx_id = addpath_tx_id;
return RB_FIND(bgp_adj_out_rb, &dest->adj_out, &lookup);
}
static void adj_free(struct bgp_adj_out *adj)
{
bgp_labels_unintern(&adj->labels);
TAILQ_REMOVE(&(adj->subgroup->adjq), adj, subgrp_adj_train);
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
SUBGRP_DECR_STAT(adj->subgroup, adj_count);
RB_REMOVE(bgp_adj_out_rb, &adj->dest->adj_out, adj);
bgp_dest_unlock_node(adj->dest);
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
XFREE(MTYPE_BGP_ADJ_OUT, adj);
}
static void
subgrp_announce_addpath_best_selected(struct bgp_dest *dest,
struct update_subgroup *subgrp)
{
afi_t afi = SUBGRP_AFI(subgrp);
safi_t safi = SUBGRP_SAFI(subgrp);
struct peer *peer = SUBGRP_PEER(subgrp);
enum bgp_path_selection_reason reason;
char pfx_buf[PREFIX2STR_BUFFER] = {};
int paths_eq = 0;
struct list *list = list_new();
struct bgp_path_info *pi = NULL;
uint16_t paths_count = 0;
uint16_t paths_limit = peer->addpath_paths_limit[afi][safi].receive;
if (peer->addpath_type[afi][safi] == BGP_ADDPATH_BEST_SELECTED) {
paths_limit =
paths_limit
? MIN(paths_limit,
peer->addpath_best_selected[afi][safi])
: peer->addpath_best_selected[afi][safi];
while (paths_count++ < paths_limit) {
struct bgp_path_info *exist = NULL;
for (pi = bgp_dest_get_bgp_path_info(dest); pi;
pi = pi->next) {
if (listnode_lookup(list, pi))
continue;
if (CHECK_FLAG(pi->flags, BGP_PATH_SELECTED))
continue;
if (bgp_path_info_cmp(peer->bgp, pi, exist,
&paths_eq, NULL, 0,
pfx_buf, afi, safi,
&reason))
exist = pi;
}
if (exist)
listnode_add(list, exist);
}
}
for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) {
uint32_t id = bgp_addpath_id_for_peer(peer, afi, safi,
&pi->tx_addpath);
if (peer->addpath_type[afi][safi] ==
BGP_ADDPATH_BEST_SELECTED) {
if (listnode_lookup(list, pi))
subgroup_process_announce_selected(
subgrp, pi, dest, afi, safi, id);
else
subgroup_process_announce_selected(
subgrp, NULL, dest, afi, safi, id);
} else {
/* No Paths-Limit involved */
if (!paths_limit) {
subgroup_process_announce_selected(subgrp, pi,
dest, afi,
safi, id);
continue;
}
/* If we have Paths-Limit capability, we MUST
* not send more than the number of paths expected
* by the peer.
*/
if (paths_count++ < paths_limit)
subgroup_process_announce_selected(subgrp, pi,
dest, afi,
safi, id);
else
subgroup_process_announce_selected(subgrp, NULL,
dest, afi,
safi, id);
}
}
if (list)
list_delete(&list);
}
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
static void subgrp_withdraw_stale_addpath(struct updwalk_context *ctx,
struct update_subgroup *subgrp)
{
struct bgp_adj_out *adj, *adj_next;
uint32_t id;
struct bgp_path_info *pi;
afi_t afi = SUBGRP_AFI(subgrp);
safi_t safi = SUBGRP_SAFI(subgrp);
struct peer *peer = SUBGRP_PEER(subgrp);
/* Look through all of the paths we have advertised for this rn and send
* a withdraw for the ones that are no longer present */
RB_FOREACH_SAFE (adj, bgp_adj_out_rb, &ctx->dest->adj_out, adj_next) {
if (adj->subgroup != subgrp)
continue;
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
for (pi = bgp_dest_get_bgp_path_info(ctx->dest); pi;
pi = pi->next) {
id = bgp_addpath_id_for_peer(peer, afi, safi,
&pi->tx_addpath);
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
if (id == adj->addpath_tx_id) {
break;
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
}
}
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
if (!pi) {
subgroup_process_announce_selected(subgrp, NULL,
ctx->dest, afi, safi,
adj->addpath_tx_id);
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
}
}
}
static int group_announce_route_walkcb(struct update_group *updgrp, void *arg)
{
struct updwalk_context *ctx = arg;
struct update_subgroup *subgrp;
afi_t afi;
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
safi_t safi;
struct peer *peer;
struct bgp_adj_out *adj, *adj_next;
bool addpath_capable;
afi = UPDGRP_AFI(updgrp);
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
safi = UPDGRP_SAFI(updgrp);
peer = UPDGRP_PEER(updgrp);
addpath_capable = bgp_addpath_encode_tx(peer, afi, safi);
if (BGP_DEBUG(update, UPDATE_OUT))
zlog_debug("%s: afi=%s, safi=%s, p=%pBD", __func__,
afi2str(afi), safi2str(safi), ctx->dest);
UPDGRP_FOREACH_SUBGRP (updgrp, subgrp) {
bgpd: Withdraw routes without waiting for the coalescing timer to expire TL;DR; BGP keeps advertising prefixes which were already removed via `network` command. This was happening randomly, but with this patch, no issues happened. Before: ``` frr# sh ip bgp neighbors 10.0.5.1 advertised-routes BGP table version is 586, local router ID is 44.44.33.43, vrf id 0 Default local pref 100, local AS 2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 15.15.15.0/24 0.0.0.0 0 32768 2 i ============> stale entry *> 15.15.16.0/24 0.0.0.0 0 32768 2 i *> 15.15.17.0/24 0.0.0.0 0 32768 2 i frr# sh ip bgp 15.15.15.0/24 % Network not in table ``` Logs: ``` root@b03d1542-0215-5ecf-013d-af2a7150a4f5:~# cat /log/syslog/frr.log | grep 15.15.15.0 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [HVRWP-5R9NQ] u78:s77 send UPDATE 15.15.15.0/24 IPv4 unicast ``` Or imagine the situation where withdrawals are postponed for 20-30s., blackholing happens. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-18 13:25:58 +01:00
/* An update-group that uses addpath */
if (addpath_capable) {
/* Send withdrawals without waiting for coalesting timer
* to expire.
*/
if (subgrp->t_coalesce) {
subgrp_withdraw_stale_addpath(ctx, subgrp);
goto done;
}
bgpd: Withdraw routes without waiting for the coalescing timer to expire TL;DR; BGP keeps advertising prefixes which were already removed via `network` command. This was happening randomly, but with this patch, no issues happened. Before: ``` frr# sh ip bgp neighbors 10.0.5.1 advertised-routes BGP table version is 586, local router ID is 44.44.33.43, vrf id 0 Default local pref 100, local AS 2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 15.15.15.0/24 0.0.0.0 0 32768 2 i ============> stale entry *> 15.15.16.0/24 0.0.0.0 0 32768 2 i *> 15.15.17.0/24 0.0.0.0 0 32768 2 i frr# sh ip bgp 15.15.15.0/24 % Network not in table ``` Logs: ``` root@b03d1542-0215-5ecf-013d-af2a7150a4f5:~# cat /log/syslog/frr.log | grep 15.15.15.0 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [HVRWP-5R9NQ] u78:s77 send UPDATE 15.15.15.0/24 IPv4 unicast ``` Or imagine the situation where withdrawals are postponed for 20-30s., blackholing happens. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-18 13:25:58 +01:00
subgrp_withdraw_stale_addpath(ctx, subgrp);
subgrp_announce_addpath_best_selected(ctx->dest, subgrp);
/* Process the bestpath last so the
* "show [ip] bgp neighbor x.x.x.x advertised" output shows
* the attributes from the bestpath.
*/
if (ctx->pi)
subgroup_process_announce_selected(
subgrp, ctx->pi, ctx->dest, afi, safi,
bgp_addpath_id_for_peer(peer, afi, safi,
&ctx->pi->tx_addpath));
} else {
/* Send withdrawals without waiting for coalesting timer
* to expire.
*/
if (subgrp->t_coalesce) {
if (!ctx->pi || CHECK_FLAG(ctx->pi->flags, BGP_PATH_UNUSEABLE)) {
RB_FOREACH_SAFE (adj, bgp_adj_out_rb, &ctx->dest->adj_out,
adj_next) {
if (adj->subgroup == subgrp) {
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
subgroup_process_announce_selected(
bgpd: Withdraw routes without waiting for the coalescing timer to expire TL;DR; BGP keeps advertising prefixes which were already removed via `network` command. This was happening randomly, but with this patch, no issues happened. Before: ``` frr# sh ip bgp neighbors 10.0.5.1 advertised-routes BGP table version is 586, local router ID is 44.44.33.43, vrf id 0 Default local pref 100, local AS 2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 15.15.15.0/24 0.0.0.0 0 32768 2 i ============> stale entry *> 15.15.16.0/24 0.0.0.0 0 32768 2 i *> 15.15.17.0/24 0.0.0.0 0 32768 2 i frr# sh ip bgp 15.15.15.0/24 % Network not in table ``` Logs: ``` root@b03d1542-0215-5ecf-013d-af2a7150a4f5:~# cat /log/syslog/frr.log | grep 15.15.15.0 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [HVRWP-5R9NQ] u78:s77 send UPDATE 15.15.15.0/24 IPv4 unicast ``` Or imagine the situation where withdrawals are postponed for 20-30s., blackholing happens. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-18 13:25:58 +01:00
subgrp, NULL, ctx->dest, afi, safi,
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
adj->addpath_tx_id);
}
}
}
bgpd: Withdraw routes without waiting for the coalescing timer to expire TL;DR; BGP keeps advertising prefixes which were already removed via `network` command. This was happening randomly, but with this patch, no issues happened. Before: ``` frr# sh ip bgp neighbors 10.0.5.1 advertised-routes BGP table version is 586, local router ID is 44.44.33.43, vrf id 0 Default local pref 100, local AS 2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 15.15.15.0/24 0.0.0.0 0 32768 2 i ============> stale entry *> 15.15.16.0/24 0.0.0.0 0 32768 2 i *> 15.15.17.0/24 0.0.0.0 0 32768 2 i frr# sh ip bgp 15.15.15.0/24 % Network not in table ``` Logs: ``` root@b03d1542-0215-5ecf-013d-af2a7150a4f5:~# cat /log/syslog/frr.log | grep 15.15.15.0 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [HVRWP-5R9NQ] u78:s77 send UPDATE 15.15.15.0/24 IPv4 unicast ``` Or imagine the situation where withdrawals are postponed for 20-30s., blackholing happens. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-18 13:25:58 +01:00
goto done;
}
if (ctx->pi) {
subgroup_process_announce_selected(
subgrp, ctx->pi, ctx->dest, afi, safi,
bgp_addpath_id_for_peer(peer, afi, safi,
&ctx->pi->tx_addpath));
} else {
RB_FOREACH_SAFE (adj, bgp_adj_out_rb, &ctx->dest->adj_out,
adj_next) {
if (adj->subgroup == subgrp) {
subgroup_process_announce_selected(subgrp, NULL,
ctx->dest, afi,
safi,
adj->addpath_tx_id);
}
}
}
}
bgpd: Withdraw routes without waiting for the coalescing timer to expire TL;DR; BGP keeps advertising prefixes which were already removed via `network` command. This was happening randomly, but with this patch, no issues happened. Before: ``` frr# sh ip bgp neighbors 10.0.5.1 advertised-routes BGP table version is 586, local router ID is 44.44.33.43, vrf id 0 Default local pref 100, local AS 2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 15.15.15.0/24 0.0.0.0 0 32768 2 i ============> stale entry *> 15.15.16.0/24 0.0.0.0 0 32768 2 i *> 15.15.17.0/24 0.0.0.0 0 32768 2 i frr# sh ip bgp 15.15.15.0/24 % Network not in table ``` Logs: ``` root@b03d1542-0215-5ecf-013d-af2a7150a4f5:~# cat /log/syslog/frr.log | grep 15.15.15.0 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [K423X-ETGCQ] group_announce_route_walkcb: afi=IPv4, safi=unicast, p=15.15.15.0/24 2024/12/08 07:56:58 BGP: [T5JFA-13199] subgroup_process_announce_selected: p=15.15.15.0/24, selected=0xde4060 2024/12/08 07:56:58 BGP: [HVRWP-5R9NQ] u78:s77 send UPDATE 15.15.15.0/24 IPv4 unicast ``` Or imagine the situation where withdrawals are postponed for 20-30s., blackholing happens. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-18 13:25:58 +01:00
done:
/* Notify BGP Conditional advertisement */
bgp_notify_conditional_adv_scanner(subgrp);
}
return UPDWALK_CONTINUE;
}
static void subgrp_show_adjq_vty(struct update_subgroup *subgrp,
struct vty *vty, uint8_t flags)
{
struct bgp_table *table;
struct bgp_adj_out *adj;
unsigned long output_count;
struct bgp_dest *dest;
int header1 = 1;
struct bgp *bgp;
int header2 = 1;
bgp = SUBGRP_INST(subgrp);
if (!bgp)
return;
table = bgp->rib[SUBGRP_AFI(subgrp)][SUBGRP_SAFI(subgrp)];
output_count = 0;
for (dest = bgp_table_top(table); dest; dest = bgp_route_next(dest)) {
const struct prefix *dest_p = bgp_dest_get_prefix(dest);
RB_FOREACH (adj, bgp_adj_out_rb, &dest->adj_out) {
if (adj->subgroup != subgrp)
continue;
if (header1) {
vty_out(vty,
"BGP table version is %" PRIu64
", local router ID is %pI4\n",
table->version, &bgp->router_id);
vty_out(vty, BGP_SHOW_SCODE_HEADER);
vty_out(vty, BGP_SHOW_OCODE_HEADER);
header1 = 0;
}
if (header2) {
vty_out(vty, BGP_SHOW_HEADER);
header2 = 0;
}
if ((flags & UPDWALK_FLAGS_ADVQUEUE) && adj->adv &&
adj->adv->baa) {
route_vty_out_tmp(vty, bgp, dest, dest_p,
adj->adv->baa->attr,
SUBGRP_SAFI(subgrp), 0, NULL,
false);
output_count++;
}
if ((flags & UPDWALK_FLAGS_ADVERTISED) && adj->attr) {
route_vty_out_tmp(vty, bgp, dest, dest_p,
adj->attr, SUBGRP_SAFI(subgrp),
0, NULL, false);
output_count++;
}
}
}
if (output_count != 0)
vty_out(vty, "\nTotal number of prefixes %ld\n", output_count);
}
static int updgrp_show_adj_walkcb(struct update_group *updgrp, void *arg)
{
struct updwalk_context *ctx = arg;
struct update_subgroup *subgrp;
struct vty *vty;
vty = ctx->vty;
UPDGRP_FOREACH_SUBGRP (updgrp, subgrp) {
if (ctx->subgrp_id && (ctx->subgrp_id != subgrp->id))
continue;
vty_out(vty, "update group %" PRIu64 ", subgroup %" PRIu64 "\n",
updgrp->id, subgrp->id);
subgrp_show_adjq_vty(subgrp, vty, ctx->flags);
}
return UPDWALK_CONTINUE;
}
static void updgrp_show_adj(struct bgp *bgp, afi_t afi, safi_t safi,
struct vty *vty, uint64_t id, uint8_t flags)
{
struct updwalk_context ctx;
memset(&ctx, 0, sizeof(ctx));
ctx.vty = vty;
ctx.subgrp_id = id;
ctx.flags = flags;
update_group_af_walk(bgp, afi, safi, updgrp_show_adj_walkcb, &ctx);
}
static void subgroup_coalesce_timer(struct event *thread)
{
struct update_subgroup *subgrp;
struct bgp *bgp;
safi_t safi;
subgrp = EVENT_ARG(thread);
if (bgp_debug_update(NULL, NULL, subgrp->update_group, 0))
zlog_debug("u%" PRIu64 ":s%" PRIu64" announcing routes upon coalesce timer expiry(%u ms)",
(SUBGRP_UPDGRP(subgrp))->id, subgrp->id,
subgrp->v_coalesce);
subgrp->t_coalesce = NULL;
subgrp->v_coalesce = 0;
bgp = SUBGRP_INST(subgrp);
subgroup_announce_route(subgrp);
safi = SUBGRP_SAFI(subgrp);
/* While the announce_route() may kick off the route advertisement timer
* for
* the members of the subgroup, we'd like to send the initial updates
* much
* faster (i.e., without enforcing MRAI). Also, if there were no routes
* to
* announce, this is the method currently employed to trigger the EOR.
*/
if (!bgp_update_delay_active(SUBGRP_INST(subgrp)) &&
!(bgp_fibupd_safi(safi) && BGP_SUPPRESS_FIB_ENABLED(bgp))) {
struct peer_af *paf;
struct peer *peer;
SUBGRP_FOREACH_PEER (subgrp, paf) {
peer = PAF_PEER(paf);
struct peer_connection *connection = peer->connection;
EVENT_OFF(connection->t_routeadv);
BGP_TIMER_ON(connection->t_routeadv, bgp_routeadv_timer,
0);
}
}
}
static int update_group_announce_walkcb(struct update_group *updgrp, void *arg)
{
struct update_subgroup *subgrp;
UPDGRP_FOREACH_SUBGRP (updgrp, subgrp) {
/* Avoid supressing duplicate routes later
* when processing in subgroup_announce_table().
*/
SET_FLAG(subgrp->sflags, SUBGRP_STATUS_FORCE_UPDATES);
subgroup_announce_all(subgrp);
}
return UPDWALK_CONTINUE;
}
static int update_group_announce_rrc_walkcb(struct update_group *updgrp,
void *arg)
{
struct update_subgroup *subgrp;
afi_t afi;
safi_t safi;
struct peer *peer;
afi = UPDGRP_AFI(updgrp);
safi = UPDGRP_SAFI(updgrp);
peer = UPDGRP_PEER(updgrp);
/* Only announce if this is a group of route-reflector-clients */
if (CHECK_FLAG(peer->af_flags[afi][safi], PEER_FLAG_REFLECTOR_CLIENT)) {
UPDGRP_FOREACH_SUBGRP (updgrp, subgrp) {
subgroup_announce_all(subgrp);
}
}
return UPDWALK_CONTINUE;
}
/********************
* PUBLIC FUNCTIONS
********************/
/**
* Allocate an adj-out object. Do proper initialization of its fields,
* primarily its association with the subgroup and the prefix.
*/
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
struct bgp_adj_out *bgp_adj_out_alloc(struct update_subgroup *subgrp,
struct bgp_dest *dest,
uint32_t addpath_tx_id)
{
struct bgp_adj_out *adj;
adj = XCALLOC(MTYPE_BGP_ADJ_OUT, sizeof(struct bgp_adj_out));
adj->subgroup = subgrp;
adj->addpath_tx_id = addpath_tx_id;
RB_INSERT(bgp_adj_out_rb, &dest->adj_out, adj);
bgp_dest_lock_node(dest);
adj->dest = dest;
TAILQ_INSERT_TAIL(&(subgrp->adjq), adj, subgrp_adj_train);
SUBGRP_INCR_STAT(subgrp, adj_count);
return adj;
}
struct bgp_advertise *
bgp_advertise_clean_subgroup(struct update_subgroup *subgrp,
struct bgp_adj_out *adj)
{
struct bgp_advertise *adv;
struct bgp_advertise_attr *baa;
struct bgp_advertise *next;
struct bgp_adv_fifo_head *fhead;
adv = adj->adv;
baa = adv->baa;
next = NULL;
if (baa) {
fhead = &subgrp->sync->update;
/* Unlink myself from advertise attribute FIFO. */
bgp_advertise_delete(baa, adv);
/* Fetch next advertise candidate. */
next = bgp_advertise_attr_fifo_first(&baa->fifo);
/* Unintern BGP advertise attribute. */
bgp_advertise_attr_unintern(subgrp->hash, baa);
} else
fhead = &subgrp->sync->withdraw;
/* Unlink myself from advertisement FIFO. */
bgp_adv_fifo_del(fhead, adv);
/* Free memory. */
bgp_advertise_free(adj->adv);
adj->adv = NULL;
return next;
}
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
bool bgp_adj_out_set_subgroup(struct bgp_dest *dest,
struct update_subgroup *subgrp, struct attr *attr,
struct bgp_path_info *path)
{
struct bgp_adj_out *adj = NULL;
struct bgp_advertise *adv;
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
struct peer *peer;
afi_t afi;
safi_t safi;
struct peer *adv_peer;
struct peer_af *paf;
struct bgp *bgp;
uint32_t attr_hash = 0;
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
peer = SUBGRP_PEER(subgrp);
afi = SUBGRP_AFI(subgrp);
safi = SUBGRP_SAFI(subgrp);
bgp = SUBGRP_INST(subgrp);
if (DISABLE_BGP_ANNOUNCE)
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
return false;
/* Look for adjacency information. */
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
adj = adj_lookup(
dest, subgrp,
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
bgp_addpath_id_for_peer(peer, afi, safi, &path->tx_addpath));
if (adj) {
if (CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_TABLE_REPARSING))
subgrp->pscount++;
} else {
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
adj = bgp_adj_out_alloc(
subgrp, dest,
bgpd: Re-use TX Addpath IDs where possible The motivation for this patch is to address a concerning behavior of tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was pre-determined as the path was received from a peer. However, this meant that any time the path selected as best from an AS changed, bgpd had no choice but to withdraw the previous best path, and advertise the new best-path under a new TX ID. This could cause significant network disruption, especially for the subset of prefixes coming from only one AS that were also communicated over a bestpath-per-AS session. The patch's general approach is best illustrated by txaddpath_update_ids. After a bestpath run (required for best-per-AS to know what will and will not be sent as addpaths) ID numbers will be stripped from paths that no longer need to be sent, and held in a pool. Then, paths that will be sent as addpaths and do not already have ID numbers will allocate new ID numbers, pulling first from that pool. Finally, anything left in the pool will be returned to the allocator. In order for this to work, ID numbers had to be split by strategy. The tx-addpath-All strategy would keep every ID number "in use" constantly, preventing IDs from being transferred to different paths. Rather than create two variables for ID, this patch create a more generic array that will easily enable more addpath strategies to be implemented. The previously described ID manipulations will happen per addpath strategy, and will only be run for strategies that are enabled on at least one peer. Finally, the ID numbers are allocated from an allocator that tracks per AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very improbable, there was the possibility with the free-running counter approach for rollover to cause two paths on the same prefix to get assigned the same TX ID. As remote as the possibility is, we prefer to not leave it to chance. This ID re-use method is not perfect. In some cases you could still get withdraw-then-add behaviors where not strictly necessary. In the case of bestpath-per-AS this requires one AS to advertise a prefix for the first time, then a second AS withdraws that prefix, all within the space of an already pending MRAI timer. In those situations a withdraw-then-add is more forgivable, and fixing it would probably require a much more significant effort, as IDs would need to be moved to ADVs instead of paths. Signed-off-by Mitchell Skiba <mskiba@amazon.com>
2018-05-10 01:10:02 +02:00
bgp_addpath_id_for_peer(peer, afi, safi,
&path->tx_addpath));
if (!adj)
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
return false;
subgrp->pscount++;
}
/* Check if we are sending the same route. This is needed to
* avoid duplicate UPDATES. For instance, filtering communities
* at egress, neighbors will see duplicate UPDATES despite
* the route wasn't changed actually.
* Do not suppress BGP UPDATES for route-refresh.
*/
if (likely(CHECK_FLAG(bgp->flags, BGP_FLAG_SUPPRESS_DUPLICATES)))
attr_hash = attrhash_key_make(attr);
if (!CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_FORCE_UPDATES) &&
attr_hash && adj->attr_hash == attr_hash &&
bgp_labels_cmp(path->extra ? path->extra->labels : NULL,
adj->labels)) {
if (BGP_DEBUG(update, UPDATE_OUT)) {
char attr_str[BUFSIZ] = {0};
bgp_dump_attr(attr, attr_str, sizeof(attr_str));
zlog_debug("%s suppress UPDATE %pBD w/ attr: %s", peer->host, dest,
attr_str);
}
/*
* If BGP is skipping sending this value to it's peers
* the version number should be updated just like it
* would if it sent the data. Why? Because update
* groups will not be coalesced until such time that
* the version numbers are the same.
*
* Imagine a scenario with say 2 peers and they come
* up and are placed in the same update group. Then
* a new peer comes up a bit later. Then a prefix is
* flapped that we decide for the first 2 peers are
* mapped to and we decide not to send the data to
* it. Then unless more network changes happen we
* will never be able to coalesce the 3rd peer down
*/
subgrp->version = MAX(subgrp->version, dest->version);
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
return false;
}
if (adj->adv)
bgp_advertise_clean_subgroup(subgrp, adj);
adj->adv = bgp_advertise_new();
adv = adj->adv;
adv->dest = dest;
assert(adv->pathi == NULL);
/* bgp_path_info adj_out reference */
adv->pathi = bgp_path_info_lock(path);
adv->baa = bgp_advertise_attr_intern(subgrp->hash, attr);
adv->adj = adj;
adj->attr_hash = attr_hash;
if (path->extra)
adj->labels = bgp_labels_intern(path->extra->labels);
else
adj->labels = NULL;
/* Add new advertisement to advertisement attribute list. */
bgp_advertise_add(adv->baa, adv);
/*
* If the update adv list is empty, trigger the member peers'
* mrai timers so the socket writes can happen.
*/
if (!bgp_adv_fifo_count(&subgrp->sync->update)) {
SUBGRP_FOREACH_PEER (subgrp, paf) {
/* If there are no routes in the withdraw list, set
* the flag PEER_STATUS_ADV_DELAY which will allow
* more routes to be sent in the update message
*/
if (bgp_fibupd_safi(safi) &&
BGP_SUPPRESS_FIB_ENABLED(bgp)) {
adv_peer = PAF_PEER(paf);
if (!bgp_adv_fifo_count(
&subgrp->sync->withdraw))
SET_FLAG(adv_peer->thread_flags,
PEER_THREAD_SUBGRP_ADV_DELAY);
else
UNSET_FLAG(adv_peer->thread_flags,
PEER_THREAD_SUBGRP_ADV_DELAY);
}
bgp_adjust_routeadv(PAF_PEER(paf));
}
}
bgp_adv_fifo_add_tail(&subgrp->sync->update, adv);
subgrp->version = MAX(subgrp->version, dest->version);
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
return true;
}
/* The only time 'withdraw' will be false is if we are sending
* the "neighbor x.x.x.x default-originate" default and need to clear
* bgp_adj_out for the 0.0.0.0/0 route in the BGP table.
*/
void bgp_adj_out_unset_subgroup(struct bgp_dest *dest,
struct update_subgroup *subgrp, char withdraw,
uint32_t addpath_tx_id)
{
struct bgp_adj_out *adj;
struct bgp_advertise *adv;
bool trigger_write;
if (DISABLE_BGP_ANNOUNCE)
return;
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
/* Lookup existing adjacency */
adj = adj_lookup(dest, subgrp, addpath_tx_id);
if (adj != NULL) {
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
/* Clean up previous advertisement. */
if (adj->adv)
bgp_advertise_clean_subgroup(subgrp, adj);
/* If default originate is enabled and the route is default
* route, do not send withdraw. This will prevent deletion of
* the default route at the peer.
*/
if (CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_DEFAULT_ORIGINATE)
&& is_default_prefix(bgp_dest_get_prefix(dest)))
return;
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
if (adj->attr && withdraw) {
/* We need advertisement structure. */
adj->adv = bgp_advertise_new();
adv = adj->adv;
adv->dest = dest;
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
adv->adj = adj;
/* Note if we need to trigger a packet write */
trigger_write =
!bgp_adv_fifo_count(&subgrp->sync->withdraw);
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
/* Add to synchronization entry for withdraw
* announcement. */
bgp_adv_fifo_add_tail(&subgrp->sync->withdraw, adv);
if (trigger_write)
subgroup_trigger_write(subgrp);
} else {
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
/* Free allocated information. */
adj_free(adj);
}
if (!CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_TABLE_REPARSING))
subgrp->pscount--;
}
subgrp->version = MAX(subgrp->version, dest->version);
}
void bgp_adj_out_remove_subgroup(struct bgp_dest *dest, struct bgp_adj_out *adj,
struct update_subgroup *subgrp)
{
if (adj->attr)
bgp_attr_unintern(&adj->attr);
if (adj->adv)
bgp_advertise_clean_subgroup(subgrp, adj);
adj_free(adj);
}
/*
* Go through all the routes and clean up the adj/adv structures corresponding
* to the subgroup.
*/
void subgroup_clear_table(struct update_subgroup *subgrp)
{
struct bgp_adj_out *aout, *taout;
SUBGRP_FOREACH_ADJ_SAFE (subgrp, aout, taout)
bgp_adj_out_remove_subgroup(aout->dest, aout, subgrp);
}
/*
* subgroup_announce_table
*/
void subgroup_announce_table(struct update_subgroup *subgrp,
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
struct bgp_table *table)
{
struct bgp_dest *dest;
struct bgp_path_info *ri;
struct peer *peer;
afi_t afi;
safi_t safi;
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
safi_t safi_rib;
bool addpath_capable;
peer = SUBGRP_PEER(subgrp);
afi = SUBGRP_AFI(subgrp);
safi = SUBGRP_SAFI(subgrp);
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
addpath_capable = bgp_addpath_encode_tx(peer, afi, safi);
if (safi == SAFI_LABELED_UNICAST)
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
safi_rib = SAFI_UNICAST;
else
safi_rib = safi;
if (!table)
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
table = peer->bgp->rib[afi][safi_rib];
if (safi != SAFI_MPLS_VPN && safi != SAFI_ENCAP && safi != SAFI_EVPN
&& CHECK_FLAG(peer->af_flags[afi][safi],
PEER_FLAG_DEFAULT_ORIGINATE))
subgroup_default_originate(subgrp, false);
subgrp->pscount = 0;
SET_FLAG(subgrp->sflags, SUBGRP_STATUS_TABLE_REPARSING);
for (dest = bgp_table_top(table); dest; dest = bgp_route_next(dest)) {
if (addpath_capable)
subgrp_announce_addpath_best_selected(dest, subgrp);
for (ri = bgp_dest_get_bgp_path_info(dest); ri; ri = ri->next) {
if (!bgp_check_selected(ri, peer, addpath_capable, afi,
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
safi_rib))
continue;
/* If default originate is enabled for
* the peer, do not send explicit
* withdraw. This will prevent deletion
* of default route advertised through
* default originate
*/
if (CHECK_FLAG(peer->af_flags[afi][safi],
PEER_FLAG_DEFAULT_ORIGINATE) &&
is_default_prefix(bgp_dest_get_prefix(dest)))
break;
if (CHECK_FLAG(ri->flags, BGP_PATH_SELECTED))
subgroup_process_announce_selected(
subgrp, ri, dest, afi, safi_rib,
bgp_addpath_id_for_peer(
peer, afi, safi_rib,
&ri->tx_addpath));
}
}
UNSET_FLAG(subgrp->sflags, SUBGRP_STATUS_TABLE_REPARSING);
/*
* We walked through the whole table -- make sure our version number
* is consistent with the one on the table. This should allow
* subgroups to merge sooner if a peer comes up when the route node
* with the largest version is no longer in the table. This also
* covers the pathological case where all routes in the table have
* now been deleted.
*/
subgrp->version = MAX(subgrp->version, table->version);
/*
* Start a task to merge the subgroup if necessary.
*/
update_subgroup_trigger_merge_check(subgrp, 0);
}
/*
* subgroup_announce_route
*
* Refresh all routes out to a subgroup.
*/
void subgroup_announce_route(struct update_subgroup *subgrp)
{
struct bgp_dest *dest;
struct bgp_table *table;
struct peer *onlypeer;
if (update_subgroup_needs_refresh(subgrp)) {
update_subgroup_set_needs_refresh(subgrp, 0);
}
/*
* First update is deferred until ORF or ROUTE-REFRESH is received
*/
onlypeer = ((SUBGRP_PCOUNT(subgrp) == 1) ? (SUBGRP_PFIRST(subgrp))->peer
: NULL);
if (onlypeer && CHECK_FLAG(onlypeer->af_sflags[SUBGRP_AFI(subgrp)]
[SUBGRP_SAFI(subgrp)],
PEER_STATUS_ORF_WAIT_REFRESH))
return;
if (SUBGRP_SAFI(subgrp) != SAFI_MPLS_VPN
&& SUBGRP_SAFI(subgrp) != SAFI_ENCAP
&& SUBGRP_SAFI(subgrp) != SAFI_EVPN)
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
subgroup_announce_table(subgrp, NULL);
else
for (dest = bgp_table_top(update_subgroup_rib(subgrp)); dest;
dest = bgp_route_next(dest)) {
table = bgp_dest_get_bgp_table_info(dest);
if (!table)
continue;
subgroup_announce_table(subgrp, table);
}
}
void subgroup_default_originate(struct update_subgroup *subgrp, bool withdraw)
{
struct bgp *bgp;
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
struct attr attr = { 0 };
struct attr *new_attr = &attr;
struct aspath *aspath;
struct prefix p;
struct peer *from;
struct bgp_dest *dest;
struct bgp_path_info *pi;
struct peer *peer;
struct bgp_adj_out *adj;
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP Introducing a 3rd state for route_map_apply library function: RMAP_NOOP Traditionally route map MATCH rule apis were designed to return a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH. (Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR). Depending on this response, the following statemachine decided the course of action: State1: If match cmd returns RMAP_MATCH then, keep existing behaviour. If routemap type is PERMIT, execute set cmds or call cmds if applicable, otherwise PERMIT! Else If routemap type is DENY, we DENYMATCH right away State2: If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH We require a 3rd state because of the following situation: The issue - what if, the rule api needs to abort or ignore a rule?: "match evpn vni xx" route-map filter can be applied to incoming routes regardless of whether the tunnel type is vxlan or mpls. This rule should be N/A for mpls based evpn route, but applicable to only vxlan based evpn route. Also, this rule should be applicable for routes with VNI label only, and not for routes without labels. For example, type 3 and type 4 EVPN routes do not have labels, so, this match cmd should let them through. Today, the filter produces either a match or nomatch response regardless of whether it is mpls/vxlan, resulting in either permitting or denying the route.. So an mpls evpn route may get filtered out incorrectly. Eg: "route-map RM1 permit 10 ; match evpn vni 20" or "route-map RM2 deny 20 ; match vni 20" With the introduction of the 3rd state, we can abort this rule check safely. How? The rules api can now return RMAP_NOOP to indicate that it encountered an invalid check, and needs to abort just that rule, but continue with other rules. As a result we have a 3rd state: State3: If match cmd returned RMAP_NOOP Then, proceed to other route-map, otherwise if there are no more rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH. Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
2019-06-19 23:04:36 +02:00
route_map_result_t ret = RMAP_DENYMATCH;
route_map_result_t new_ret = RMAP_DENYMATCH;
afi_t afi;
safi_t safi;
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
safi_t safi_rib;
int pref = 65536;
int new_pref = 0;
if (!subgrp)
return;
peer = SUBGRP_PEER(subgrp);
afi = SUBGRP_AFI(subgrp);
safi = SUBGRP_SAFI(subgrp);
if (!(afi == AFI_IP || afi == AFI_IP6))
return;
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
if (safi == SAFI_LABELED_UNICAST)
safi_rib = SAFI_UNICAST;
else
safi_rib = safi;
bgp = peer->bgp;
from = bgp->peer_self;
bgp_attr_default_set(&attr, bgp, BGP_ORIGIN_IGP);
/* make coverity happy */
assert(attr.aspath);
aspath = attr.aspath;
bgp_attr_set_med(&attr, 0);
if ((afi == AFI_IP6) || peer_cap_enhe(peer, afi, safi)) {
/* IPv6 global nexthop must be included. */
attr.mp_nexthop_len = BGP_ATTR_NHLEN_IPV6_GLOBAL;
/* If the peer is on shared nextwork and we have link-local
nexthop set it. */
if (peer->shared_network
&& !IN6_IS_ADDR_UNSPECIFIED(&peer->nexthop.v6_local))
attr.mp_nexthop_len = BGP_ATTR_NHLEN_IPV6_GLOBAL_AND_LL;
}
if (peer->default_rmap[afi][safi].name) {
struct bgp_path_info tmp_pi = {0};
tmp_pi.peer = bgp->peer_self;
SET_FLAG(bgp->peer_self->rmap_type, PEER_RMAP_TYPE_DEFAULT);
/* Iterate over the RIB to see if we can announce
* the default route. We announce the default
* route only if route-map has a match.
*/
bgpd: Announce labeled-unicast default-originate Without this patch, this just crashes: ``` (gdb) bt 0 raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f66d977b10c in core_handler (signo=11, siginfo=0x7ffd87aa0430, context=<optimized out>) at lib/sigevent.c:261 2 <signal handler called> 3 stream_put_labeled_prefix (s=s@entry=0x55bd3ce53050, p=p@entry=0x7ffd87aa0a20, label=label@entry=0x0, addpath_capable=<optimized out>, addpath_tx_id=addpath_tx_id@entry=1) at lib/stream.c:1057 4 0x000055bd3bfba176 in bgp_packet_mpattr_prefix (s=s@entry=0x55bd3ce53050, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, p=p@entry=0x7ffd87aa0a20, prd=prd@entry=0x0, label=label@entry=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, attr=0x7ffd87aa2c20) at bgpd/bgp_attr.c:3964 5 0x000055bd3bfba2b5 in bgp_packet_attribute (bgp=0x55bd3cd8e470, bgp@entry=0x0, peer=peer@entry=0x55bd3cf21fc0, s=s@entry=0x55bd3ce53050, attr=attr@entry=0x7ffd87aa2c20, vecarr=vecarr@entry=0x7ffd87aa0a10, p=p@entry=0x7ffd87aa0a20, afi=AFI_IP, safi=SAFI_LABELED_UNICAST, from=0x7f66d9ba9010, prd=0x0, label=0x0, num_labels=0, addpath_capable=true, addpath_tx_id=1, bpi=0x0) at bgpd/bgp_attr.c:4139 6 0x000055bd3c04d455 in subgroup_default_update_packet (subgrp=subgrp@entry=0x55bd3cd885b0, attr=attr@entry=0x7ffd87aa2c20, from=from@entry=0x7f66d9ba9010) at bgpd/bgp_updgrp_packet.c:1129 7 0x000055bd3c04a9a5 in subgroup_default_originate (subgrp=0x55bd3cd885b0, withdraw=withdraw@entry=0) at bgpd/bgp_updgrp_adv.c:972 8 0x000055bd3c022668 in bgp_default_originate (peer=peer@entry=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, withdraw=withdraw@entry=0) at bgpd/bgp_route.c:5037 9 0x000055bd3c0922e0 in peer_default_originate_set (peer=0x7f66d574a010, afi=afi@entry=AFI_IP, safi=safi@entry=SAFI_LABELED_UNICAST, rmap=rmap@entry=0x0, route_map=route_map@entry=0x0) at bgpd/bgpd.c:5428 10 0x000055bd3c076c07 in peer_default_originate_set_vty (set=1, rmap=0x0, safi=SAFI_LABELED_UNICAST, afi=AFI_IP, peer_str=<optimized out>, vty=0x55bd3ce4c900) at bgpd/bgp_vty.c:6941 11 neighbor_default_originate (self=<optimized out>, vty=0x55bd3ce4c900, argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_vty.c:6958 12 0x00007f66d9721dc0 in cmd_execute_command_real (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, up_level=up_level@entry=0, filter=FILTER_RELAXED) at lib/command.c:996 13 0x00007f66d9721f39 in cmd_execute_command (vline=vline@entry=0x55bd3cd874d0, vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1055 14 0x00007f66d9722162 in cmd_execute (vty=vty@entry=0x55bd3ce4c900, cmd=cmd@entry=0x55bd3cd8a230 "neighbor 192.168.34.4 default-originate ", matched=matched@entry=0x0, vtysh=vtysh@entry=0) at lib/command.c:1223 15 0x00007f66d9792337 in vty_command (vty=vty@entry=0x55bd3ce4c900, buf=<optimized out>) at lib/vty.c:486 16 0x00007f66d9792570 in vty_execute (vty=0x55bd3ce4c900) at lib/vty.c:1249 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2022-12-07 21:57:29 +01:00
for (dest = bgp_table_top(bgp->rib[afi][safi_rib]); dest;
dest = bgp_route_next(dest)) {
if (!bgp_dest_has_bgp_path_info_data(dest))
continue;
for (pi = bgp_dest_get_bgp_path_info(dest); pi;
pi = pi->next) {
struct attr tmp_attr = attr;
tmp_pi.attr = &tmp_attr;
new_ret = route_map_apply_ext(
peer->default_rmap[afi][safi].map,
bgp_dest_get_prefix(dest), pi, &tmp_pi,
&new_pref);
if (new_ret == RMAP_PERMITMATCH) {
if (new_pref < pref) {
pref = new_pref;
bgp_attr_flush(new_attr);
new_attr = bgp_attr_intern(
tmp_pi.attr);
}
bgp_attr_flush(tmp_pi.attr);
subgroup_announce_reset_nhop(
(peer_cap_enhe(peer, afi, safi)
? AF_INET6
: AF_INET),
new_attr);
ret = new_ret;
} else
bgp_attr_flush(&tmp_attr);
}
}
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
bgp->peer_self->rmap_type = 0;
if (ret == RMAP_DENYMATCH) {
/*
* If its a implicit withdraw due to routemap
* deny operation need to set the flag back.
* This is a convertion of update flow to
* withdraw flow.
*/
if (!withdraw &&
(!CHECK_FLAG(subgrp->sflags,
SUBGRP_STATUS_DEFAULT_ORIGINATE)))
SET_FLAG(subgrp->sflags,
SUBGRP_STATUS_DEFAULT_ORIGINATE);
withdraw = true;
}
}
/* Check if the default route is in local BGP RIB which is
* installed through redistribute or network command
*/
memset(&p, 0, sizeof(p));
p.family = afi2family(afi);
p.prefixlen = 0;
dest = bgp_safi_node_lookup(bgp->rib[afi][safi_rib], safi_rib, &p,
NULL);
if (withdraw) {
/* Withdraw the default route advertised using default
* originate
*/
if (CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_DEFAULT_ORIGINATE))
subgroup_default_withdraw_packet(subgrp);
UNSET_FLAG(subgrp->sflags, SUBGRP_STATUS_DEFAULT_ORIGINATE);
/* If default route is present in the local RIB, advertise the
* route
*/
if (dest) {
for (pi = bgp_dest_get_bgp_path_info(dest); pi;
pi = pi->next) {
bgpd: Ensure community data is freed in some cases. Customer has this valgrind trace: Direct leak of 2829120 byte(s) in 70728 object(s) allocated from: 0 in community_new ../bgpd/bgp_community.c:39 1 in community_uniq_sort ../bgpd/bgp_community.c:170 2 in route_set_community ../bgpd/bgp_routemap.c:2342 3 in route_map_apply_ext ../lib/routemap.c:2673 4 in subgroup_announce_check ../bgpd/bgp_route.c:2367 5 in subgroup_process_announce_selected ../bgpd/bgp_route.c:2914 6 in group_announce_route_walkcb ../bgpd/bgp_updgrp_adv.c:199 7 in hash_walk ../lib/hash.c:285 8 in update_group_af_walk ../bgpd/bgp_updgrp.c:2061 9 in group_announce_route ../bgpd/bgp_updgrp_adv.c:1059 10 in bgp_process_main_one ../bgpd/bgp_route.c:3221 11 in bgp_process_wq ../bgpd/bgp_route.c:3221 12 in work_queue_run ../lib/workqueue.c:282 The above leak detected by valgrind was from a screenshot so I copied it by hand. Any mistakes in line numbers are purely from my transcription. Additionally this is against a slightly modified 8.5.1 version of FRR. Code inspection of 8.5.1 -vs- latest master shows the same problem exists. Code should be able to be followed from there to here. What is happening: There is a route-map being applied that modifes the outgoing community to a peer. This is saved in the attr copy created in subgroup_process_announce_selected. This community pointer is not interned. So the community->refcount is still 0. Normally when a prefix is announced, the attr and the prefix are placed on a adjency out structure where the attribute is interned. This will cause the community to be saved in the community hash list as well. In a non-normal operation when the decision to send is aborted after the route-map application, the attribute is just dropped and the pointer to the community is just dropped too, leading to situations where the memory is leaked. The usage of bgp suppress-fib would would be a case where the community is caused to be leaked. Additionally the previous commit where an unsuppress-map is used to modify the outgoing attribute but since unsuppress-map was not considered part of outgoing policy the attribute would be dropped as well. This pointer drop also extends to any dynamically allocated memory saved by the attribute pointer that was not interned yet as well. So let's modify the return case where the decision is made to not send the prefix to the peer to always just flush the attribute to ensure memory is not leaked. Fixes: #15459 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-03-02 15:50:38 +01:00
if (!CHECK_FLAG(pi->flags, BGP_PATH_SELECTED))
continue;
if (subgroup_announce_check(dest, pi, subgrp,
bgp_dest_get_prefix(
dest),
&attr, NULL)) {
if (!bgp_adj_out_set_subgroup(dest,
subgrp,
&attr, pi))
bgp_attr_flush(&attr);
} else
bgp_attr_flush(&attr);
}
bgp_dest_unlock_node(dest);
}
} else {
if (!CHECK_FLAG(subgrp->sflags,
SUBGRP_STATUS_DEFAULT_ORIGINATE)) {
/* The 'neighbor x.x.x.x default-originate' default will
* act as an
* implicit withdraw for any previous UPDATEs sent for
* 0.0.0.0/0 so
* clear adj_out for the 0.0.0.0/0 prefix in the BGP
* table.
*/
if (dest) {
/* Remove the adjacency for the previously
* advertised default route
*/
adj = adj_lookup(
dest, subgrp,
BGP_ADDPATH_TX_ID_FOR_DEFAULT_ORIGINATE);
if (adj != NULL) {
/* Clean up previous advertisement. */
if (adj->adv)
bgp_advertise_clean_subgroup(
subgrp, adj);
/* Free allocated information. */
adj_free(adj);
}
bgp_dest_unlock_node(dest);
}
/* Advertise the default route */
if (bgp_in_graceful_shutdown(bgp))
bgp_attr_add_gshut_community(new_attr);
SET_FLAG(subgrp->sflags,
SUBGRP_STATUS_DEFAULT_ORIGINATE);
subgroup_default_update_packet(subgrp, new_attr, from);
}
}
aspath_unintern(&aspath);
}
/*
* Announce the BGP table to a subgroup.
*
* At startup, we try to optimize route announcement by coalescing the
* peer-up events. This is done only the first time - from then on,
* subgrp->v_coalesce will be set to zero and the normal logic
* prevails.
*/
void subgroup_announce_all(struct update_subgroup *subgrp)
{
if (!subgrp)
return;
/*
* If coalesce timer value is not set, announce routes immediately.
*/
if (!subgrp->v_coalesce) {
if (bgp_debug_update(NULL, NULL, subgrp->update_group, 0))
zlog_debug("u%" PRIu64 ":s%" PRIu64" announcing all routes",
subgrp->update_group->id, subgrp->id);
subgroup_announce_route(subgrp);
return;
}
/*
* We should wait for the coalesce timer. Arm the timer if not done.
*/
if (!subgrp->t_coalesce) {
event_add_timer_msec(bm->master, subgroup_coalesce_timer,
subgrp, subgrp->v_coalesce,
&subgrp->t_coalesce);
}
}
/*
* Go through all update subgroups and set up the adv queue for the
* input route.
*/
void group_announce_route(struct bgp *bgp, afi_t afi, safi_t safi,
struct bgp_dest *dest, struct bgp_path_info *pi)
{
struct updwalk_context ctx;
ctx.pi = pi;
ctx.dest = dest;
/* If suppress fib is enabled, the route will be advertised when
* FIB status is received
*/
if (!bgp_check_advertise(bgp, dest, safi))
return;
update_group_af_walk(bgp, afi, safi, group_announce_route_walkcb, &ctx);
}
void update_group_show_adj_queue(struct bgp *bgp, afi_t afi, safi_t safi,
struct vty *vty, uint64_t id)
{
updgrp_show_adj(bgp, afi, safi, vty, id, UPDWALK_FLAGS_ADVQUEUE);
}
void update_group_show_advertised(struct bgp *bgp, afi_t afi, safi_t safi,
struct vty *vty, uint64_t id)
{
updgrp_show_adj(bgp, afi, safi, vty, id, UPDWALK_FLAGS_ADVERTISED);
}
void update_group_announce(struct bgp *bgp)
{
update_group_walk(bgp, update_group_announce_walkcb, NULL);
}
void update_group_announce_rrclients(struct bgp *bgp)
{
update_group_walk(bgp, update_group_announce_rrc_walkcb, NULL);
}