frr/bgpd/bgp_updgrp_adv.c

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

1071 lines
27 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 "event.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)
{
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);
}
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, 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;
struct bgp_path_info *pi;
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=%pRN", __func__,
afi2str(afi), safi2str(safi),
bgp_dest_to_rnode(ctx->dest));
UPDGRP_FOREACH_SUBGRP (updgrp, subgrp) {
/*
* Skip the subgroups that have coalesce timer running. We will
* walk the entire prefix table for those subgroups when the
* coalesce timer fires.
*/
if (!subgrp->t_coalesce) {
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
/* An update-group that uses addpath */
if (addpath_capable) {
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
subgrp_withdraw_stale_addpath(ctx, subgrp);
for (pi = bgp_dest_get_bgp_path_info(ctx->dest);
pi; pi = pi->next) {
/* Skip the bestpath for now */
if (pi == ctx->pi)
continue;
subgroup_process_announce_selected(
subgrp, pi, ctx->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,
&pi->tx_addpath));
}
/* 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,
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,
&ctx->pi->tx_addpath));
}
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
/* An update-group that does not use addpath */
else {
if (ctx->pi) {
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(
subgrp, ctx->pi, ctx->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,
&ctx->pi->tx_addpath));
} 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
/* Find the addpath_tx_id of the path we
* had advertised and
* send a withdraw */
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(
subgrp, NULL,
ctx->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
adj->addpath_tx_id);
}
}
}
}
}
/* 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, 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, 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;
subgrp = THREAD_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);
/* 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_SUPPRESS_FIB_ENABLED(bgp))) {
struct peer_af *paf;
struct peer *peer;
SUBGRP_FOREACH_PEER (subgrp, paf) {
peer = PAF_PEER(paf);
THREAD_OFF(peer->t_routeadv);
BGP_TIMER_ON(peer->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 = baa->adv;
/* 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;
}
void 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 = attrhash_key_make(attr);
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)
return;
/* 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)
return;
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 (CHECK_FLAG(bgp->flags, BGP_FLAG_SUPPRESS_DUPLICATES)
&& !CHECK_FLAG(subgrp->sflags, SUBGRP_STATUS_FORCE_UPDATES)
&& adj->attr_hash == attr_hash) {
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 w/ attr: %s", peer->host,
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);
return;
}
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;
/* 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_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);
}
/* 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 attr attr;
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;
struct bgp *bgp;
bool advertise;
peer = SUBGRP_PEER(subgrp);
afi = SUBGRP_AFI(subgrp);
safi = SUBGRP_SAFI(subgrp);
bgp = SUBGRP_INST(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, 0);
subgrp->pscount = 0;
SET_FLAG(subgrp->sflags, SUBGRP_STATUS_TABLE_REPARSING);
for (dest = bgp_table_top(table); dest; dest = bgp_route_next(dest)) {
const struct prefix *dest_p = bgp_dest_get_prefix(dest);
/* Check if the route can be advertised */
advertise = bgp_check_advertise(bgp, dest);
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 (subgroup_announce_check(dest, ri, subgrp, dest_p,
&attr, NULL)) {
/* Check if route can be advertised */
if (advertise) {
bgpd: Intern attributes before putting into rib-out After we call subgroup_announce_check(), we leave communities, large-communities that are modified by route-maps uninterned, and here we have a memory leak. ``` ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d90037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b15b2 in qcalloc lib/memory.c:105 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e08d2 in lcommunity_new bgpd/bgp_lcommunity.c:28 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c4e11d9 in lcommunity_dup bgpd/bgp_lcommunity.c:141 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #14 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Indirect leak of 144 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d8fe8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b1579 in qmalloc lib/memory.c:100 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e1282 in lcommunity_dup bgpd/bgp_lcommunity.c:144 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-SUMMARY: AddressSanitizer: 224 byte(s) leaked in 4 allocation(s). ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-27 22:40:32 +01:00
if (!bgp_check_withdrawal(bgp, dest)) {
struct attr *adv_attr =
bgp_attr_intern(&attr);
bgp_adj_out_set_subgroup(
bgpd: Intern attributes before putting into rib-out After we call subgroup_announce_check(), we leave communities, large-communities that are modified by route-maps uninterned, and here we have a memory leak. ``` ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d90037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b15b2 in qcalloc lib/memory.c:105 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e08d2 in lcommunity_new bgpd/bgp_lcommunity.c:28 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c4e11d9 in lcommunity_dup bgpd/bgp_lcommunity.c:141 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #14 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Indirect leak of 144 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d8fe8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b1579 in qmalloc lib/memory.c:100 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e1282 in lcommunity_dup bgpd/bgp_lcommunity.c:144 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-SUMMARY: AddressSanitizer: 224 byte(s) leaked in 4 allocation(s). ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-27 22:40:32 +01:00
dest, subgrp, adv_attr,
ri);
bgpd: Intern attributes before putting into rib-out After we call subgroup_announce_check(), we leave communities, large-communities that are modified by route-maps uninterned, and here we have a memory leak. ``` ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Direct leak of 80 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d90037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b15b2 in qcalloc lib/memory.c:105 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e08d2 in lcommunity_new bgpd/bgp_lcommunity.c:28 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c4e11d9 in lcommunity_dup bgpd/bgp_lcommunity.c:141 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #14 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323:Indirect leak of 144 byte(s) in 2 object(s) allocated from: ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #0 0x7f0858d8fe8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #1 0x7f08589b1579 in qmalloc lib/memory.c:100 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #2 0x561f5c4e1282 in lcommunity_dup bgpd/bgp_lcommunity.c:144 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #3 0x561f5c5c3b8b in route_set_lcommunity bgpd/bgp_routemap.c:2491 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #4 0x7f0858a177a5 in route_map_apply_ext lib/routemap.c:2675 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #5 0x561f5c5696f9 in subgroup_announce_check bgpd/bgp_route.c:2352 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #6 0x561f5c5fb728 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:682 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #7 0x561f5c5fbd95 in subgroup_announce_route bgpd/bgp_updgrp_adv.c:765 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #8 0x561f5c5f6105 in peer_af_announce_route bgpd/bgp_updgrp.c:2187 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #9 0x561f5c5790be in bgp_announce_route_timer_expired bgpd/bgp_route.c:5032 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #10 0x7f0858a76e4e in thread_call lib/thread.c:1991 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #11 0x7f0858974c24 in frr_run lib/libfrr.c:1185 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #12 0x561f5c3e955d in main bgpd/bgp_main.c:505 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- #13 0x7f08583a9d09 in __libc_start_main ../csu/libc-start.c:308 ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323- ./bgp_large_community.test_bgp_large_community_topo_2/r1.bgpd.asan.2465323-SUMMARY: AddressSanitizer: 224 byte(s) leaked in 4 allocation(s). ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-27 22:40:32 +01:00
} else
bgp_adj_out_unset_subgroup(
dest, subgrp, 1,
bgp_addpath_id_for_peer(
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
peer, afi,
safi_rib,
&ri->tx_addpath));
}
} else {
/* 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;
bgp_adj_out_unset_subgroup(
dest, subgrp, 1,
bgp_addpath_id_for_peer(
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
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, int withdraw)
{
struct bgp *bgp;
struct attr attr;
struct attr *new_attr = &attr;
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);
attr.med = 0;
attr.flag |= ATTR_FLAG_BIT(BGP_ATTR_MULTI_EXIT_DISC);
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);
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
withdraw = 1;
}
}
/* 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) {
if (CHECK_FLAG(pi->flags, BGP_PATH_SELECTED))
if (subgroup_announce_check(
dest, pi, subgrp,
bgp_dest_get_prefix(dest),
bgpd: Intern default-originate attributes to avoid use-after-free When we receive a default route from a peer and we originate default route using `neighbor default-originate`, we do not track of struct attr we use, and when we do `no neighbor default-originate` we withdraw our generated default route, but we announce default-route from the peer. After we do this, we unintern aspath (which was used for default-originate), BUT it was used also for peer's default route we received. And here we have a use-after-free crash, because bgp_process_main_one() reaps old paths that are marked as BGP_PATH_REMOVED with aspath->refcnt > 0, but here it's 0. ``` 0 0x55c24bbcd022 in aspath_key_make bgpd/bgp_aspath.c:2070 1 0x55c24b8f1140 in attrhash_key_make bgpd/bgp_attr.c:777 2 0x7f52322e66c9 in hash_release lib/hash.c:220 3 0x55c24b8f6017 in bgp_attr_unintern bgpd/bgp_attr.c:1271 4 0x55c24ba0acaa in bgp_path_info_free_with_caller bgpd/bgp_route.c:283 5 0x55c24ba0a7de in bgp_path_info_unlock bgpd/bgp_route.c:309 6 0x55c24ba0af6d in bgp_path_info_reap bgpd/bgp_route.c:426 7 0x55c24ba17b9a in bgp_process_main_one bgpd/bgp_route.c:3333 8 0x55c24ba18a1d in bgp_process_wq bgpd/bgp_route.c:3425 9 0x7f52323c2cd5 in work_queue_run lib/workqueue.c:282 10 0x7f52323aab92 in thread_call lib/thread.c:2006 11 0x7f5232300dc7 in frr_run lib/libfrr.c:1198 12 0x55c24b8ea792 in main bgpd/bgp_main.c:520 13 0x7f5231c3a082 in __libc_start_main ../csu/libc-start.c:308 14 0x55c24b8ef0bd in _start (/usr/lib/frr/bgpd+0x2c90bd) ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-09 21:29:25 +01:00
&attr, NULL)) {
struct attr *default_attr =
bgp_attr_intern(&attr);
bgp_adj_out_set_subgroup(
bgpd: Intern default-originate attributes to avoid use-after-free When we receive a default route from a peer and we originate default route using `neighbor default-originate`, we do not track of struct attr we use, and when we do `no neighbor default-originate` we withdraw our generated default route, but we announce default-route from the peer. After we do this, we unintern aspath (which was used for default-originate), BUT it was used also for peer's default route we received. And here we have a use-after-free crash, because bgp_process_main_one() reaps old paths that are marked as BGP_PATH_REMOVED with aspath->refcnt > 0, but here it's 0. ``` 0 0x55c24bbcd022 in aspath_key_make bgpd/bgp_aspath.c:2070 1 0x55c24b8f1140 in attrhash_key_make bgpd/bgp_attr.c:777 2 0x7f52322e66c9 in hash_release lib/hash.c:220 3 0x55c24b8f6017 in bgp_attr_unintern bgpd/bgp_attr.c:1271 4 0x55c24ba0acaa in bgp_path_info_free_with_caller bgpd/bgp_route.c:283 5 0x55c24ba0a7de in bgp_path_info_unlock bgpd/bgp_route.c:309 6 0x55c24ba0af6d in bgp_path_info_reap bgpd/bgp_route.c:426 7 0x55c24ba17b9a in bgp_process_main_one bgpd/bgp_route.c:3333 8 0x55c24ba18a1d in bgp_process_wq bgpd/bgp_route.c:3425 9 0x7f52323c2cd5 in work_queue_run lib/workqueue.c:282 10 0x7f52323aab92 in thread_call lib/thread.c:2006 11 0x7f5232300dc7 in frr_run lib/libfrr.c:1198 12 0x55c24b8ea792 in main bgpd/bgp_main.c:520 13 0x7f5231c3a082 in __libc_start_main ../csu/libc-start.c:308 14 0x55c24b8ef0bd in _start (/usr/lib/frr/bgpd+0x2c90bd) ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-02-09 21:29:25 +01:00
dest, subgrp,
default_attr, pi);
}
}
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(&attr.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) {
thread_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))
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);
}