2002-12-13 21:15:29 +01:00
|
|
|
/* BGP message definition header.
|
2017-05-13 10:25:29 +02:00
|
|
|
* Copyright (C) 1996, 97, 98, 99, 2000 Kunihiro Ishiguro
|
|
|
|
*
|
|
|
|
* This file is part of GNU Zebra.
|
|
|
|
*
|
|
|
|
* GNU Zebra is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2, or (at your option) any
|
|
|
|
* later version.
|
|
|
|
*
|
|
|
|
* GNU Zebra is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; see the file COPYING; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
*/
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2005-05-23 16:19:54 +02:00
|
|
|
#ifndef _QUAGGA_BGPD_H
|
|
|
|
#define _QUAGGA_BGPD_H
|
|
|
|
|
2016-12-07 12:25:24 +01:00
|
|
|
#include "qobj.h"
|
2017-02-07 00:39:06 +01:00
|
|
|
#include <pthread.h>
|
|
|
|
|
2019-05-10 15:31:04 +02:00
|
|
|
#include "hook.h"
|
2018-09-12 21:23:52 +02:00
|
|
|
#include "frr_pthread.h"
|
2015-08-12 15:59:18 +02:00
|
|
|
#include "lib/json.h"
|
2016-02-02 13:36:20 +01:00
|
|
|
#include "vrf.h"
|
2017-03-02 02:45:55 +01:00
|
|
|
#include "vty.h"
|
2019-06-02 21:02:07 +02:00
|
|
|
#include "iana_afi.h"
|
2016-02-02 13:36:20 +01:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* For union sockunion. */
|
2015-05-20 03:03:47 +02:00
|
|
|
#include "queue.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
#include "sockunion.h"
|
2015-05-20 02:40:45 +02:00
|
|
|
#include "routemap.h"
|
2015-05-20 03:12:17 +02:00
|
|
|
#include "linklist.h"
|
2017-03-09 19:00:19 +01:00
|
|
|
#include "defaults.h"
|
2015-05-29 05:48:31 +02:00
|
|
|
#include "bgp_memory.h"
|
2017-05-15 23:27:51 +02:00
|
|
|
#include "bitfield.h"
|
2017-10-09 02:46:08 +02:00
|
|
|
#include "vxlan.h"
|
2018-04-07 20:13:07 +02:00
|
|
|
#include "bgp_labelpool.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 "bgp_addpath_types.h"
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2015-09-11 05:10:16 +02:00
|
|
|
#define BGP_MAX_HOSTNAME 64 /* Linux max, is larger than most other sys */
|
2017-07-31 23:22:23 +02:00
|
|
|
#define BGP_PEER_MAX_HASH_SIZE 16384
|
2015-09-11 05:10:16 +02:00
|
|
|
|
2016-05-13 01:51:43 +02:00
|
|
|
/* Default interval for IPv6 RAs when triggered by BGP unnumbered neighbor. */
|
|
|
|
#define BGP_UNNUM_DEFAULT_RA_INTERVAL 10
|
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
struct update_subgroup;
|
|
|
|
struct bpacket;
|
2018-04-25 18:29:35 +02:00
|
|
|
struct bgp_pbr_config;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2015-05-20 03:04:25 +02:00
|
|
|
/*
|
|
|
|
* Allow the neighbor XXXX remote-as to take internal or external
|
2017-07-17 14:03:14 +02:00
|
|
|
* AS_SPECIFIED is zero to auto-inherit original non-feature/enhancement
|
|
|
|
* behavior
|
2015-05-20 03:04:25 +02:00
|
|
|
* in the system.
|
|
|
|
*/
|
2017-07-17 14:03:14 +02:00
|
|
|
enum { AS_UNSPECIFIED = 0,
|
|
|
|
AS_SPECIFIED,
|
|
|
|
AS_INTERNAL,
|
|
|
|
AS_EXTERNAL,
|
2015-05-20 03:04:25 +02:00
|
|
|
};
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* Typedef BGP specific types. */
|
2018-03-27 21:13:34 +02:00
|
|
|
typedef uint32_t as_t;
|
|
|
|
typedef uint16_t as16_t; /* we may still encounter 16 Bit asnums */
|
|
|
|
typedef uint16_t bgp_size_t;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
#define max(a, b) \
|
|
|
|
({ \
|
|
|
|
__typeof__(a) _a = (a); \
|
|
|
|
__typeof__(b) _b = (b); \
|
|
|
|
_a > _b ? _a : _b; \
|
|
|
|
})
|
|
|
|
|
|
|
|
enum bgp_af_index {
|
|
|
|
BGP_AF_START,
|
|
|
|
BGP_AF_IPV4_UNICAST = BGP_AF_START,
|
|
|
|
BGP_AF_IPV4_MULTICAST,
|
|
|
|
BGP_AF_IPV4_VPN,
|
|
|
|
BGP_AF_IPV6_UNICAST,
|
|
|
|
BGP_AF_IPV6_MULTICAST,
|
|
|
|
BGP_AF_IPV6_VPN,
|
|
|
|
BGP_AF_IPV4_ENCAP,
|
|
|
|
BGP_AF_IPV6_ENCAP,
|
|
|
|
BGP_AF_L2VPN_EVPN,
|
|
|
|
BGP_AF_IPV4_LBL_UNICAST,
|
|
|
|
BGP_AF_IPV6_LBL_UNICAST,
|
2017-01-23 03:45:30 +01:00
|
|
|
BGP_AF_IPV4_FLOWSPEC,
|
|
|
|
BGP_AF_IPV6_FLOWSPEC,
|
2017-07-17 14:03:14 +02:00
|
|
|
BGP_AF_MAX
|
2015-05-20 03:03:47 +02:00
|
|
|
};
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
#define AF_FOREACH(af) for ((af) = BGP_AF_START; (af) < BGP_AF_MAX; (af)++)
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
#define FOREACH_AFI_SAFI(afi, safi) \
|
|
|
|
for (afi = AFI_IP; afi < AFI_MAX; afi++) \
|
|
|
|
for (safi = SAFI_UNICAST; safi < SAFI_MAX; safi++)
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2019-02-24 10:30:31 +01:00
|
|
|
#define FOREACH_SAFI(safi) \
|
|
|
|
for (safi = SAFI_UNICAST; safi < SAFI_MAX; safi++)
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2018-09-12 21:23:52 +02:00
|
|
|
extern struct frr_pthread *bgp_pth_io;
|
|
|
|
extern struct frr_pthread *bgp_pth_ka;
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP master for system wide configurations and variables. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_master {
|
|
|
|
/* BGP instance list. */
|
|
|
|
struct list *bgp;
|
|
|
|
|
|
|
|
/* BGP thread master. */
|
|
|
|
struct thread_master *master;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* work queues */
|
|
|
|
struct work_queue *process_main_queue;
|
2015-10-13 22:00:55 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Listening sockets */
|
|
|
|
struct list *listen_sockets;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP port number. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t port;
|
2007-11-01 15:29:11 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Listener address */
|
|
|
|
char *address;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-10-12 15:49:15 +02:00
|
|
|
/* The Mac table */
|
|
|
|
struct hash *self_mac_hash;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP start time. */
|
|
|
|
time_t start_time;
|
|
|
|
|
|
|
|
/* Various BGP global configuration. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t options;
|
2002-12-13 21:15:29 +01:00
|
|
|
#define BGP_OPT_NO_FIB (1 << 0)
|
2019-06-03 21:06:16 +02:00
|
|
|
#define BGP_OPT_NO_LISTEN (1 << 1)
|
|
|
|
#define BGP_OPT_NO_ZEBRA (1 << 2)
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
uint64_t updgrp_idspace;
|
|
|
|
uint64_t subgrp_idspace;
|
2016-03-22 18:46:30 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* timer to dampen route map changes */
|
|
|
|
struct thread *t_rmap_update; /* Handle route map updates */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t rmap_update_timer; /* Route map update timer */
|
2016-03-22 18:46:30 +01:00
|
|
|
#define RMAP_DEFAULT_UPDATE_TIMER 5 /* disabled by default */
|
2016-12-07 12:25:24 +01:00
|
|
|
|
2017-10-26 01:13:32 +02:00
|
|
|
/* Id space for automatic RD derivation for an EVI/VRF */
|
|
|
|
bitfield_t rd_idspace;
|
|
|
|
|
2018-04-07 20:13:07 +02:00
|
|
|
/* dynamic mpls label allocation pool */
|
|
|
|
struct labelpool labelpool;
|
|
|
|
|
2019-03-06 19:09:25 +01:00
|
|
|
/* BGP-EVPN VRF ID. Defaults to default VRF (if any) */
|
|
|
|
struct bgp* bgp_evpn;
|
|
|
|
|
2019-10-04 20:33:01 +02:00
|
|
|
/* How big should we set the socket buffer size */
|
|
|
|
uint32_t socket_buffer;
|
|
|
|
|
2018-05-10 14:47:11 +02:00
|
|
|
bool terminating; /* global flag that sigint terminate seen */
|
2017-07-17 14:03:14 +02:00
|
|
|
QOBJ_FIELDS
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
2016-12-07 12:25:24 +01:00
|
|
|
DECLARE_QOBJ_TYPE(bgp_master)
|
2002-12-13 21:15:29 +01:00
|
|
|
|
bgpd: bgpd-table-map.patch
COMMAND:
table-map <route-map-name>
DESCRIPTION:
This feature is used to apply a route-map on route updates from BGP to Zebra.
All the applicable match operations are allowed, such as match on prefix,
next-hop, communities, etc. Set operations for this attach-point are limited
to metric and next-hop only. Any operation of this feature does not affect
BGPs internal RIB.
Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
however, metric setting is based on the best-path only.
IMPLEMENTATION NOTES:
The route-map application at this point is not supposed to modify any of BGP
route's attributes (anything in bgp_info for that matter). To achieve that,
creating a copy of the bgp_attr was inevitable. Implementation tries to keep
the memory footprint low, code comments do point out the rationale behind a
few choices made.
bgp_zebra_announce() was already a big routine, adding this feature would
extend it further. Patch has created a few smaller routines/macros whereever
possible to keep the size of the routine in check without compromising on the
readability of the code/flow inside this routine.
For updating a partially filtered route (with its nexthops), BGP to Zebra
replacement semantic of the next-hops serves the purpose well. However, with
this patch there could be some redundant withdraws each time BGP announces a
route thats (all the nexthops) gets denied by the route-map application.
Handling of this case could be optimized by keeping state with the prefix and
the nexthops in BGP. The patch doesn't optimizing that case, as even with the
redundant withdraws the total number of updates to zebra are still be capped
by the total number of routes in the table.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
|
|
|
/* BGP route-map structure. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_rmap {
|
|
|
|
char *name;
|
|
|
|
struct route_map *map;
|
bgpd: bgpd-table-map.patch
COMMAND:
table-map <route-map-name>
DESCRIPTION:
This feature is used to apply a route-map on route updates from BGP to Zebra.
All the applicable match operations are allowed, such as match on prefix,
next-hop, communities, etc. Set operations for this attach-point are limited
to metric and next-hop only. Any operation of this feature does not affect
BGPs internal RIB.
Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
however, metric setting is based on the best-path only.
IMPLEMENTATION NOTES:
The route-map application at this point is not supposed to modify any of BGP
route's attributes (anything in bgp_info for that matter). To achieve that,
creating a copy of the bgp_attr was inevitable. Implementation tries to keep
the memory footprint low, code comments do point out the rationale behind a
few choices made.
bgp_zebra_announce() was already a big routine, adding this feature would
extend it further. Patch has created a few smaller routines/macros whereever
possible to keep the size of the routine in check without compromising on the
readability of the code/flow inside this routine.
For updating a partially filtered route (with its nexthops), BGP to Zebra
replacement semantic of the next-hops serves the purpose well. However, with
this patch there could be some redundant withdraws each time BGP announces a
route thats (all the nexthops) gets denied by the route-map application.
Handling of this case could be optimized by keeping state with the prefix and
the nexthops in BGP. The patch doesn't optimizing that case, as even with the
redundant withdraws the total number of updates to zebra are still be capped
by the total number of routes in the table.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
|
|
|
};
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_redist {
|
2018-03-27 21:13:34 +02:00
|
|
|
unsigned short instance;
|
Multi-Instance OSPF Summary
——————————————-------------
- etc/init.d/quagga is modified to support creating separate ospf daemon
process for each instance. Each individual instance is monitored by
watchquagga just like any protocol daemons.(requires initd-mi.patch).
- Vtysh is modified to able to connect to multiple daemons of the same
protocol (supported for OSPF only for now).
- ospfd is modified to remember the Instance-ID that its invoked with. For
the entire life of the process it caters to any command request that
matches that instance-ID (unless its a non instance specific command).
Routes/messages to zebra are tagged with instance-ID.
- zebra route/redistribute mechanisms are modified to work with
[protocol type + instance-id]
- bgpd now has ability to have multiple instance specific redistribution
for a protocol (OSPF only supported/tested for now).
- zlog ability to display instance-id besides the protocol/daemon name.
- Changes in other daemons are to because of the needed integration with
some of the modified APIs/routines. (Didn’t prefer replicating too many
separate instance specific APIs.)
- config/show/debug commands are modified to take instance-id argument
as appropriate.
Guidelines to start using multi-instance ospf
---------------------------------------------
The patch is backward compatible, i.e for any previous way of single ospf
deamon(router ospf <cr>) will continue to work as is, including all the
show commands etc.
To enable multiple instances, do the following:
1. service quagga stop
2. Modify /etc/quagga/daemons to add instance-ids of each desired
instance in the following format:
ospfd=“yes"
ospfd_instances="1,2,3"
assuming you want to enable 3 instances with those instance ids.
3. Create corresponding ospfd config files as ospfd-1.conf, ospfd-2.conf
and ospfd-3.conf.
4. service quagga start/restart
5. Verify that the deamons are started as expected. You should see
ospfd started with -n <instance-id> option.
ps –ef | grep quagga
With that /var/run/quagga/ should have ospfd-<instance-id>.pid and
ospfd-<instance-id>/vty to each instance.
6. vtysh to work with instances as you would with any other deamons.
7. Overall most quagga semantics are the same working with the instance
deamon, like it is for any other daemon.
NOTE:
To safeguard against errors leading to too many processes getting invoked,
a hard limit on number of instance-ids is in place, currently its 5.
Allowed instance-id range is <1-65535>
Once daemons are up, show running from vtysh should show the instance-id
of each daemon as 'router ospf <instance-id>’ (without needing explicit
configuration)
Instance-id can not be changed via vtysh, other router ospf configuration
is allowed as before.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 03:03:42 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP redistribute metric configuration. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t redist_metric_flag;
|
|
|
|
uint32_t redist_metric;
|
Multi-Instance OSPF Summary
——————————————-------------
- etc/init.d/quagga is modified to support creating separate ospf daemon
process for each instance. Each individual instance is monitored by
watchquagga just like any protocol daemons.(requires initd-mi.patch).
- Vtysh is modified to able to connect to multiple daemons of the same
protocol (supported for OSPF only for now).
- ospfd is modified to remember the Instance-ID that its invoked with. For
the entire life of the process it caters to any command request that
matches that instance-ID (unless its a non instance specific command).
Routes/messages to zebra are tagged with instance-ID.
- zebra route/redistribute mechanisms are modified to work with
[protocol type + instance-id]
- bgpd now has ability to have multiple instance specific redistribution
for a protocol (OSPF only supported/tested for now).
- zlog ability to display instance-id besides the protocol/daemon name.
- Changes in other daemons are to because of the needed integration with
some of the modified APIs/routines. (Didn’t prefer replicating too many
separate instance specific APIs.)
- config/show/debug commands are modified to take instance-id argument
as appropriate.
Guidelines to start using multi-instance ospf
---------------------------------------------
The patch is backward compatible, i.e for any previous way of single ospf
deamon(router ospf <cr>) will continue to work as is, including all the
show commands etc.
To enable multiple instances, do the following:
1. service quagga stop
2. Modify /etc/quagga/daemons to add instance-ids of each desired
instance in the following format:
ospfd=“yes"
ospfd_instances="1,2,3"
assuming you want to enable 3 instances with those instance ids.
3. Create corresponding ospfd config files as ospfd-1.conf, ospfd-2.conf
and ospfd-3.conf.
4. service quagga start/restart
5. Verify that the deamons are started as expected. You should see
ospfd started with -n <instance-id> option.
ps –ef | grep quagga
With that /var/run/quagga/ should have ospfd-<instance-id>.pid and
ospfd-<instance-id>/vty to each instance.
6. vtysh to work with instances as you would with any other deamons.
7. Overall most quagga semantics are the same working with the instance
deamon, like it is for any other daemon.
NOTE:
To safeguard against errors leading to too many processes getting invoked,
a hard limit on number of instance-ids is in place, currently its 5.
Allowed instance-id range is <1-65535>
Once daemons are up, show running from vtysh should show the instance-id
of each daemon as 'router ospf <instance-id>’ (without needing explicit
configuration)
Instance-id can not be changed via vtysh, other router ospf configuration
is allowed as before.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 03:03:42 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP redistribute route-map. */
|
|
|
|
struct bgp_rmap rmap;
|
Multi-Instance OSPF Summary
——————————————-------------
- etc/init.d/quagga is modified to support creating separate ospf daemon
process for each instance. Each individual instance is monitored by
watchquagga just like any protocol daemons.(requires initd-mi.patch).
- Vtysh is modified to able to connect to multiple daemons of the same
protocol (supported for OSPF only for now).
- ospfd is modified to remember the Instance-ID that its invoked with. For
the entire life of the process it caters to any command request that
matches that instance-ID (unless its a non instance specific command).
Routes/messages to zebra are tagged with instance-ID.
- zebra route/redistribute mechanisms are modified to work with
[protocol type + instance-id]
- bgpd now has ability to have multiple instance specific redistribution
for a protocol (OSPF only supported/tested for now).
- zlog ability to display instance-id besides the protocol/daemon name.
- Changes in other daemons are to because of the needed integration with
some of the modified APIs/routines. (Didn’t prefer replicating too many
separate instance specific APIs.)
- config/show/debug commands are modified to take instance-id argument
as appropriate.
Guidelines to start using multi-instance ospf
---------------------------------------------
The patch is backward compatible, i.e for any previous way of single ospf
deamon(router ospf <cr>) will continue to work as is, including all the
show commands etc.
To enable multiple instances, do the following:
1. service quagga stop
2. Modify /etc/quagga/daemons to add instance-ids of each desired
instance in the following format:
ospfd=“yes"
ospfd_instances="1,2,3"
assuming you want to enable 3 instances with those instance ids.
3. Create corresponding ospfd config files as ospfd-1.conf, ospfd-2.conf
and ospfd-3.conf.
4. service quagga start/restart
5. Verify that the deamons are started as expected. You should see
ospfd started with -n <instance-id> option.
ps –ef | grep quagga
With that /var/run/quagga/ should have ospfd-<instance-id>.pid and
ospfd-<instance-id>/vty to each instance.
6. vtysh to work with instances as you would with any other deamons.
7. Overall most quagga semantics are the same working with the instance
deamon, like it is for any other daemon.
NOTE:
To safeguard against errors leading to too many processes getting invoked,
a hard limit on number of instance-ids is in place, currently its 5.
Allowed instance-id range is <1-65535>
Once daemons are up, show running from vtysh should show the instance-id
of each daemon as 'router ospf <instance-id>’ (without needing explicit
configuration)
Instance-id can not be changed via vtysh, other router ospf configuration
is allowed as before.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 03:03:42 +02:00
|
|
|
};
|
|
|
|
|
2018-03-09 21:52:55 +01:00
|
|
|
typedef enum {
|
|
|
|
BGP_VPN_POLICY_DIR_FROMVPN = 0,
|
|
|
|
BGP_VPN_POLICY_DIR_TOVPN = 1,
|
|
|
|
BGP_VPN_POLICY_DIR_MAX = 2
|
|
|
|
} vpn_policy_direction_t;
|
|
|
|
|
2018-04-07 20:32:52 +02:00
|
|
|
struct vpn_policy {
|
|
|
|
struct bgp *bgp; /* parent */
|
|
|
|
afi_t afi;
|
|
|
|
struct ecommunity *rtlist[BGP_VPN_POLICY_DIR_MAX];
|
|
|
|
struct ecommunity *import_redirect_rtlist;
|
|
|
|
char *rmap_name[BGP_VPN_POLICY_DIR_MAX];
|
|
|
|
struct route_map *rmap[BGP_VPN_POLICY_DIR_MAX];
|
|
|
|
|
|
|
|
/* should be mpls_label_t? */
|
|
|
|
uint32_t tovpn_label; /* may be MPLS_LABEL_NONE */
|
|
|
|
uint32_t tovpn_zebra_vrf_label_last_sent;
|
|
|
|
struct prefix_rd tovpn_rd;
|
|
|
|
struct prefix tovpn_nexthop; /* unset => set to 0 */
|
|
|
|
uint32_t flags;
|
|
|
|
#define BGP_VPN_POLICY_TOVPN_LABEL_AUTO (1 << 0)
|
|
|
|
#define BGP_VPN_POLICY_TOVPN_RD_SET (1 << 1)
|
|
|
|
#define BGP_VPN_POLICY_TOVPN_NEXTHOP_SET (1 << 2)
|
2018-03-19 20:41:17 +01:00
|
|
|
|
2018-04-17 14:21:03 +02:00
|
|
|
/*
|
|
|
|
* If we are importing another vrf into us keep a list of
|
|
|
|
* vrf names that are being imported into us.
|
|
|
|
*/
|
2018-03-19 20:41:17 +01:00
|
|
|
struct list *import_vrf;
|
2018-04-17 14:21:03 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* if we are being exported to another vrf keep a list of
|
|
|
|
* vrf names that we are being exported to.
|
|
|
|
*/
|
2018-03-19 20:41:17 +01:00
|
|
|
struct list *export_vrf;
|
2018-04-07 20:32:52 +02:00
|
|
|
};
|
|
|
|
|
2016-02-12 21:18:28 +01:00
|
|
|
/*
|
|
|
|
* Type of 'struct bgp'.
|
|
|
|
* - Default: The default instance
|
|
|
|
* - VRF: A specific (non-default) VRF
|
|
|
|
* - View: An instance used for route exchange
|
|
|
|
* The "default" instance is treated separately to simplify the code. Note
|
|
|
|
* that if deployed in a Multi-VRF environment, it may not exist.
|
|
|
|
*/
|
2017-07-17 14:03:14 +02:00
|
|
|
enum bgp_instance_type {
|
|
|
|
BGP_INSTANCE_TYPE_DEFAULT,
|
|
|
|
BGP_INSTANCE_TYPE_VRF,
|
|
|
|
BGP_INSTANCE_TYPE_VIEW
|
2016-02-12 21:18:28 +01:00
|
|
|
};
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP instance structure. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp {
|
|
|
|
/* AS number of this BGP instance. */
|
|
|
|
as_t as;
|
|
|
|
|
|
|
|
/* Name of this BGP instance. */
|
|
|
|
char *name;
|
2018-03-28 19:11:56 +02:00
|
|
|
char *name_pretty; /* printable "VRF|VIEW name|default" */
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Type of instance and VRF id. */
|
|
|
|
enum bgp_instance_type inst_type;
|
|
|
|
vrf_id_t vrf_id;
|
|
|
|
|
|
|
|
/* Reference count to allow peer_delete to finish after bgp_delete */
|
|
|
|
int lock;
|
|
|
|
|
|
|
|
/* Self peer. */
|
|
|
|
struct peer *peer_self;
|
|
|
|
|
|
|
|
/* BGP peer. */
|
|
|
|
struct list *peer;
|
|
|
|
struct hash *peerhash;
|
|
|
|
|
|
|
|
/* BGP peer group. */
|
|
|
|
struct list *group;
|
|
|
|
|
|
|
|
/* The maximum number of BGP dynamic neighbors that can be created */
|
|
|
|
int dynamic_neighbors_limit;
|
|
|
|
|
|
|
|
/* The current number of BGP dynamic neighbors */
|
|
|
|
int dynamic_neighbors_count;
|
|
|
|
|
|
|
|
struct hash *update_groups[BGP_AF_MAX];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Global statistics for update groups.
|
|
|
|
*/
|
|
|
|
struct {
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t join_events;
|
|
|
|
uint32_t prune_events;
|
|
|
|
uint32_t merge_events;
|
|
|
|
uint32_t split_events;
|
|
|
|
uint32_t updgrp_switch_events;
|
|
|
|
uint32_t peer_refreshes_combined;
|
|
|
|
uint32_t adj_count;
|
|
|
|
uint32_t merge_checks_triggered;
|
|
|
|
|
|
|
|
uint32_t updgrps_created;
|
|
|
|
uint32_t updgrps_deleted;
|
|
|
|
uint32_t subgrps_created;
|
|
|
|
uint32_t subgrps_deleted;
|
2017-07-17 14:03:14 +02:00
|
|
|
} update_group_stats;
|
|
|
|
|
|
|
|
/* BGP configuration. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t config;
|
2015-11-17 22:57:56 +01:00
|
|
|
#define BGP_CONFIG_CLUSTER_ID (1 << 0)
|
|
|
|
#define BGP_CONFIG_CONFEDERATION (1 << 1)
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP router identifier. */
|
|
|
|
struct in_addr router_id;
|
|
|
|
struct in_addr router_id_static;
|
|
|
|
struct in_addr router_id_zebra;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP route reflector cluster ID. */
|
|
|
|
struct in_addr cluster_id;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP confederation information. */
|
|
|
|
as_t confed_id;
|
|
|
|
as_t *confed_peers;
|
|
|
|
int confed_peers_cnt;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct thread
|
|
|
|
*t_startup; /* start-up timer on only once at the beginning */
|
2015-05-20 02:40:42 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t v_maxmed_onstartup; /* Duration of max-med on start-up */
|
2015-05-20 02:40:42 +02:00
|
|
|
#define BGP_MAXMED_ONSTARTUP_UNCONFIGURED 0 /* 0 means off, its the default */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t maxmed_onstartup_value; /* Max-med value when active on
|
|
|
|
start-up */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct thread
|
|
|
|
*t_maxmed_onstartup; /* non-null when max-med onstartup is on */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t maxmed_onstartup_over; /* Flag to make it effective only once */
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t v_maxmed_admin; /* 1/0 if max-med administrative is on/off */
|
2015-05-20 02:40:42 +02:00
|
|
|
#define BGP_MAXMED_ADMIN_UNCONFIGURED 0 /* Off by default */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t maxmed_admin_value; /* Max-med value when administrative in on
|
|
|
|
*/
|
2015-05-20 02:40:42 +02:00
|
|
|
#define BGP_MAXMED_VALUE_DEFAULT 4294967294 /* Maximum by default */
|
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t maxmed_active; /* 1/0 if max-med is active or not */
|
|
|
|
uint32_t maxmed_value; /* Max-med value when its active */
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* BGP update delay on startup */
|
|
|
|
struct thread *t_update_delay;
|
|
|
|
struct thread *t_establish_wait;
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t update_delay_over;
|
|
|
|
uint8_t main_zebra_update_hold;
|
|
|
|
uint8_t main_peers_update_hold;
|
|
|
|
uint16_t v_update_delay;
|
|
|
|
uint16_t v_establish_wait;
|
2017-07-17 14:03:14 +02:00
|
|
|
char update_delay_begin_time[64];
|
|
|
|
char update_delay_end_time[64];
|
|
|
|
char update_delay_zebra_resume_time[64];
|
|
|
|
char update_delay_peers_resume_time[64];
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t established;
|
|
|
|
uint32_t restarted_peers;
|
|
|
|
uint32_t implicit_eors;
|
|
|
|
uint32_t explicit_eors;
|
bgpd: bgpd-update-delay.patch
COMMAND:
'update-delay <max-delay in seconds> [<establish-wait in seconds>]'
DESCRIPTION:
This feature is used to enable read-only mode on BGP process restart or when
BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode
would begin as soon as the first peer reaches Established state and a timer
for <max-delay> seconds is started.
During this mode BGP doesn't run any best-path or generate any updates to its
peers. This mode continues until:
1. All the configured peers, except the shutdown peers, have sent explicit EOR
(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR.
If the <establish-wait> optional value is given, then BGP will wait for
peers to reach establish from the begining of the update-delay till the
establish-wait period is over, i.e. the minimum set of established peers for
which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors.
2. max-delay period is over.
On hitting any of the above two conditions, BGP resumes the decision process
and generates updates to its peers.
Default <max-delay> is 0, i.e. the feature is off by default.
This feature can be useful in reducing CPU/network used as BGP restarts/clears.
Particularly useful in the topologies where BGP learns a prefix from many peers.
Intermediate bestpaths are possible for the same prefix as peers get established
and start receiving updates at different times. This feature should offer a
value-add if the network has a high number of such prefixes.
IMPLEMENTATION OBJECTIVES:
Given this is an optional feature, minimized the code-churn. Used existing
constructs wherever possible (existing queue-plug/unplug were used to achieve
delay and resume of best-paths/update-generation). As a result, no new
data-structure(s) had to be defined and allocated. When the feature is disabled,
the new node is not exercised for the most part.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:33 +02:00
|
|
|
#define BGP_UPDATE_DELAY_DEF 0
|
|
|
|
#define BGP_UPDATE_DELAY_MIN 0
|
|
|
|
#define BGP_UPDATE_DELAY_MAX 3600
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP flags. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t flags;
|
2002-12-13 21:15:29 +01:00
|
|
|
#define BGP_FLAG_ALWAYS_COMPARE_MED (1 << 0)
|
|
|
|
#define BGP_FLAG_DETERMINISTIC_MED (1 << 1)
|
|
|
|
#define BGP_FLAG_MED_MISSING_AS_WORST (1 << 2)
|
|
|
|
#define BGP_FLAG_MED_CONFED (1 << 3)
|
|
|
|
#define BGP_FLAG_NO_DEFAULT_IPV4 (1 << 4)
|
|
|
|
#define BGP_FLAG_NO_CLIENT_TO_CLIENT (1 << 5)
|
|
|
|
#define BGP_FLAG_COMPARE_ROUTER_ID (1 << 7)
|
|
|
|
#define BGP_FLAG_ASPATH_IGNORE (1 << 8)
|
|
|
|
#define BGP_FLAG_IMPORT_CHECK (1 << 9)
|
|
|
|
#define BGP_FLAG_NO_FAST_EXT_FAILOVER (1 << 10)
|
2003-08-13 02:32:49 +02:00
|
|
|
#define BGP_FLAG_LOG_NEIGHBOR_CHANGES (1 << 11)
|
2004-05-21 11:31:30 +02:00
|
|
|
#define BGP_FLAG_GRACEFUL_RESTART (1 << 12)
|
2005-04-08 17:40:36 +02:00
|
|
|
#define BGP_FLAG_ASPATH_CONFED (1 << 13)
|
2013-09-07 09:02:36 +02:00
|
|
|
#define BGP_FLAG_ASPATH_MULTIPATH_RELAX (1 << 14)
|
2015-05-20 02:40:41 +02:00
|
|
|
#define BGP_FLAG_RR_ALLOW_OUTBOUND_POLICY (1 << 15)
|
2015-05-20 03:03:49 +02:00
|
|
|
#define BGP_FLAG_DISABLE_NH_CONNECTED_CHK (1 << 16)
|
2015-11-10 16:33:24 +01:00
|
|
|
#define BGP_FLAG_MULTIPATH_RELAX_AS_SET (1 << 17)
|
2015-05-20 03:04:20 +02:00
|
|
|
#define BGP_FLAG_FORCE_STATIC_PROCESS (1 << 18)
|
2015-10-20 23:57:09 +02:00
|
|
|
#define BGP_FLAG_SHOW_HOSTNAME (1 << 19)
|
2016-05-20 12:10:07 +02:00
|
|
|
#define BGP_FLAG_GR_PRESERVE_FWD (1 << 20)
|
2017-08-25 20:27:49 +02:00
|
|
|
#define BGP_FLAG_GRACEFUL_SHUTDOWN (1 << 21)
|
2019-06-11 15:20:09 +02:00
|
|
|
#define BGP_FLAG_DELETE_IN_PROGRESS (1 << 22)
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP Per AF flags */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t af_flags[AFI_MAX][SAFI_MAX];
|
2018-03-26 10:55:28 +02:00
|
|
|
#define BGP_CONFIG_DAMPENING (1 << 0)
|
2018-02-27 11:19:57 +01:00
|
|
|
/* l2vpn evpn flags - 1 << 0 is used for DAMPENNG */
|
2018-03-26 10:55:28 +02:00
|
|
|
#define BGP_L2VPN_EVPN_ADVERTISE_IPV4_UNICAST (1 << 1)
|
|
|
|
#define BGP_L2VPN_EVPN_ADVERTISE_IPV6_UNICAST (1 << 2)
|
|
|
|
#define BGP_L2VPN_EVPN_DEFAULT_ORIGINATE_IPV4 (1 << 3)
|
|
|
|
#define BGP_L2VPN_EVPN_DEFAULT_ORIGINATE_IPV6 (1 << 4)
|
|
|
|
/* import/export between address families */
|
|
|
|
#define BGP_CONFIG_VRF_TO_MPLSVPN_EXPORT (1 << 5)
|
|
|
|
#define BGP_CONFIG_MPLSVPN_TO_VRF_IMPORT (1 << 6)
|
|
|
|
/* vrf-route leaking flags */
|
|
|
|
#define BGP_CONFIG_VRF_TO_VRF_IMPORT (1 << 7)
|
|
|
|
#define BGP_CONFIG_VRF_TO_VRF_EXPORT (1 << 8)
|
2018-02-20 09:46:22 +01:00
|
|
|
|
bgpd: Incorrect number of peers count in "show bgp ipv6 summary output
The "show bgp ipv6 summary" output displays incorrect number of peers count.
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 5, using 103 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
In the above output, the peers count displays as 5 but the actual peer count is 3, i.e.. 3 neighbors are activated in ipv6 unicast address family.
Displayed peer count (5) is the number of the neighbors activated in a BGP instance.
Fix : Now the peers count displays the number of neighbors activated per afi/safi.
After Fix:
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 3, using 62 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
2019-03-07 08:47:25 +01:00
|
|
|
/* BGP per AF peer count */
|
|
|
|
uint32_t af_peer_count[AFI_MAX][SAFI_MAX];
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Route table for next-hop lookup cache. */
|
|
|
|
struct bgp_table *nexthop_cache_table[AFI_MAX];
|
2016-02-02 13:36:20 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Route table for import-check */
|
|
|
|
struct bgp_table *import_check_table[AFI_MAX];
|
2016-02-02 13:36:20 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_table *connected_table[AFI_MAX];
|
2016-02-02 13:36:20 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct hash *address_hash;
|
2016-02-02 13:36:20 +01:00
|
|
|
|
2017-08-17 08:19:58 +02:00
|
|
|
/* DB for all local tunnel-ips - used mainly for martian checks
|
|
|
|
Currently it only has all VxLan tunnel IPs*/
|
|
|
|
struct hash *tip_hash;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Static route configuration. */
|
|
|
|
struct bgp_table *route[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Aggregate address configuration. */
|
|
|
|
struct bgp_table *aggregate[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP routing information base. */
|
|
|
|
struct bgp_table *rib[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP table route-map. */
|
|
|
|
struct bgp_rmap table_map[AFI_MAX][SAFI_MAX];
|
bgpd: bgpd-table-map.patch
COMMAND:
table-map <route-map-name>
DESCRIPTION:
This feature is used to apply a route-map on route updates from BGP to Zebra.
All the applicable match operations are allowed, such as match on prefix,
next-hop, communities, etc. Set operations for this attach-point are limited
to metric and next-hop only. Any operation of this feature does not affect
BGPs internal RIB.
Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
however, metric setting is based on the best-path only.
IMPLEMENTATION NOTES:
The route-map application at this point is not supposed to modify any of BGP
route's attributes (anything in bgp_info for that matter). To achieve that,
creating a copy of the bgp_attr was inevitable. Implementation tries to keep
the memory footprint low, code comments do point out the rationale behind a
few choices made.
bgp_zebra_announce() was already a big routine, adding this feature would
extend it further. Patch has created a few smaller routines/macros whereever
possible to keep the size of the routine in check without compromising on the
readability of the code/flow inside this routine.
For updating a partially filtered route (with its nexthops), BGP to Zebra
replacement semantic of the next-hops serves the purpose well. However, with
this patch there could be some redundant withdraws each time BGP announces a
route thats (all the nexthops) gets denied by the route-map application.
Handling of this case could be optimized by keeping state with the prefix and
the nexthops in BGP. The patch doesn't optimizing that case, as even with the
redundant withdraws the total number of updates to zebra are still be capped
by the total number of routes in the table.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP redistribute configuration. */
|
|
|
|
struct list *redist[AFI_MAX][ZEBRA_ROUTE_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-08-22 20:14:50 +02:00
|
|
|
/* Allocate MPLS labels */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t allocate_mpls_labels[AFI_MAX][SAFI_MAX];
|
2017-08-22 20:14:50 +02:00
|
|
|
|
2018-03-08 17:23:02 +01:00
|
|
|
/* Allocate hash entries to store policy routing information
|
|
|
|
* The hash are used to host pbr rules somewhere.
|
|
|
|
* Actually, pbr will only be used by flowspec
|
|
|
|
* those hash elements will have relationship together as
|
|
|
|
* illustrated in below diagram:
|
|
|
|
*
|
|
|
|
* pbr_action a <----- pbr_match i <--- pbr_match_entry 1..n
|
|
|
|
* <----- pbr_match j <--- pbr_match_entry 1..m
|
2018-11-29 15:12:03 +01:00
|
|
|
* <----- pbr_rule k
|
2018-03-08 17:23:02 +01:00
|
|
|
*
|
|
|
|
* - here in BGP structure, the list of match and actions will
|
|
|
|
* stand for the list of ipset sets, and table_ids in the kernel
|
|
|
|
* - the arrow above between pbr_match and pbr_action indicate
|
|
|
|
* that a backpointer permits match to find the action
|
|
|
|
* - the arrow betwen match_entry and match is a hash list
|
|
|
|
* contained in match, that lists the whole set of entries
|
|
|
|
*/
|
|
|
|
struct hash *pbr_match_hash;
|
2018-11-29 15:12:03 +01:00
|
|
|
struct hash *pbr_rule_hash;
|
2018-03-08 17:23:02 +01:00
|
|
|
struct hash *pbr_action_hash;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* timer to re-evaluate neighbor default-originate route-maps */
|
|
|
|
struct thread *t_rmap_def_originate_eval;
|
2015-05-20 03:04:20 +02:00
|
|
|
#define RMAP_DEFAULT_ORIGINATE_EVAL_TIMER 5
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP distance configuration. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t distance_ebgp[AFI_MAX][SAFI_MAX];
|
|
|
|
uint8_t distance_ibgp[AFI_MAX][SAFI_MAX];
|
|
|
|
uint8_t distance_local[AFI_MAX][SAFI_MAX];
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* BGP default local-preference. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t default_local_pref;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* BGP default subgroup pkt queue max */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t default_subgroup_pkt_queue_max;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* BGP default timer. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t default_holdtime;
|
|
|
|
uint32_t default_keepalive;
|
2019-08-01 18:50:56 +02:00
|
|
|
uint32_t default_connect_retry;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* BGP graceful restart */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t restart_time;
|
|
|
|
uint32_t stalepath_time;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Maximum-paths configuration */
|
|
|
|
struct bgp_maxpaths_cfg {
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t maxpaths_ebgp;
|
|
|
|
uint16_t maxpaths_ibgp;
|
|
|
|
uint16_t ibgp_flags;
|
2015-05-20 02:40:31 +02:00
|
|
|
#define BGP_FLAG_IBGP_MULTIPATH_SAME_CLUSTERLEN (1 << 0)
|
2017-07-17 14:03:14 +02:00
|
|
|
} maxpaths[AFI_MAX][SAFI_MAX];
|
bgpd: bgpd-mrai.patch
BGP: Event-driven route announcement taking into account min route advertisement interval
ISSUE
BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec
when a peer is established. From then on, the timer expires
periodically based on the configured MRAI value (default: 30sec for
EBGP, 5sec for IBGP). At the expiry, the write thread is triggered
that takes the routes from peer's sync FIFO (adj-rib-out) and sends
UPDATEs. This has a few drawbacks:
(1) Delay in new route announcement: Even when the last UPDATE message
was sent a while back, the next route change will necessarily have
to wait for routeadv expiry
(2) CPU usage: The timer is always armed. If the operator chooses to
configure a lower value of MRAI (zero second is a preferred choice
in many deployments) for better convergence, it leads to high CPU
usage for BGP process, even at the times of no network churn.
PATCH
Make the route advertisement event-driven - When routes are added to
peer's sync FIFO, check if the routeadv timer needs to be adjusted (or
started). Conversely, do not arm the routeadv timer unconditionally.
The patch also addresses route announcements during read-only mode
(update-delay). During read-only mode operation, the routeadv timer
is not started. When BGP comes out of read-only mode and all the
routes are processed, the timer is started for all peers with zero
expiry, so that the UPDATEs can be sent all at once. This leads to
(near-)optimal UPDATE packing.
Finally, the patch makes the "max # packets to write to peer socket at
a time" configurable. Currently it is hard-coded to 10. The command is
at the top router-bgp mode and is called "write-quanta <number>". It
is a useful convergence parameter to tweak.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
2015-05-20 02:40:37 +02:00
|
|
|
|
2017-06-05 22:14:47 +02:00
|
|
|
_Atomic uint32_t wpkt_quanta; // max # packets to write per i/o cycle
|
|
|
|
_Atomic uint32_t rpkt_quanta; // max # packets to read per i/o cycle
|
|
|
|
|
2017-12-14 22:43:31 +01:00
|
|
|
/* Automatic coalesce adjust on/off */
|
|
|
|
bool heuristic_coalesce;
|
2017-12-06 23:35:21 +01:00
|
|
|
/* Actual coalesce time */
|
|
|
|
uint32_t coalesce_time;
|
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
|
|
|
|
2018-01-11 18:50:08 +01:00
|
|
|
/* Auto-shutdown new peers */
|
|
|
|
bool autoshutdown;
|
|
|
|
|
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 bgp_addpath_bgp_data tx_addpath;
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
|
|
|
|
#if ENABLE_BGP_VNC
|
2017-07-17 14:03:14 +02:00
|
|
|
struct rfapi_cfg *rfapi_cfg;
|
|
|
|
struct rfapi *rfapi;
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
#endif
|
2016-12-07 12:25:24 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* EVPN related information */
|
2017-05-15 23:27:51 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* EVI hash table */
|
|
|
|
struct hash *vnihash;
|
2017-05-15 23:27:51 +02:00
|
|
|
|
2017-06-28 10:51:10 +02:00
|
|
|
/* EVPN enable - advertise gateway macip routes */
|
|
|
|
int advertise_gw_macip;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* EVPN enable - advertise local VNIs and their MACs etc. */
|
|
|
|
int advertise_all_vni;
|
2017-05-15 23:27:51 +02:00
|
|
|
|
2019-02-07 09:49:04 +01:00
|
|
|
/* RFC 8212 - prevent route leaks. */
|
|
|
|
int ebgp_requires_policy;
|
|
|
|
#define DEFAULT_EBGP_POLICY_DISABLED 0
|
|
|
|
#define DEFAULT_EBGP_POLICY_ENABLED 1
|
|
|
|
|
2019-11-09 19:24:34 +01:00
|
|
|
/* draft-ietf-idr-deprecate-as-set-confed-set
|
|
|
|
* Reject aspaths with AS_SET and/or AS_CONFED_SET.
|
|
|
|
*/
|
|
|
|
bool reject_as_sets;
|
|
|
|
#define BGP_REJECT_AS_SETS_DISABLED 0
|
|
|
|
#define BGP_REJECT_AS_SETS_ENABLED 1
|
|
|
|
|
2018-11-01 00:53:28 +01:00
|
|
|
struct bgp_evpn_info *evpn_info;
|
|
|
|
|
2017-04-12 11:24:07 +02:00
|
|
|
/* EVPN - use RFC 8365 to auto-derive RT */
|
|
|
|
int advertise_autort_rfc8365;
|
|
|
|
|
2018-10-05 01:20:12 +02:00
|
|
|
/*
|
|
|
|
* Flooding mechanism for BUM packets for VxLAN-EVPN.
|
|
|
|
*/
|
|
|
|
enum vxlan_flood_control vxlan_flood_ctrl;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Hash table of Import RTs to EVIs */
|
|
|
|
struct hash *import_rt_hash;
|
2017-05-15 23:27:51 +02:00
|
|
|
|
2017-10-10 03:12:05 +02:00
|
|
|
/* Hash table of VRF import RTs to VRFs */
|
|
|
|
struct hash *vrf_import_rt_hash;
|
|
|
|
|
2017-10-09 02:46:08 +02:00
|
|
|
/* L3-VNI corresponding to this vrf */
|
|
|
|
vni_t l3vni;
|
|
|
|
|
|
|
|
/* router-mac to be used in mac-ip routes for this vrf */
|
|
|
|
struct ethaddr rmac;
|
|
|
|
|
2017-10-31 00:58:15 +01:00
|
|
|
/* originator ip - to be used as NH for type-5 routes */
|
|
|
|
struct in_addr originator_ip;
|
|
|
|
|
2019-02-27 12:52:34 +01:00
|
|
|
/* SVI associated with the L3-VNI corresponding to this vrf */
|
|
|
|
ifindex_t l3vni_svi_ifindex;
|
|
|
|
|
2017-10-09 02:46:08 +02:00
|
|
|
/* vrf flags */
|
|
|
|
uint32_t vrf_flags;
|
2017-10-26 01:49:18 +02:00
|
|
|
#define BGP_VRF_AUTO (1 << 0)
|
2018-02-20 09:46:22 +01:00
|
|
|
#define BGP_VRF_IMPORT_RT_CFGD (1 << 1)
|
|
|
|
#define BGP_VRF_EXPORT_RT_CFGD (1 << 2)
|
|
|
|
#define BGP_VRF_RD_CFGD (1 << 3)
|
2018-02-27 10:46:26 +01:00
|
|
|
#define BGP_VRF_L3VNI_PREFIX_ROUTES_ONLY (1 << 4)
|
|
|
|
|
2017-10-26 01:49:18 +02:00
|
|
|
|
|
|
|
/* unique ID for auto derivation of RD for this vrf */
|
|
|
|
uint16_t vrf_rd_id;
|
|
|
|
|
2018-03-27 02:11:39 +02:00
|
|
|
/* Automatically derived RD for this VRF */
|
|
|
|
struct prefix_rd vrf_prd_auto;
|
|
|
|
|
2017-10-26 01:49:18 +02:00
|
|
|
/* RD for this VRF */
|
|
|
|
struct prefix_rd vrf_prd;
|
2017-10-09 03:34:29 +02:00
|
|
|
|
|
|
|
/* import rt list for the vrf instance */
|
|
|
|
struct list *vrf_import_rtl;
|
|
|
|
|
|
|
|
/* export rt list for the vrf instance */
|
|
|
|
struct list *vrf_export_rtl;
|
2017-10-09 02:46:08 +02:00
|
|
|
|
2017-10-09 05:43:14 +02:00
|
|
|
/* list of corresponding l2vnis (struct bgpevpn) */
|
|
|
|
struct list *l2vnis;
|
|
|
|
|
2018-02-09 10:09:20 +01:00
|
|
|
/* route map for advertise ipv4/ipv6 unicast (type-5 routes) */
|
|
|
|
struct bgp_rmap adv_cmd_rmap[AFI_MAX][SAFI_MAX];
|
|
|
|
|
2018-04-07 20:32:52 +02:00
|
|
|
struct vpn_policy vpn_policy[AFI_MAX];
|
2018-03-09 21:52:55 +01:00
|
|
|
|
2018-04-25 18:29:35 +02:00
|
|
|
struct bgp_pbr_config *bgp_pbr_cfg;
|
|
|
|
|
2018-04-14 00:01:12 +02:00
|
|
|
/* local esi hash table */
|
|
|
|
struct hash *esihash;
|
|
|
|
|
2018-11-19 13:35:32 +01:00
|
|
|
/* Count of peers in established state */
|
|
|
|
uint32_t established_peers;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
QOBJ_FIELDS
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
2016-12-07 12:25:24 +01:00
|
|
|
DECLARE_QOBJ_TYPE(bgp)
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-05-10 15:31:04 +02:00
|
|
|
DECLARE_HOOK(bgp_inst_delete, (struct bgp *bgp), (bgp))
|
|
|
|
DECLARE_HOOK(bgp_inst_config_write,
|
|
|
|
(struct bgp *bgp, struct vty *vty),
|
|
|
|
(bgp, vty))
|
|
|
|
|
2015-11-10 16:29:12 +01:00
|
|
|
#define BGP_ROUTE_ADV_HOLD(bgp) (bgp->main_peers_update_hold)
|
2015-05-20 02:58:12 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
#define IS_BGP_INST_KNOWN_TO_ZEBRA(bgp) \
|
|
|
|
(bgp->inst_type == BGP_INSTANCE_TYPE_DEFAULT \
|
|
|
|
|| (bgp->inst_type == BGP_INSTANCE_TYPE_VRF \
|
|
|
|
&& bgp->vrf_id != VRF_UNKNOWN))
|
2016-02-12 21:18:28 +01:00
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP peer-group support. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct peer_group {
|
|
|
|
/* Name of the peer-group. */
|
|
|
|
char *name;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Pointer to BGP. */
|
|
|
|
struct bgp *bgp;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Peer-group client list. */
|
|
|
|
struct list *peer;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/** Dynamic neighbor listening ranges */
|
|
|
|
struct list *listen_range[AFI_MAX];
|
|
|
|
|
|
|
|
/* Peer-group config */
|
|
|
|
struct peer *conf;
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* BGP Notify message format. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_notify {
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t code;
|
|
|
|
uint8_t subcode;
|
2017-07-17 14:03:14 +02:00
|
|
|
char *data;
|
|
|
|
bgp_size_t length;
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t *raw_data;
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Next hop self address. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_nexthop {
|
|
|
|
struct interface *ifp;
|
|
|
|
struct in_addr v4;
|
|
|
|
struct in6_addr v6_global;
|
|
|
|
struct in6_addr v6_local;
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
2015-05-20 03:03:45 +02:00
|
|
|
/* BGP addpath values */
|
|
|
|
#define BGP_ADDPATH_RX 1
|
|
|
|
#define BGP_ADDPATH_TX 2
|
|
|
|
#define BGP_ADDPATH_ID_LEN 4
|
|
|
|
|
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
|
|
|
#define BGP_ADDPATH_TX_ID_FOR_DEFAULT_ORIGINATE 1
|
|
|
|
|
2018-07-07 22:34:25 +02:00
|
|
|
/* Route map direction */
|
2015-11-10 16:29:12 +01:00
|
|
|
#define RMAP_IN 0
|
|
|
|
#define RMAP_OUT 1
|
|
|
|
#define RMAP_MAX 2
|
2004-09-13 Jose Luis Rubio <jrubio@dit.upm.es>
(at Technical University of Madrid as part of Euro6ix Project)
Enhanced Route Server functionality and Route-Maps:
* bgpd/bgpd.h: Modified 'struct peer' and 'struct bgp_filter' to
support rs-clients. A 'struct bgp_table *rib' has been added to the
first (to mantain a separated RIB for each rs-client) and two new
route-maps have been added to the last (for import/export policies).
Added the following #defines: RMAP_{IN|OUT|IMPORT|EXPORT|MAX},
PEER_RMAP_TYPE_{IMPORT|EXPORT} and BGP_CLEAR_SOFT_RSCLIENT.
* bgpd/bgpd.c: Modified the functions that create/delete/etc peers in
order to consider the new fields included in 'struct peer' for
supporting rs-clients, i.e. the import/export route-maps and the
'struct bgp_table'.
* bgpd/bgp_route.{ch}: Modified several functions related with
receiving/sending announces in order to support the new Route Server
capabilities.
Function 'bgp_process' has been reorganized, creating an auxiliar
function for best path selection ('bgp_best_selection').
Modified 'bgp_show' and 'bgp_show_route' for displaying information
about any RIB (and not only the main bgp RIB).
Added commands for displaying information about RS-clients RIBs:
'show bgp rsclient (A.B.C.D|X:X::X:X)', 'show bgp rsclient
(A.B.C.D|X:X::X:X) X:X::X:X/M', etc
* bgpd/bgp_table.{ch}: The structure 'struct bgp_table' now has two
new fields: type (which can take the values BGP_TABLE_{MAIN|RSCLIENT})
and 'void *owner' which points to 'struct bgp' or 'struct peer' which
owns the table.
When creating a new bgp_table by default 'type=BGP_TABLE_MAIN' is set.
* bgpd/bgp_vty.c: The commands 'neighbor ... route-server-client' and
'no neighbor ... route-server-client' now not only set/unset the flag
PEER_FLAG_RSERVER_CLIENT, but they create/destroy the 'struct
bgp_table' of the peer. Special actions are taken for peer_groups.
Command 'neighbor ... route-map WORD (in|out)' now also supports two
new kinds of route-map: 'import' and 'export'.
Added commands 'clear bgp * rsclient', etc. These commands allow a new
kind of soft_reconfig which affects only the RIB of the specified
RS-client.
Added commands 'show bgp rsclient summary', etc which display a
summary of the rs-clients configured for the corresponding address
family.
* bgpd/bgp_routemap.c: A new match statement is available,
'match peer (A.B.C.D|X:X::X:X)'. This statement can only be used in
import/export route-maps, and it matches when the peer who announces
(when used in an import route-map) or is going to receive (when used
in an export route-map) the route is the same than the one specified
in the statement.
For peer-groups the statement matches if the specified peer is member
of the peer-group.
A special version of the command, 'match peer local', matches with
routes originated by the Route Server (defined with 'network ...',
redistributed routes and default-originate).
* lib/routemap.{ch}: Added a new clause 'call NAME' for use in
route-maps. It jumps into the specified route-map and when it returns
the first route-map ends if the called RM returns DENY_MATCH, or
continues in other case.
2004-09-13 07:12:46 +02:00
|
|
|
|
2019-10-23 16:56:23 +02:00
|
|
|
#define BGP_DEFAULT_TTL 1
|
|
|
|
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
#include "filter.h"
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP filter structure. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_filter {
|
|
|
|
/* Distribute-list. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct access_list *alist;
|
|
|
|
} dlist[FILTER_MAX];
|
|
|
|
|
|
|
|
/* Prefix-list. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct prefix_list *plist;
|
|
|
|
} plist[FILTER_MAX];
|
|
|
|
|
|
|
|
/* Filter-list. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct as_list *aslist;
|
|
|
|
} aslist[FILTER_MAX];
|
|
|
|
|
|
|
|
/* Route-map. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct route_map *map;
|
|
|
|
} map[RMAP_MAX];
|
|
|
|
|
|
|
|
/* Unsuppress-map. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct route_map *map;
|
|
|
|
} usmap;
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
2012-05-07 18:52:54 +02:00
|
|
|
/* IBGP/EBGP identifier. We also have a CONFED peer, which is to say,
|
|
|
|
a peer who's AS is part of our Confederation. */
|
2017-07-17 14:03:14 +02:00
|
|
|
typedef enum {
|
2018-12-27 17:03:38 +01:00
|
|
|
BGP_PEER_UNSPECIFIED,
|
|
|
|
BGP_PEER_IBGP,
|
2017-07-17 14:03:14 +02:00
|
|
|
BGP_PEER_EBGP,
|
|
|
|
BGP_PEER_INTERNAL,
|
|
|
|
BGP_PEER_CONFED,
|
2012-05-07 18:52:54 +02:00
|
|
|
} bgp_peer_sort_t;
|
|
|
|
|
2015-05-20 02:40:39 +02:00
|
|
|
/* BGP message header and packet size. */
|
|
|
|
#define BGP_MARKER_SIZE 16
|
|
|
|
#define BGP_HEADER_SIZE 19
|
|
|
|
#define BGP_MAX_PACKET_SIZE 4096
|
2015-05-20 02:58:10 +02:00
|
|
|
#define BGP_MAX_PACKET_SIZE_OVERFLOW 1024
|
2015-05-20 02:40:39 +02:00
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
/*
|
|
|
|
* Trigger delay for bgp_announce_route().
|
|
|
|
*/
|
|
|
|
#define BGP_ANNOUNCE_ROUTE_SHORT_DELAY_MS 100
|
|
|
|
#define BGP_ANNOUNCE_ROUTE_DELAY_MS 500
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct peer_af {
|
|
|
|
/* back pointer to the peer */
|
|
|
|
struct peer *peer;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* which subgroup the peer_af belongs to */
|
|
|
|
struct update_subgroup *subgroup;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* for being part of an update subgroup's peer list */
|
|
|
|
LIST_ENTRY(peer_af) subgrp_train;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* for being part of a packet's peer list */
|
|
|
|
LIST_ENTRY(peer_af) pkt_train;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bpacket *next_pkt_to_send;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/*
|
|
|
|
* Trigger timer for bgp_announce_route().
|
|
|
|
*/
|
|
|
|
struct thread *t_announce_route;
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
afi_t afi;
|
|
|
|
safi_t safi;
|
|
|
|
int afid;
|
2015-05-20 03:03:47 +02:00
|
|
|
};
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP neighbor structure. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct peer {
|
|
|
|
/* BGP structure. */
|
|
|
|
struct bgp *bgp;
|
|
|
|
|
|
|
|
/* reference count, primarily to allow bgp_process'ing of route_node's
|
|
|
|
* to be done after a struct peer is deleted.
|
|
|
|
*
|
|
|
|
* named 'lock' for hysterical reasons within Quagga.
|
|
|
|
*/
|
|
|
|
int lock;
|
|
|
|
|
|
|
|
/* BGP peer group. */
|
|
|
|
struct peer_group *group;
|
|
|
|
uint64_t version[AFI_MAX][SAFI_MAX];
|
|
|
|
|
|
|
|
/* BGP peer_af structures, per configured AF on this peer */
|
|
|
|
struct peer_af *peer_af_array[BGP_AF_MAX];
|
|
|
|
|
|
|
|
/* Peer's remote AS number. */
|
|
|
|
int as_type;
|
|
|
|
as_t as;
|
|
|
|
|
|
|
|
/* Peer's local AS number. */
|
|
|
|
as_t local_as;
|
|
|
|
|
|
|
|
bgp_peer_sort_t sort;
|
|
|
|
|
|
|
|
/* Peer's Change local AS number. */
|
|
|
|
as_t change_local_as;
|
|
|
|
|
|
|
|
/* Remote router ID. */
|
|
|
|
struct in_addr remote_id;
|
|
|
|
|
|
|
|
/* Local router ID. */
|
|
|
|
struct in_addr local_id;
|
|
|
|
|
|
|
|
/* Packet receive and send buffer. */
|
2017-05-02 02:37:45 +02:00
|
|
|
pthread_mutex_t io_mtx; // guards ibuf, obuf
|
|
|
|
struct stream_fifo *ibuf; // packets waiting to be processed
|
|
|
|
struct stream_fifo *obuf; // packets waiting to be written
|
|
|
|
|
2018-01-02 19:20:00 +01:00
|
|
|
struct ringbuf *ibuf_work; // WiP buffer used by bgp_read() only
|
|
|
|
struct stream *obuf_work; // WiP buffer used to construct packets
|
2017-05-02 02:37:45 +02:00
|
|
|
|
|
|
|
struct stream *curr; // the current packet being parsed
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* We use a separate stream to encode MP_REACH_NLRI for efficient
|
2017-05-02 02:37:45 +02:00
|
|
|
* NLRI packing. peer->obuf_work stores all the other attributes. The
|
2017-07-17 14:03:14 +02:00
|
|
|
* actual packet is then constructed by concatenating the two.
|
|
|
|
*/
|
|
|
|
struct stream *scratch;
|
|
|
|
|
|
|
|
/* the doppelganger peer structure, due to dual TCP conn setup */
|
|
|
|
struct peer *doppelganger;
|
|
|
|
|
|
|
|
/* Status of the peer. */
|
|
|
|
int status;
|
|
|
|
int ostatus;
|
|
|
|
|
|
|
|
/* FSM events, stored for debug purposes.
|
|
|
|
* Note: uchar used for reduced memory usage.
|
|
|
|
*/
|
|
|
|
unsigned char cur_event;
|
|
|
|
unsigned char last_event;
|
|
|
|
unsigned char last_major_event;
|
|
|
|
|
|
|
|
/* Peer index, used for dumping TABLE_DUMP_V2 format */
|
|
|
|
uint16_t table_dump_index;
|
|
|
|
|
|
|
|
/* Peer information */
|
|
|
|
int fd; /* File descriptor */
|
|
|
|
int ttl; /* TTL of TCP connection to the peer. */
|
|
|
|
int rtt; /* Estimated round-trip-time from TCP_INFO */
|
|
|
|
int gtsm_hops; /* minimum hopcount to peer */
|
|
|
|
char *desc; /* Description of the peer. */
|
|
|
|
unsigned short port; /* Destination port for peer */
|
|
|
|
char *host; /* Printable address of the peer. */
|
|
|
|
union sockunion su; /* Sockunion address of the peer. */
|
2015-05-20 02:40:40 +02:00
|
|
|
#define BGP_PEER_SU_UNSPEC(peer) (peer->su.sa.sa_family == AF_UNSPEC)
|
2017-07-17 14:03:14 +02:00
|
|
|
time_t uptime; /* Last Up/Down time */
|
|
|
|
time_t readtime; /* Last read time */
|
|
|
|
time_t resettime; /* Last reset time */
|
|
|
|
|
|
|
|
char *conf_if; /* neighbor interface config name. */
|
|
|
|
struct interface *ifp; /* corresponding interface */
|
|
|
|
char *ifname; /* bind interface name. */
|
|
|
|
char *update_if;
|
|
|
|
union sockunion *update_source;
|
|
|
|
|
|
|
|
union sockunion *su_local; /* Sockunion of local address. */
|
|
|
|
union sockunion *su_remote; /* Sockunion of remote address. */
|
|
|
|
int shared_network; /* Is this peer shared same network. */
|
|
|
|
struct bgp_nexthop nexthop; /* Nexthop */
|
|
|
|
|
|
|
|
/* Peer address family configuration. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t afc[AFI_MAX][SAFI_MAX];
|
|
|
|
uint8_t afc_nego[AFI_MAX][SAFI_MAX];
|
|
|
|
uint8_t afc_adv[AFI_MAX][SAFI_MAX];
|
|
|
|
uint8_t afc_recv[AFI_MAX][SAFI_MAX];
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Capability flags (reset in bgp_stop) */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t cap;
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_CAP_REFRESH_ADV (1 << 0) /* refresh advertised */
|
|
|
|
#define PEER_CAP_REFRESH_OLD_RCV (1 << 1) /* refresh old received */
|
|
|
|
#define PEER_CAP_REFRESH_NEW_RCV (1 << 2) /* refresh rfc received */
|
|
|
|
#define PEER_CAP_DYNAMIC_ADV (1 << 3) /* dynamic advertised */
|
|
|
|
#define PEER_CAP_DYNAMIC_RCV (1 << 4) /* dynamic received */
|
2004-05-21 11:31:30 +02:00
|
|
|
#define PEER_CAP_RESTART_ADV (1 << 5) /* restart advertised */
|
|
|
|
#define PEER_CAP_RESTART_RCV (1 << 6) /* restart received */
|
[bgpd] Merge AS4 support
2007-10-14 Paul Jakma <paul.jakma@sun.com>
* NEWS: Note that MRT dumps are now version 2
* (general) Merge in Juergen Kammer's AS4 patch.
2007-09-27 Paul Jakma <paul.jakma@sun.com>
* bgp_aspath.c: (assegment_normalise) remove duplicates from
from sets.
(aspath_reconcile_as4) disregard a broken part of the RFC around
error handling in path reconciliation.
* aspath_test.c: Test dupe-weeding from sets.
Test that reconciliation merges AS_PATH and AS4_PATH where
former is shorter than latter.
2007-09-26 Paul Jakma <paul.jakma@sun.com>
* aspath_test.c: Test AS4_PATH reconcilation where length
of AS_PATH and AS4_PATH is same.
2007-09-25 Paul Jakma <paul.jakma@sun.com>
* bgp_open.c: (peek_for_as4_capability) Fix to work.
* bgp_packet.c: (bgp_open_receive) Fix sanity check of as4.
* tests/bgp_capability_test.c: (general) Extend tests to validate
peek_for_as4_capability.
Add test of full OPEN Option block, with multiple capabilities,
both as a series of Option, and a single option.
Add some crap to beginning of stream, to prevent code depending
on getp == 0.
2007-09-18 Paul Jakma <paul.jakma@sun.com>
* bgp_open.c: (bgp_capability_as4) debug printf inline with others.
(peek_for_as4_capability) There's no need to signal failure, as
failure is better dealt with through full capability parser -
just return the AS4, simpler.
* bgp_packet.c: (bgp_open_receive) Update to match
peek_for_as4_capability change.
Allow use of BGP_AS_TRANS by 2b speakers.
Use NOTIFY_OPEN_ERR rather than CEASE for OPEN parsing errors.
(bgp_capability_msg_parse) missing argument to debug print
(bgp_capability_receive) missing return values.
* tests/bgp_capability_test.c: (parse_test) update for changes to
peek_for_as4_capability
2007-07-25 Paul Jakma <paul.jakma@sun.com>
* Remove 2-byte size macros, just make existing macros take
argument to indicate which size to use.
Adjust all users - typically they want '1'.
* bgp_aspath.c: (aspath_has_as4) New, return 1 if there are any
as4's in a path.
(aspath_put) Return the number of bytes actually written, to
fix the bug Juergen noted: Splitting of segments will change
the number of bytes written from that already written to the
AS_PATH header.
(aspath_snmp_pathseg) Pass 2-byte flag to aspath_put. SNMP
is still defined as 2b.
(aspath_aggregate) fix latent bug.
(aspath_reconcile_as4) AS_PATH+NEW_AS_PATH reconciliation
function.
(aspath_key_make) Hash the AS_PATH string, rather than
just taking the addition of assegment ASes as the hash value,
hopefully sligthly more collision resistant.
(bgp_attr_munge_as4_attrs) Collide the NEW_ attributes
together with the OLD 2-byte forms, code Juergen
had in bgp_attr_parse but re-organised a bit.
(bgp_attr_parse) Bunch of code from Juergen moves
to previous function.
(bgp_packet_attribute) Compact significantly by
just /always/ using extended-length attr header.
Fix bug Juergen noted, by using aspath_put's
(new) returned size value for the attr header rather
than the (guesstimate) of aspath_size() - the two could
differ when aspath_put had to split large segments, unlikely
this bug was ever hit in the 'wild'.
(bgp_dump_routes_attr) Always use extended-len and
use aspath_put return for header length. Output 4b ASN
for AS_PATH and AGGREGATOR.
* bgp_ecommunity.c: (ecommunity_{hash_make,cmp}) fix
hash callback declarations to match prototypes.
(ecommunity_gettoken) Updated for ECOMMUNITY_ENCODE_AS4,
complete rewrite of Juergen's changes (no asdot support)
* bgp_open.c: (bgp_capability_as4) New, does what it says
on the tin.
(peek_for_as4_capability) Rewritten to use streams and
bgp_capability_as4.
* bgp_packet.c: (bgp_open_send) minor edit
checked (in the abstract at least) with Juergen.
Changes are to be more accepting, e.g, allow AS_TRANS on
a 2-byte session.
* (general) Update all commands to use CMD_AS_RANGE.
* bgp_vty.c: (bgp_clear) Fix return vals to use CMD_..
Remove stuff replicated by VTY_GET_LONG
(bgp_clear_vty) Return bgp_clear directly to vty.
* tests/aspath_test.c: Exercise 32bit parsing. Test reconcile
function.
* tests/ecommunity_test.c: New, test AS4 ecommunity changes,
positive test only at this time, error cases not tested yet.
2007-07-25 Juergen Kammer <j.kammer@eurodata.de>
* (general) AS4 support.
* bgpd.h: as_t changes to 4-bytes.
* bgp_aspath.h: Add BGP_AS4_MAX and BGP_AS_TRANS defines.
* bgp_aspath.c: AS_VALUE_SIZE becomes 4-byte, AS16_VALUE_SIZE
added for 2-byte.
Add AS16 versions of length calc macros.
(aspath_count_numas) New, count number of ASes.
(aspath_has_as4) New, return 1 if there are any as4's in a
path.
(assegments_parse) Interpret assegment as 4 or 2 byte,
according to how the caller instructs us, with a new
argument.
(aspath_parse) Add use32bit argument to pass to
assegments_parse. Adjust all its callers to pass 1, unless
otherwise noted.
(assegment_data_put) Adjust to be able to write 2 or 4 byte
AS, according to new use32bit argument.
(aspath_put) Adjust to write 2 or 4.
(aspath_gettoken) Use a long for passed in asno.
* bgp_attr.c: (attr_str) Add BGP_ATTR_AS4_PATH and
BGP_ATTR_AS4_AGGREGATOR.
(bgp_attr_aspath) Call aspath_parse with right 2/4 arg, as
determined by received-capability flag.
(bgp_attr_aspath_check) New, code previously in attr_aspath
but moved to new func so it can be run after NEW_AS_PATH
reconciliation.
(bgp_attr_as4_path) New, handle NEW_AS_PATH.
(bgp_attr_aggregator) Adjust to cope with 2/4 byte ASes.
(bgp_attr_as4_aggregator) New, read NEW_AGGREGATOR.
(bgp_attr_parse) Add handoffs to previous parsers for the two
new AS4 NEW_ attributes.
Various checks added for NEW/OLD reconciliation.
(bgp_packet_attribute) Support 2/4 for AS_PATH and
AGGREGATOR, detect when NEW_ attrs need to be sent.
* bgp_debug.{c,h}: Add 'debug bgp as4'.
* bgp_dump.c: MRTv2 support, unconditionally enabled, which
supports AS4. Based on patches from Erik (RIPE?).
* bgp_ecommunity.c: (ecommunity_ecom2str) ECOMMUNITY_ENCODE_AS4
support.
* bgp_open.c: (peek_for_as4_capability) New, peek for AS4
capability prior to full capability parsing, so we know which
ASN to use for struct peer lookup.
(bgp_open_capability) Always send AS4 capability.
* bgp_packet.c: (bgp_open_send) AS4 handling for AS field
(bgp_open_receive) Peek for AS4 capability first, and figure
out which AS to believe.
* bgp_vty.c: (bgp_show_peer) Print AS4 cap
* tests/aspath_test.c: Support asn32 changes, call aspath_parse
with 16 bit.
* vtysh/extract.pl: AS4 compatibility for router bgp ASNUMBER
* vtysh/extract.pl.in: AS4 compatibility for router bgp ASNUMBER
* vtysh/vtysh.c: AS4 compatibility for router bgp ASNUMBER
2007-10-15 00:32:21 +02:00
|
|
|
#define PEER_CAP_AS4_ADV (1 << 7) /* as4 advertised */
|
|
|
|
#define PEER_CAP_AS4_RCV (1 << 8) /* as4 received */
|
2015-05-20 02:40:32 +02:00
|
|
|
#define PEER_CAP_RESTART_BIT_ADV (1 << 9) /* sent restart state */
|
|
|
|
#define PEER_CAP_RESTART_BIT_RCV (1 << 10) /* peer restart state */
|
2015-05-20 03:03:45 +02:00
|
|
|
#define PEER_CAP_ADDPATH_ADV (1 << 11) /* addpath advertised */
|
|
|
|
#define PEER_CAP_ADDPATH_RCV (1 << 12) /* addpath received */
|
2015-06-12 16:59:12 +02:00
|
|
|
#define PEER_CAP_ENHE_ADV (1 << 13) /* Extended nexthop advertised */
|
|
|
|
#define PEER_CAP_ENHE_RCV (1 << 14) /* Extended nexthop received */
|
2015-09-11 05:10:16 +02:00
|
|
|
#define PEER_CAP_HOSTNAME_ADV (1 << 15) /* hostname advertised */
|
|
|
|
#define PEER_CAP_HOSTNAME_RCV (1 << 16) /* hostname received */
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Capability flags (reset in bgp_stop) */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t af_cap[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_CAP_ORF_PREFIX_SM_ADV (1 << 0) /* send-mode advertised */
|
|
|
|
#define PEER_CAP_ORF_PREFIX_RM_ADV (1 << 1) /* receive-mode advertised */
|
|
|
|
#define PEER_CAP_ORF_PREFIX_SM_RCV (1 << 2) /* send-mode received */
|
|
|
|
#define PEER_CAP_ORF_PREFIX_RM_RCV (1 << 3) /* receive-mode received */
|
|
|
|
#define PEER_CAP_ORF_PREFIX_SM_OLD_RCV (1 << 4) /* send-mode received */
|
|
|
|
#define PEER_CAP_ORF_PREFIX_RM_OLD_RCV (1 << 5) /* receive-mode received */
|
2005-02-02 15:40:33 +01:00
|
|
|
#define PEER_CAP_RESTART_AF_RCV (1 << 6) /* graceful restart afi/safi received */
|
|
|
|
#define PEER_CAP_RESTART_AF_PRESERVE_RCV (1 << 7) /* graceful restart afi/safi F-bit received */
|
2015-05-20 03:03:45 +02:00
|
|
|
#define PEER_CAP_ADDPATH_AF_TX_ADV (1 << 8) /* addpath tx advertised */
|
|
|
|
#define PEER_CAP_ADDPATH_AF_TX_RCV (1 << 9) /* addpath tx received */
|
|
|
|
#define PEER_CAP_ADDPATH_AF_RX_ADV (1 << 10) /* addpath rx advertised */
|
|
|
|
#define PEER_CAP_ADDPATH_AF_RX_RCV (1 << 11) /* addpath rx received */
|
2015-06-11 18:19:12 +02:00
|
|
|
#define PEER_CAP_ENHE_AF_ADV (1 << 12) /* Extended nexthopi afi/safi advertised */
|
|
|
|
#define PEER_CAP_ENHE_AF_RCV (1 << 13) /* Extended nexthop afi/safi received */
|
|
|
|
#define PEER_CAP_ENHE_AF_NEGO (1 << 14) /* Extended nexthop afi/safi negotiated */
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Global configuration flags. */
|
bgpd: Implement group-overrides for peer flags
The current implementation of peer flags (e.g. shutdown, passive, ...)
only has partial support for overriding flags of a peer-group when the
peer is a member. Often settings might get lost if the user toys around
with the peer-group configuration, which can lead to disaster.
This commit introduces the same override implementation which was
previously integrated to support proper peer flag/attribute override on
the address-family level. The code is very similar and the global
attributes now use their separate state-arrays *flags_invert* and
*flags_override*.
The test suite for BGP peer attributes was extended to also check peer
global attributes, so that the newly introduced changes are covered. An
additional feature was added which allows to test an attribute with an
*interface-peer*, which can be configured by running `neighbor IF-TEST
interface`. This was introduced so that the dynamic runtime inversion of
the `extended-nexthop` flag, which is only enabled by default for
interface peers, can also be tested.
Last but not least, two small changes have been made to the current bgpd
implementation:
- The command `strict-capability-match` can now also be set on a
peer-group, it seems like this command slipped through while
implementing peer-groups in the very past.
- The macro `COND_FLAG` was introduced inside lib/zebra.h, which now
allows to either set or unset a flag based on a condition. The syntax
for using this macro is: `COND_FLAG(flag_variable, flag, condition)`
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-06-11 19:49:20 +02:00
|
|
|
/*
|
|
|
|
* Parallel array to flags that indicates whether each flag originates
|
|
|
|
* from a peer-group or if it is config that is specific to this
|
|
|
|
* individual peer. If a flag is set independent of the peer-group, the
|
|
|
|
* same bit should be set here. If this peer is a peer-group, this
|
|
|
|
* memory region should be all zeros.
|
|
|
|
*
|
|
|
|
* The assumption is that the default state for all flags is unset,
|
|
|
|
* so if a flag is unset, the corresponding override flag is unset too.
|
|
|
|
* However if a flag is set, the corresponding override flag is set.
|
|
|
|
*/
|
|
|
|
uint32_t flags_override;
|
|
|
|
/*
|
|
|
|
* Parallel array to flags that indicates whether the default behavior
|
|
|
|
* of *flags_override* should be inverted. If a flag is unset and the
|
|
|
|
* corresponding invert flag is set, the corresponding override flag
|
|
|
|
* would be set. However if a flag is set and the corresponding invert
|
|
|
|
* flag is unset, the corresponding override flag would be unset.
|
|
|
|
*
|
|
|
|
* This can be used for attributes like *send-community*, which are
|
|
|
|
* implicitely enabled and have to be disabled explicitely, compared to
|
|
|
|
* 'normal' attributes like *next-hop-self* which are implicitely set.
|
|
|
|
*
|
|
|
|
* All operations dealing with flags should apply the following boolean
|
|
|
|
* logic to keep the internal flag system in a sane state:
|
|
|
|
*
|
|
|
|
* value=0 invert=0 Inherit flag if member, otherwise unset flag
|
|
|
|
* value=0 invert=1 Unset flag unconditionally
|
|
|
|
* value=1 invert=0 Set flag unconditionally
|
|
|
|
* value=1 invert=1 Inherit flag if member, otherwise set flag
|
|
|
|
*
|
|
|
|
* Contrary to the implementation of *flags_override*, the flag
|
|
|
|
* inversion state can be set either on the peer OR the peer *and* the
|
|
|
|
* peer-group. This was done on purpose, as the inversion state of a
|
|
|
|
* flag can be determined on either the peer or the peer-group.
|
|
|
|
*
|
|
|
|
* Example: Enabling the cisco configuration mode inverts all flags
|
|
|
|
* related to *send-community* unconditionally for both peer-groups and
|
|
|
|
* peers.
|
|
|
|
*
|
|
|
|
* This behavior is different for interface peers though, which enable
|
|
|
|
* the *extended-nexthop* flag by default, which regular peers do not.
|
|
|
|
* As the peer-group can contain both regular and interface peers, the
|
|
|
|
* flag inversion state must be set on the peer only.
|
|
|
|
*
|
|
|
|
* When a peer inherits the configuration from a peer-group and the
|
|
|
|
* inversion state of the flag differs between peer and peer-group, the
|
|
|
|
* newly set value must equal to the inverted state of the peer-group.
|
|
|
|
*/
|
|
|
|
uint32_t flags_invert;
|
|
|
|
/*
|
|
|
|
* Effective array for storing the peer/peer-group flags. In case of a
|
|
|
|
* peer-group, the peer-specific overrides (see flags_override and
|
|
|
|
* flags_invert) must be respected.
|
|
|
|
*/
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t flags;
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_FLAG_PASSIVE (1 << 0) /* passive mode */
|
|
|
|
#define PEER_FLAG_SHUTDOWN (1 << 1) /* shutdown */
|
|
|
|
#define PEER_FLAG_DONT_CAPABILITY (1 << 2) /* dont-capability */
|
|
|
|
#define PEER_FLAG_OVERRIDE_CAPABILITY (1 << 3) /* override-capability */
|
|
|
|
#define PEER_FLAG_STRICT_CAP_MATCH (1 << 4) /* strict-match */
|
2005-02-01 23:01:48 +01:00
|
|
|
#define PEER_FLAG_DYNAMIC_CAPABILITY (1 << 5) /* dynamic capability */
|
2005-02-02 15:50:11 +01:00
|
|
|
#define PEER_FLAG_DISABLE_CONNECTED_CHECK (1 << 6) /* disable-connected-check */
|
2005-02-01 23:01:48 +01:00
|
|
|
#define PEER_FLAG_LOCAL_AS_NO_PREPEND (1 << 7) /* local-as no-prepend */
|
bgpd: add replace-as modifier for BGP neighbor
Added replace-as modifier for BGP neighbors when using
local-as. If the replace-as modifier is specified, only the
replacement AS as specified by the local-as modifier is
prepended to the AS_PATH, not the process's AS.
In bgp_attr.c, I decided that
if (peer->change_local_as) {
/* If replace-as is specified, we only use the change_local_as when
advertising routes. */
if( ! CHECK_FLAG (peer->flags, PEER_FLAG_LOCAL_AS_REPLACE_AS) ) {
aspath = aspath_add_seq (aspath, peer->local_as);
}
aspath = aspath_add_seq (aspath, peer->change_local_as);
} else {
aspath = aspath_add_seq (aspath, peer->local_as);
}
was clearer than the alternative that didn't duplicate the prepending of the
process's AS:
/* First, append the process local AS unless we have an alternate local_as
* and we're replacing it (as opposed to just prepending it). */
if (! (peer->change_local_as
&& CHECK_FLAG (peer->flags, PEER_FLAG_LOCAL_AS_REPLACE_AS) ) ) {
aspath = aspath_add_seq (aspath, peer->local_as);
}
if (peer->change_local_as)
aspath = aspath_add_seq (aspath, peer->change_local_as);
}
But I could be convinced otherwise.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2012-11-08 00:50:07 +01:00
|
|
|
#define PEER_FLAG_LOCAL_AS_REPLACE_AS (1 << 8) /* local-as no-prepend replace-as */
|
2018-05-17 22:51:35 +02:00
|
|
|
#define PEER_FLAG_DELETE (1 << 9) /* mark the peer for deleting */
|
|
|
|
#define PEER_FLAG_CONFIG_NODE (1 << 10) /* the node to update configs on */
|
2015-07-22 21:35:37 +02:00
|
|
|
#define PEER_FLAG_LONESOUL (1 << 11)
|
|
|
|
#define PEER_FLAG_DYNAMIC_NEIGHBOR (1 << 12) /* dynamic neighbor */
|
|
|
|
#define PEER_FLAG_CAPABILITY_ENHE (1 << 13) /* Extended next-hop (rfc 5549)*/
|
2015-07-26 00:55:47 +02:00
|
|
|
#define PEER_FLAG_IFPEER_V6ONLY (1 << 14) /* if-based peer is v6 only */
|
2018-05-17 22:51:35 +02:00
|
|
|
#define PEER_FLAG_IS_RFAPI_HD (1 << 15) /* attached to rfapi HD */
|
|
|
|
#define PEER_FLAG_ENFORCE_FIRST_AS (1 << 16) /* enforce-first-as */
|
2018-06-13 02:34:43 +02:00
|
|
|
#define PEER_FLAG_ROUTEADV (1 << 17) /* route advertise */
|
|
|
|
#define PEER_FLAG_TIMER (1 << 18) /* keepalive & holdtime */
|
|
|
|
#define PEER_FLAG_TIMER_CONNECT (1 << 19) /* connect timer */
|
2018-06-13 19:34:17 +02:00
|
|
|
#define PEER_FLAG_PASSWORD (1 << 20) /* password */
|
|
|
|
#define PEER_FLAG_LOCAL_AS (1 << 21) /* local-as */
|
|
|
|
#define PEER_FLAG_UPDATE_SOURCE (1 << 22) /* update-source */
|
2017-10-10 16:00:10 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* outgoing message sent in CEASE_ADMIN_SHUTDOWN notify */
|
|
|
|
char *tx_shutdown_message;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* NSF mode (graceful restart) */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t nsf[AFI_MAX][SAFI_MAX];
|
2005-02-02 15:40:33 +01:00
|
|
|
|
2018-05-07 19:25:10 +02:00
|
|
|
/* Peer Per AF flags */
|
|
|
|
/*
|
bgpd: Implement group-overrides for peer flags
The current implementation of peer flags (e.g. shutdown, passive, ...)
only has partial support for overriding flags of a peer-group when the
peer is a member. Often settings might get lost if the user toys around
with the peer-group configuration, which can lead to disaster.
This commit introduces the same override implementation which was
previously integrated to support proper peer flag/attribute override on
the address-family level. The code is very similar and the global
attributes now use their separate state-arrays *flags_invert* and
*flags_override*.
The test suite for BGP peer attributes was extended to also check peer
global attributes, so that the newly introduced changes are covered. An
additional feature was added which allows to test an attribute with an
*interface-peer*, which can be configured by running `neighbor IF-TEST
interface`. This was introduced so that the dynamic runtime inversion of
the `extended-nexthop` flag, which is only enabled by default for
interface peers, can also be tested.
Last but not least, two small changes have been made to the current bgpd
implementation:
- The command `strict-capability-match` can now also be set on a
peer-group, it seems like this command slipped through while
implementing peer-groups in the very past.
- The macro `COND_FLAG` was introduced inside lib/zebra.h, which now
allows to either set or unset a flag based on a condition. The syntax
for using this macro is: `COND_FLAG(flag_variable, flag, condition)`
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-06-11 19:49:20 +02:00
|
|
|
* Please consult the comments for *flags_override*, *flags_invert* and
|
|
|
|
* *flags* to understand what these three arrays do. The address-family
|
|
|
|
* specific attributes are being treated the exact same way as global
|
|
|
|
* peer attributes.
|
2018-05-07 19:25:10 +02:00
|
|
|
*/
|
|
|
|
uint32_t af_flags_override[AFI_MAX][SAFI_MAX];
|
2018-05-27 17:39:45 +02:00
|
|
|
uint32_t af_flags_invert[AFI_MAX][SAFI_MAX];
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t af_flags[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_FLAG_SEND_COMMUNITY (1 << 0) /* send-community */
|
|
|
|
#define PEER_FLAG_SEND_EXT_COMMUNITY (1 << 1) /* send-community ext. */
|
|
|
|
#define PEER_FLAG_NEXTHOP_SELF (1 << 2) /* next-hop-self */
|
|
|
|
#define PEER_FLAG_REFLECTOR_CLIENT (1 << 3) /* reflector-client */
|
|
|
|
#define PEER_FLAG_RSERVER_CLIENT (1 << 4) /* route-server-client */
|
|
|
|
#define PEER_FLAG_SOFT_RECONFIG (1 << 5) /* soft-reconfiguration */
|
|
|
|
#define PEER_FLAG_AS_PATH_UNCHANGED (1 << 6) /* transparent-as */
|
|
|
|
#define PEER_FLAG_NEXTHOP_UNCHANGED (1 << 7) /* transparent-next-hop */
|
|
|
|
#define PEER_FLAG_MED_UNCHANGED (1 << 8) /* transparent-next-hop */
|
|
|
|
#define PEER_FLAG_DEFAULT_ORIGINATE (1 << 9) /* default-originate */
|
|
|
|
#define PEER_FLAG_REMOVE_PRIVATE_AS (1 << 10) /* remove-private-as */
|
|
|
|
#define PEER_FLAG_ALLOWAS_IN (1 << 11) /* set allowas-in */
|
|
|
|
#define PEER_FLAG_ORF_PREFIX_SM (1 << 12) /* orf capability send-mode */
|
|
|
|
#define PEER_FLAG_ORF_PREFIX_RM (1 << 13) /* orf capability receive-mode */
|
|
|
|
#define PEER_FLAG_MAX_PREFIX (1 << 14) /* maximum prefix */
|
|
|
|
#define PEER_FLAG_MAX_PREFIX_WARNING (1 << 15) /* maximum prefix warning-only */
|
[bgpd] TCP-MD5: password vty configuration and initial Linux support
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* bgp_packet.c: (bgp_open_receive) fix warning in a zlog call
* bgp_vty.c: (bgp_vty_return) add return code
* bgpd.c: (bgp_master_init) setup the socket list.
* bgp_network.c: Remove the dual IPv4/6 socket thing for now, which
was implemented by Michael, until such time as its clear its
required for Linux (see sockopt comments). IPv6 support, including
IPv4 sessions on AF_INET6 sockets, therefore is broken, and the
'-l 0.0.0.0' arguments would need to be given to bgpd to make
things work here.
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Tomohiko Kusuda <kusuda@inetcore.com>
Leigh Brown <leigh@solinno.co.uk>
* bgp_network.c: (bgp_md5_set_one) shim between libzebra tcp-md5
sockopt and bgpd.
(bgp_md5_set_socket) Helper for bgp_connect
(bgp_md5_set) setup TCP-MD5SIG for the given peer.
(bgp_connect) call out to bgp_md5_set_socket for the outgoing
connect socket.
(bgp_socket) save references to the listen sockets, needed if
TCP-MD5SIG is applied later or changed.
* bgp_vty.c: (*neighbor_password_cmd) New 'neighbor ... password'
commands.
* bgpd.c: (peer_{new,delete) manage TCP-MD5 password
(peer_group2peer_config_copy) inherit TCP-MD5 password
(peer_password_{un,}set) orchestrate the whole add/remove of TCP-MD5
passwords: applying checks, stopping peers, and trying to return
errors to UI, etc.
(bgp_config_write_peer) save password.
Fix missing newline in writeout of neighbor ... port.
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* sockunion.c: ifdef out various places that converted
v4mapped sockets to pure v4. Doesn't seem necessary at all,
presumably a workaround for now historical inet_ntop bugs (?)
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* sockopt.{c,h}: (sockopt_tcp_signature) Add TCP-MD5SIG support.
2008-07-21 23:02:49 +02:00
|
|
|
#define PEER_FLAG_NEXTHOP_LOCAL_UNCHANGED (1 << 16) /* leave link-local nexthop unchanged */
|
2015-07-22 22:18:24 +02:00
|
|
|
#define PEER_FLAG_FORCE_NEXTHOP_SELF (1 << 17) /* next-hop-self force */
|
2015-05-20 02:57:34 +02:00
|
|
|
#define PEER_FLAG_REMOVE_PRIVATE_AS_ALL (1 << 18) /* remove-private-as all */
|
|
|
|
#define PEER_FLAG_REMOVE_PRIVATE_AS_REPLACE (1 << 19) /* remove-private-as replace-as */
|
2015-05-20 03:03:14 +02:00
|
|
|
#define PEER_FLAG_AS_OVERRIDE (1 << 20) /* as-override */
|
2015-10-28 02:54:48 +01:00
|
|
|
#define PEER_FLAG_REMOVE_PRIVATE_AS_ALL_REPLACE (1 << 21) /* remove-private-as all replace-as */
|
2016-10-10 16:53:34 +02:00
|
|
|
#define PEER_FLAG_WEIGHT (1 << 24) /* weight */
|
bgpd: add 'neighbor x.x.x.x allowas-in origin' knob
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-13207
normal table on spine-1....we do not see 6.0.0.10 (spine-2's loopback)
spine-1 and spine-2 are in AS 65200
superm-redxp-05# show ip bgp
BGP table version is 13, local router ID is 6.0.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 6.0.0.5/32 swp1 0 0 65101 ?
*> 6.0.0.6/32 swp2 0 0 65101 ?
*> 6.0.0.7/32 swp3 0 0 65104 ?
*> 6.0.0.8/32 swp4 0 0 65104 ?
*> 6.0.0.9/32 0.0.0.0 0 32768 ?
*= 6.0.0.11/32 swp2 0 65101 65001 ?
*> swp1 0 65101 65001 ?
*= 6.0.0.12/32 swp2 0 65101 65002 ?
*> swp1 0 65101 65002 ?
*= 6.0.0.13/32 swp4 0 65104 65001 ?
*> swp3 0 65104 65001 ?
*= 6.0.0.14/32 swp4 0 65104 65002 ?
*> swp3 0 65104 65002 ?
Displayed 9 out of 13 total prefixes
superm-redxp-05#
spine-1 with "neighbor x.x.x.x allowas-in origin", we now see 6.0.0.10
superm-redxp-05# show ip bgp
BGP table version is 14, local router ID is 6.0.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 6.0.0.5/32 swp1 0 0 65101 ?
*> 6.0.0.6/32 swp2 0 0 65101 ?
*> 6.0.0.7/32 swp3 0 0 65104 ?
*> 6.0.0.8/32 swp4 0 0 65104 ?
* 6.0.0.9/32 swp2 0 65101 65200 ?
* swp1 0 65101 65200 ?
* swp3 0 65104 65200 ?
* swp4 0 65104 65200 ?
*> 0.0.0.0 0 32768 ?
*= 6.0.0.10/32 swp2 0 65101 65200 ?
*> swp1 0 65101 65200 ?
*= swp3 0 65104 65200 ?
*= swp4 0 65104 65200 ?
*= 6.0.0.11/32 swp2 0 65101 65001 ?
*> swp1 0 65101 65001 ?
*= 6.0.0.12/32 swp2 0 65101 65002 ?
*> swp1 0 65101 65002 ?
*= 6.0.0.13/32 swp4 0 65104 65001 ?
*> swp3 0 65104 65001 ?
*= 6.0.0.14/32 swp4 0 65104 65002 ?
*> swp3 0 65104 65002 ?
Displayed 10 out of 21 total prefixes
superm-redxp-05#
The only as-paths with 65200 that made it through were the ones that
originated from 65200
superm-redxp-05# show ip bgp regexp _65200_
BGP table version is 14, local router ID is 6.0.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 6.0.0.9/32 swp2 0 65101 65200 ?
* swp1 0 65101 65200 ?
* swp3 0 65104 65200 ?
* swp4 0 65104 65200 ?
*= 6.0.0.10/32 swp2 0 65101 65200 ?
*> swp1 0 65101 65200 ?
*= swp3 0 65104 65200 ?
*= swp4 0 65104 65200 ?
Displayed 2 out of 21 total prefixes
superm-redxp-05#
2016-10-21 19:51:05 +02:00
|
|
|
#define PEER_FLAG_ALLOWAS_IN_ORIGIN (1 << 25) /* allowas-in origin */
|
2016-11-15 11:00:39 +01:00
|
|
|
#define PEER_FLAG_SEND_LARGE_COMMUNITY (1 << 26) /* Send large Communities */
|
[bgpd] TCP-MD5: password vty configuration and initial Linux support
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* bgp_packet.c: (bgp_open_receive) fix warning in a zlog call
* bgp_vty.c: (bgp_vty_return) add return code
* bgpd.c: (bgp_master_init) setup the socket list.
* bgp_network.c: Remove the dual IPv4/6 socket thing for now, which
was implemented by Michael, until such time as its clear its
required for Linux (see sockopt comments). IPv6 support, including
IPv4 sessions on AF_INET6 sockets, therefore is broken, and the
'-l 0.0.0.0' arguments would need to be given to bgpd to make
things work here.
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Tomohiko Kusuda <kusuda@inetcore.com>
Leigh Brown <leigh@solinno.co.uk>
* bgp_network.c: (bgp_md5_set_one) shim between libzebra tcp-md5
sockopt and bgpd.
(bgp_md5_set_socket) Helper for bgp_connect
(bgp_md5_set) setup TCP-MD5SIG for the given peer.
(bgp_connect) call out to bgp_md5_set_socket for the outgoing
connect socket.
(bgp_socket) save references to the listen sockets, needed if
TCP-MD5SIG is applied later or changed.
* bgp_vty.c: (*neighbor_password_cmd) New 'neighbor ... password'
commands.
* bgpd.c: (peer_{new,delete) manage TCP-MD5 password
(peer_group2peer_config_copy) inherit TCP-MD5 password
(peer_password_{un,}set) orchestrate the whole add/remove of TCP-MD5
passwords: applying checks, stopping peers, and trying to return
errors to UI, etc.
(bgp_config_write_peer) save password.
Fix missing newline in writeout of neighbor ... port.
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* sockunion.c: ifdef out various places that converted
v4mapped sockets to pure v4. Doesn't seem necessary at all,
presumably a workaround for now historical inet_ntop bugs (?)
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* sockopt.{c,h}: (sockopt_tcp_signature) Add TCP-MD5SIG support.
2008-07-21 23:02:49 +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
|
|
|
enum bgp_addpath_strat addpath_type[AFI_MAX][SAFI_MAX];
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* MD5 password */
|
|
|
|
char *password;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* default-originate route-map. */
|
|
|
|
struct {
|
|
|
|
char *name;
|
|
|
|
struct route_map *map;
|
|
|
|
} default_rmap[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Peer status flags. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t sflags;
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_STATUS_ACCEPT_PEER (1 << 0) /* accept peer */
|
|
|
|
#define PEER_STATUS_PREFIX_OVERFLOW (1 << 1) /* prefix-overflow */
|
|
|
|
#define PEER_STATUS_CAPABILITY_OPEN (1 << 2) /* capability open send */
|
|
|
|
#define PEER_STATUS_HAVE_ACCEPT (1 << 3) /* accept peer's parent */
|
|
|
|
#define PEER_STATUS_GROUP (1 << 4) /* peer-group conf */
|
2005-02-02 15:40:33 +01:00
|
|
|
#define PEER_STATUS_NSF_MODE (1 << 5) /* NSF aware peer */
|
|
|
|
#define PEER_STATUS_NSF_WAIT (1 << 6) /* wait comeback peer */
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Peer status af flags (reset in bgp_stop) */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint16_t af_sflags[AFI_MAX][SAFI_MAX];
|
2002-12-13 21:15:29 +01:00
|
|
|
#define PEER_STATUS_ORF_PREFIX_SEND (1 << 0) /* prefix-list send peer */
|
|
|
|
#define PEER_STATUS_ORF_WAIT_REFRESH (1 << 1) /* wait refresh received peer */
|
2015-05-20 03:29:19 +02:00
|
|
|
#define PEER_STATUS_PREFIX_THRESHOLD (1 << 2) /* exceed prefix-threshold */
|
|
|
|
#define PEER_STATUS_PREFIX_LIMIT (1 << 3) /* exceed prefix-limit */
|
|
|
|
#define PEER_STATUS_EOR_SEND (1 << 4) /* end-of-rib send to peer */
|
|
|
|
#define PEER_STATUS_EOR_RECEIVED (1 << 5) /* end-of-rib received from peer */
|
2004-05-20 11:19:34 +02:00
|
|
|
|
2018-06-13 02:34:43 +02:00
|
|
|
/* Configured timer values. */
|
2017-07-05 17:38:57 +02:00
|
|
|
_Atomic uint32_t holdtime;
|
|
|
|
_Atomic uint32_t keepalive;
|
|
|
|
_Atomic uint32_t connect;
|
|
|
|
_Atomic uint32_t routeadv;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Timer values. */
|
2017-07-05 17:38:57 +02:00
|
|
|
_Atomic uint32_t v_start;
|
|
|
|
_Atomic uint32_t v_connect;
|
|
|
|
_Atomic uint32_t v_holdtime;
|
|
|
|
_Atomic uint32_t v_keepalive;
|
|
|
|
_Atomic uint32_t v_routeadv;
|
|
|
|
_Atomic uint32_t v_pmax_restart;
|
|
|
|
_Atomic uint32_t v_gr_restart;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Threads. */
|
|
|
|
struct thread *t_read;
|
2017-05-02 02:37:45 +02:00
|
|
|
struct thread *t_write;
|
2017-07-17 14:03:14 +02:00
|
|
|
struct thread *t_start;
|
2017-09-25 04:18:15 +02:00
|
|
|
struct thread *t_connect_check_r;
|
|
|
|
struct thread *t_connect_check_w;
|
2017-07-17 14:03:14 +02:00
|
|
|
struct thread *t_connect;
|
|
|
|
struct thread *t_holdtime;
|
|
|
|
struct thread *t_routeadv;
|
|
|
|
struct thread *t_pmax_restart;
|
|
|
|
struct thread *t_gr_restart;
|
|
|
|
struct thread *t_gr_stale;
|
2017-04-18 20:11:43 +02:00
|
|
|
struct thread *t_generate_updgrp_packets;
|
2017-05-02 02:37:45 +02:00
|
|
|
struct thread *t_process_packet;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2017-03-27 21:47:23 +02:00
|
|
|
/* Thread flags. */
|
2018-11-19 19:44:35 +01:00
|
|
|
_Atomic uint32_t thread_flags;
|
2017-06-08 23:14:18 +02:00
|
|
|
#define PEER_THREAD_WRITES_ON (1 << 0)
|
|
|
|
#define PEER_THREAD_READS_ON (1 << 1)
|
|
|
|
#define PEER_THREAD_KEEPALIVES_ON (1 << 2)
|
2017-07-17 14:03:14 +02:00
|
|
|
/* workqueues */
|
|
|
|
struct work_queue *clear_node_queue;
|
|
|
|
|
2018-02-09 19:22:50 +01:00
|
|
|
#define PEER_TOTAL_RX(peer) \
|
|
|
|
atomic_load_explicit(&peer->open_in, memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->update_in, memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->notify_in, memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->refresh_in, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->keepalive_in, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->dynamic_cap_in, \
|
|
|
|
memory_order_relaxed)
|
|
|
|
|
|
|
|
#define PEER_TOTAL_TX(peer) \
|
|
|
|
atomic_load_explicit(&peer->open_out, memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->update_out, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->notify_out, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->refresh_out, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->keepalive_out, \
|
|
|
|
memory_order_relaxed) \
|
|
|
|
+ atomic_load_explicit(&peer->dynamic_cap_out, \
|
|
|
|
memory_order_relaxed)
|
2018-01-09 21:38:17 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Statistics field */
|
2018-03-06 20:02:52 +01:00
|
|
|
_Atomic uint32_t open_in; /* Open message input count */
|
|
|
|
_Atomic uint32_t open_out; /* Open message output count */
|
2017-07-05 17:38:57 +02:00
|
|
|
_Atomic uint32_t update_in; /* Update message input count */
|
|
|
|
_Atomic uint32_t update_out; /* Update message ouput count */
|
|
|
|
_Atomic time_t update_time; /* Update message received time. */
|
|
|
|
_Atomic uint32_t keepalive_in; /* Keepalive input count */
|
|
|
|
_Atomic uint32_t keepalive_out; /* Keepalive output count */
|
|
|
|
_Atomic uint32_t notify_in; /* Notify input count */
|
|
|
|
_Atomic uint32_t notify_out; /* Notify output count */
|
|
|
|
_Atomic uint32_t refresh_in; /* Route Refresh input count */
|
|
|
|
_Atomic uint32_t refresh_out; /* Route Refresh output count */
|
|
|
|
_Atomic uint32_t dynamic_cap_in; /* Dynamic Capability input count. */
|
2018-02-09 19:22:50 +01:00
|
|
|
_Atomic uint32_t dynamic_cap_out; /* Dynamic Capability output count. */
|
2017-07-17 14:03:14 +02:00
|
|
|
|
2019-04-24 21:40:50 +02:00
|
|
|
uint32_t stat_pfx_filter;
|
|
|
|
uint32_t stat_pfx_aspath_loop;
|
|
|
|
uint32_t stat_pfx_originator_loop;
|
|
|
|
uint32_t stat_pfx_cluster_loop;
|
|
|
|
uint32_t stat_pfx_nh_invalid;
|
|
|
|
uint32_t stat_pfx_dup_withdraw;
|
|
|
|
uint32_t stat_upd_7606; /* RFC7606: treat-as-withdraw */
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* BGP state count */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint32_t established; /* Established */
|
|
|
|
uint32_t dropped; /* Dropped */
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Update delay related fields */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t update_delay_over; /* When this is set, BGP is no more waiting
|
2017-07-17 14:03:14 +02:00
|
|
|
for EOR */
|
|
|
|
|
|
|
|
/* Syncronization list and time. */
|
|
|
|
struct bgp_synchronize *sync[AFI_MAX][SAFI_MAX];
|
|
|
|
time_t synctime;
|
2017-07-05 17:38:57 +02:00
|
|
|
/* timestamp when the last UPDATE msg was written */
|
|
|
|
_Atomic time_t last_write;
|
|
|
|
/* timestamp when the last msg was written */
|
|
|
|
_Atomic time_t last_update;
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Send prefix count. */
|
|
|
|
unsigned long scount[AFI_MAX][SAFI_MAX];
|
|
|
|
|
|
|
|
/* Notify data. */
|
|
|
|
struct bgp_notify notify;
|
|
|
|
|
|
|
|
/* Filter structure. */
|
|
|
|
struct bgp_filter filter[AFI_MAX][SAFI_MAX];
|
|
|
|
|
2018-05-21 12:09:25 +02:00
|
|
|
/*
|
|
|
|
* Parallel array to filter that indicates whether each filter
|
|
|
|
* originates from a peer-group or if it is config that is specific to
|
|
|
|
* this individual peer. If a filter is set independent of the
|
|
|
|
* peer-group the appropriate bit should be set here. If this peer is a
|
|
|
|
* peer-group, this memory region should be all zeros. The assumption
|
|
|
|
* is that the default state for all flags is unset. Due to filters
|
|
|
|
* having a direction (e.g. in/out/...), this array has a third
|
|
|
|
* dimension for storing the overrides independently per direction.
|
|
|
|
*
|
|
|
|
* Notes:
|
|
|
|
* - if a filter for an individual peer is unset, the corresponding
|
|
|
|
* override flag is unset and the peer is considered to be back in
|
|
|
|
* sync with the peer-group.
|
|
|
|
* - This does *not* contain the filter values, rather it contains
|
|
|
|
* whether the filter in filter (struct bgp_filter) is peer-specific.
|
|
|
|
*/
|
|
|
|
uint8_t filter_override[AFI_MAX][SAFI_MAX][(FILTER_MAX > RMAP_MAX)
|
|
|
|
? FILTER_MAX
|
|
|
|
: RMAP_MAX];
|
|
|
|
#define PEER_FT_DISTRIBUTE_LIST (1 << 0) /* distribute-list */
|
|
|
|
#define PEER_FT_FILTER_LIST (1 << 1) /* filter-list */
|
|
|
|
#define PEER_FT_PREFIX_LIST (1 << 2) /* prefix-list */
|
|
|
|
#define PEER_FT_ROUTE_MAP (1 << 3) /* route-map */
|
|
|
|
#define PEER_FT_UNSUPPRESS_MAP (1 << 4) /* unsuppress-map */
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* ORF Prefix-list */
|
|
|
|
struct prefix_list *orf_plist[AFI_MAX][SAFI_MAX];
|
|
|
|
|
|
|
|
/* Text description of last attribute rcvd */
|
|
|
|
char rcvd_attr_str[BUFSIZ];
|
|
|
|
|
|
|
|
/* Track if we printed the attribute in debugs */
|
|
|
|
int rcvd_attr_printed;
|
|
|
|
|
|
|
|
/* Prefix count. */
|
2019-10-03 23:30:28 +02:00
|
|
|
uint32_t pcount[AFI_MAX][SAFI_MAX];
|
2017-07-17 14:03:14 +02:00
|
|
|
|
|
|
|
/* Max prefix count. */
|
2019-10-03 23:30:28 +02:00
|
|
|
uint32_t pmax[AFI_MAX][SAFI_MAX];
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t pmax_threshold[AFI_MAX][SAFI_MAX];
|
|
|
|
uint16_t pmax_restart[AFI_MAX][SAFI_MAX];
|
2004-05-20 11:19:34 +02:00
|
|
|
#define MAXIMUM_PREFIX_THRESHOLD_DEFAULT 75
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* allowas-in. */
|
|
|
|
char allowas_in[AFI_MAX][SAFI_MAX];
|
2003-08-12 07:32:27 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* weight */
|
|
|
|
unsigned long weight[AFI_MAX][SAFI_MAX];
|
2016-10-10 16:53:34 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* peer reset cause */
|
2019-04-24 20:14:19 +02:00
|
|
|
uint8_t last_reset;
|
2004-05-20 11:19:34 +02:00
|
|
|
#define PEER_DOWN_RID_CHANGE 1 /* bgp router-id command */
|
|
|
|
#define PEER_DOWN_REMOTE_AS_CHANGE 2 /* neighbor remote-as command */
|
|
|
|
#define PEER_DOWN_LOCAL_AS_CHANGE 3 /* neighbor local-as command */
|
|
|
|
#define PEER_DOWN_CLID_CHANGE 4 /* bgp cluster-id command */
|
|
|
|
#define PEER_DOWN_CONFED_ID_CHANGE 5 /* bgp confederation identifier command */
|
|
|
|
#define PEER_DOWN_CONFED_PEER_CHANGE 6 /* bgp confederation peer command */
|
|
|
|
#define PEER_DOWN_RR_CLIENT_CHANGE 7 /* neighbor route-reflector-client command */
|
|
|
|
#define PEER_DOWN_RS_CLIENT_CHANGE 8 /* neighbor route-server-client command */
|
|
|
|
#define PEER_DOWN_UPDATE_SOURCE_CHANGE 9 /* neighbor update-source command */
|
|
|
|
#define PEER_DOWN_AF_ACTIVATE 10 /* neighbor activate command */
|
|
|
|
#define PEER_DOWN_USER_SHUTDOWN 11 /* neighbor shutdown command */
|
|
|
|
#define PEER_DOWN_USER_RESET 12 /* clear ip bgp command */
|
|
|
|
#define PEER_DOWN_NOTIFY_RECEIVED 13 /* notification received */
|
|
|
|
#define PEER_DOWN_NOTIFY_SEND 14 /* notification send */
|
|
|
|
#define PEER_DOWN_CLOSE_SESSION 15 /* tcp session close */
|
|
|
|
#define PEER_DOWN_NEIGHBOR_DELETE 16 /* neghbor delete */
|
|
|
|
#define PEER_DOWN_RMAP_BIND 17 /* neghbor peer-group command */
|
|
|
|
#define PEER_DOWN_RMAP_UNBIND 18 /* no neighbor peer-group command */
|
|
|
|
#define PEER_DOWN_CAPABILITY_CHANGE 19 /* neighbor capability command */
|
|
|
|
#define PEER_DOWN_PASSIVE_CHANGE 20 /* neighbor passive command */
|
|
|
|
#define PEER_DOWN_MULTIHOP_CHANGE 21 /* neighbor multihop command */
|
2005-02-02 15:40:33 +01:00
|
|
|
#define PEER_DOWN_NSF_CLOSE_SESSION 22 /* NSF tcp session close */
|
2015-07-22 21:35:37 +02:00
|
|
|
#define PEER_DOWN_V6ONLY_CHANGE 23 /* if-based peering v6only toggled */
|
2015-07-22 21:35:37 +02:00
|
|
|
#define PEER_DOWN_BFD_DOWN 24 /* BFD down */
|
2016-04-23 00:15:25 +02:00
|
|
|
#define PEER_DOWN_IF_DOWN 25 /* Interface down */
|
|
|
|
#define PEER_DOWN_NBR_ADDR_DEL 26 /* Peer address lost */
|
bgpd: Add a new command to only show failed peerings
In a data center, having 32-128 peers is not uncommon. In such a situation, to find a
peer that has failed and why is several commands. This hinders both the automatability of
failure detection and the ease/speed with which the reason can be found. To simplify this
process of catching a failure and its cause quicker, this patch does the following:
1. Created a new function, bgp_show_failed_summary to display the
failed summary output for JSON and vty
2. Created a new function to display the reset code/subcode. This is now used in the
failed summary code and in the show neighbors code
3. Added a new variable failedPeers in all the JSON outputs, including the vanilla
"show bgp summary" family. This lists the failed session count.
4. Display peer, dropped count, estd count, uptime and the reason for failure as the
output of "show bgp summary failed" family of commands
5. Added three resset codes for the case where we're waiting for NHT, waiting for peer
IPv6 addr, waiting for VRF to init.
This also counts the case where only one peer has advertised an AFI/SAFI.
The new command has the optional keyword "failed" added to the classical summary command.
The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As
we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr,
the output of that command will show a "waiting for NHT" etc. as the last reset reason.
This patch includes update to the documentation too.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
2019-08-31 18:24:49 +02:00
|
|
|
#define PEER_DOWN_WAITING_NHT 27 /* Waiting for NHT to resolve */
|
|
|
|
#define PEER_DOWN_NBR_ADDR 28 /* Waiting for peer IPv6 IP Addr */
|
|
|
|
#define PEER_DOWN_VRF_UNINIT 29 /* Associated VRF is not init yet */
|
2019-09-03 21:55:49 +02:00
|
|
|
#define PEER_DOWN_NOAFI_ACTIVATED 30 /* No AFI/SAFI activated for peer */
|
2019-11-09 19:24:34 +01:00
|
|
|
#define PEER_DOWN_AS_SETS_REJECT 31 /* Reject routes with AS_SET */
|
2019-04-24 20:14:19 +02:00
|
|
|
size_t last_reset_cause_size;
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t last_reset_cause[BGP_MAX_PACKET_SIZE];
|
2004-05-20 11:19:34 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* The kind of route-map Flags.*/
|
2019-09-24 14:24:10 +02:00
|
|
|
uint16_t rmap_type;
|
2003-08-12 07:32:27 +02:00
|
|
|
#define PEER_RMAP_TYPE_IN (1 << 0) /* neighbor route-map in */
|
|
|
|
#define PEER_RMAP_TYPE_OUT (1 << 1) /* neighbor route-map out */
|
|
|
|
#define PEER_RMAP_TYPE_NETWORK (1 << 2) /* network route-map */
|
|
|
|
#define PEER_RMAP_TYPE_REDISTRIBUTE (1 << 3) /* redistribute route-map */
|
|
|
|
#define PEER_RMAP_TYPE_DEFAULT (1 << 4) /* default-originate route-map */
|
|
|
|
#define PEER_RMAP_TYPE_NOSET (1 << 5) /* not allow to set commands */
|
2004-09-13 Jose Luis Rubio <jrubio@dit.upm.es>
(at Technical University of Madrid as part of Euro6ix Project)
Enhanced Route Server functionality and Route-Maps:
* bgpd/bgpd.h: Modified 'struct peer' and 'struct bgp_filter' to
support rs-clients. A 'struct bgp_table *rib' has been added to the
first (to mantain a separated RIB for each rs-client) and two new
route-maps have been added to the last (for import/export policies).
Added the following #defines: RMAP_{IN|OUT|IMPORT|EXPORT|MAX},
PEER_RMAP_TYPE_{IMPORT|EXPORT} and BGP_CLEAR_SOFT_RSCLIENT.
* bgpd/bgpd.c: Modified the functions that create/delete/etc peers in
order to consider the new fields included in 'struct peer' for
supporting rs-clients, i.e. the import/export route-maps and the
'struct bgp_table'.
* bgpd/bgp_route.{ch}: Modified several functions related with
receiving/sending announces in order to support the new Route Server
capabilities.
Function 'bgp_process' has been reorganized, creating an auxiliar
function for best path selection ('bgp_best_selection').
Modified 'bgp_show' and 'bgp_show_route' for displaying information
about any RIB (and not only the main bgp RIB).
Added commands for displaying information about RS-clients RIBs:
'show bgp rsclient (A.B.C.D|X:X::X:X)', 'show bgp rsclient
(A.B.C.D|X:X::X:X) X:X::X:X/M', etc
* bgpd/bgp_table.{ch}: The structure 'struct bgp_table' now has two
new fields: type (which can take the values BGP_TABLE_{MAIN|RSCLIENT})
and 'void *owner' which points to 'struct bgp' or 'struct peer' which
owns the table.
When creating a new bgp_table by default 'type=BGP_TABLE_MAIN' is set.
* bgpd/bgp_vty.c: The commands 'neighbor ... route-server-client' and
'no neighbor ... route-server-client' now not only set/unset the flag
PEER_FLAG_RSERVER_CLIENT, but they create/destroy the 'struct
bgp_table' of the peer. Special actions are taken for peer_groups.
Command 'neighbor ... route-map WORD (in|out)' now also supports two
new kinds of route-map: 'import' and 'export'.
Added commands 'clear bgp * rsclient', etc. These commands allow a new
kind of soft_reconfig which affects only the RIB of the specified
RS-client.
Added commands 'show bgp rsclient summary', etc which display a
summary of the rs-clients configured for the corresponding address
family.
* bgpd/bgp_routemap.c: A new match statement is available,
'match peer (A.B.C.D|X:X::X:X)'. This statement can only be used in
import/export route-maps, and it matches when the peer who announces
(when used in an import route-map) or is going to receive (when used
in an export route-map) the route is the same than the one specified
in the statement.
For peer-groups the statement matches if the specified peer is member
of the peer-group.
A special version of the command, 'match peer local', matches with
routes originated by the Route Server (defined with 'network ...',
redistributed routes and default-originate).
* lib/routemap.{ch}: Added a new clause 'call NAME' for use in
route-maps. It jumps into the specified route-map and when it returns
the first route-map ends if the called RM returns DENY_MATCH, or
continues in other case.
2004-09-13 07:12:46 +02:00
|
|
|
#define PEER_RMAP_TYPE_IMPORT (1 << 6) /* neighbor route-map import */
|
|
|
|
#define PEER_RMAP_TYPE_EXPORT (1 << 7) /* neighbor route-map export */
|
2019-08-21 17:16:05 +02:00
|
|
|
#define PEER_RMAP_TYPE_AGGREGATE (1 << 8) /* aggregate-address route-map */
|
2015-05-20 03:29:16 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* peer specific BFD information */
|
|
|
|
struct bfd_info *bfd_info;
|
2015-09-11 05:10:16 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* hostname and domainname advertised by host */
|
|
|
|
char *hostname;
|
|
|
|
char *domainname;
|
2016-12-07 12:25:24 +01:00
|
|
|
|
2019-10-29 20:29:09 +01:00
|
|
|
/* Sender side AS path loop detection. */
|
|
|
|
bool as_path_loop_detection;
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
QOBJ_FIELDS
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
2016-12-07 12:25:24 +01:00
|
|
|
DECLARE_QOBJ_TYPE(peer)
|
2002-12-13 21:15:29 +01:00
|
|
|
|
bgpd: Improve group overrides for AF flags
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-05-19 22:10:48 +02:00
|
|
|
/* Inherit peer attribute from peer-group. */
|
2018-06-12 17:09:49 +02:00
|
|
|
#define PEER_ATTR_INHERIT(peer, group, attr) \
|
|
|
|
((peer)->attr = (group)->conf->attr)
|
|
|
|
#define PEER_STR_ATTR_INHERIT(peer, group, attr, mt) \
|
bgpd: Improve group overrides for AF flags
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-05-19 22:10:48 +02:00
|
|
|
do { \
|
|
|
|
if ((peer)->attr) \
|
|
|
|
XFREE(mt, (peer)->attr); \
|
2018-06-12 17:09:49 +02:00
|
|
|
if ((group)->conf->attr) \
|
|
|
|
(peer)->attr = XSTRDUP(mt, (group)->conf->attr); \
|
bgpd: Improve group overrides for AF flags
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-05-19 22:10:48 +02:00
|
|
|
else \
|
|
|
|
(peer)->attr = NULL; \
|
|
|
|
} while (0)
|
2018-06-13 19:34:17 +02:00
|
|
|
#define PEER_SU_ATTR_INHERIT(peer, group, attr) \
|
|
|
|
do { \
|
|
|
|
if ((peer)->attr) \
|
|
|
|
sockunion_free((peer)->attr); \
|
|
|
|
if ((group)->conf->attr) \
|
|
|
|
(peer)->attr = sockunion_dup((group)->conf->attr); \
|
|
|
|
else \
|
|
|
|
(peer)->attr = NULL; \
|
|
|
|
} while (0)
|
bgpd: Improve group overrides for AF flags
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-05-19 22:10:48 +02:00
|
|
|
|
2016-02-12 21:18:28 +01:00
|
|
|
/* Check if suppress start/restart of sessions to peer. */
|
2017-07-17 14:03:14 +02:00
|
|
|
#define BGP_PEER_START_SUPPRESSED(P) \
|
|
|
|
(CHECK_FLAG((P)->flags, PEER_FLAG_SHUTDOWN) \
|
|
|
|
|| CHECK_FLAG((P)->sflags, PEER_STATUS_PREFIX_OVERFLOW))
|
2016-02-12 21:18:28 +01:00
|
|
|
|
[bgpd] TCP-MD5: password vty configuration and initial Linux support
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* bgp_packet.c: (bgp_open_receive) fix warning in a zlog call
* bgp_vty.c: (bgp_vty_return) add return code
* bgpd.c: (bgp_master_init) setup the socket list.
* bgp_network.c: Remove the dual IPv4/6 socket thing for now, which
was implemented by Michael, until such time as its clear its
required for Linux (see sockopt comments). IPv6 support, including
IPv4 sessions on AF_INET6 sockets, therefore is broken, and the
'-l 0.0.0.0' arguments would need to be given to bgpd to make
things work here.
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Tomohiko Kusuda <kusuda@inetcore.com>
Leigh Brown <leigh@solinno.co.uk>
* bgp_network.c: (bgp_md5_set_one) shim between libzebra tcp-md5
sockopt and bgpd.
(bgp_md5_set_socket) Helper for bgp_connect
(bgp_md5_set) setup TCP-MD5SIG for the given peer.
(bgp_connect) call out to bgp_md5_set_socket for the outgoing
connect socket.
(bgp_socket) save references to the listen sockets, needed if
TCP-MD5SIG is applied later or changed.
* bgp_vty.c: (*neighbor_password_cmd) New 'neighbor ... password'
commands.
* bgpd.c: (peer_{new,delete) manage TCP-MD5 password
(peer_group2peer_config_copy) inherit TCP-MD5 password
(peer_password_{un,}set) orchestrate the whole add/remove of TCP-MD5
passwords: applying checks, stopping peers, and trying to return
errors to UI, etc.
(bgp_config_write_peer) save password.
Fix missing newline in writeout of neighbor ... port.
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* sockunion.c: ifdef out various places that converted
v4mapped sockets to pure v4. Doesn't seem necessary at all,
presumably a workaround for now historical inet_ntop bugs (?)
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* sockopt.{c,h}: (sockopt_tcp_signature) Add TCP-MD5SIG support.
2008-07-21 23:02:49 +02:00
|
|
|
#define PEER_PASSWORD_MINLEN (1)
|
|
|
|
#define PEER_PASSWORD_MAXLEN (80)
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* This structure's member directly points incoming packet data
|
|
|
|
stream. */
|
2017-07-17 14:03:14 +02:00
|
|
|
struct bgp_nlri {
|
|
|
|
/* AFI. */
|
2017-08-01 02:37:46 +02:00
|
|
|
uint16_t afi; /* iana_afi_t */
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* SAFI. */
|
2017-08-01 02:37:46 +02:00
|
|
|
uint8_t safi; /* iana_safi_t */
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Pointer to NLRI byte stream. */
|
2018-03-27 21:13:34 +02:00
|
|
|
uint8_t *nlri;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
/* Length of whole NLRI. */
|
|
|
|
bgp_size_t length;
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* BGP versions. */
|
|
|
|
#define BGP_VERSION_4 4
|
|
|
|
|
|
|
|
/* Default BGP port number. */
|
|
|
|
#define BGP_PORT_DEFAULT 179
|
|
|
|
|
|
|
|
/* BGP minimum message size. */
|
|
|
|
#define BGP_MSG_OPEN_MIN_SIZE (BGP_HEADER_SIZE + 10)
|
|
|
|
#define BGP_MSG_UPDATE_MIN_SIZE (BGP_HEADER_SIZE + 4)
|
|
|
|
#define BGP_MSG_NOTIFY_MIN_SIZE (BGP_HEADER_SIZE + 2)
|
|
|
|
#define BGP_MSG_KEEPALIVE_MIN_SIZE (BGP_HEADER_SIZE + 0)
|
|
|
|
#define BGP_MSG_ROUTE_REFRESH_MIN_SIZE (BGP_HEADER_SIZE + 4)
|
|
|
|
#define BGP_MSG_CAPABILITY_MIN_SIZE (BGP_HEADER_SIZE + 3)
|
|
|
|
|
|
|
|
/* BGP message types. */
|
|
|
|
#define BGP_MSG_OPEN 1
|
|
|
|
#define BGP_MSG_UPDATE 2
|
|
|
|
#define BGP_MSG_NOTIFY 3
|
|
|
|
#define BGP_MSG_KEEPALIVE 4
|
|
|
|
#define BGP_MSG_ROUTE_REFRESH_NEW 5
|
|
|
|
#define BGP_MSG_CAPABILITY 6
|
|
|
|
#define BGP_MSG_ROUTE_REFRESH_OLD 128
|
|
|
|
|
|
|
|
/* BGP open optional parameter. */
|
|
|
|
#define BGP_OPEN_OPT_AUTH 1
|
|
|
|
#define BGP_OPEN_OPT_CAP 2
|
|
|
|
|
|
|
|
/* BGP4 attribute type codes. */
|
|
|
|
#define BGP_ATTR_ORIGIN 1
|
|
|
|
#define BGP_ATTR_AS_PATH 2
|
|
|
|
#define BGP_ATTR_NEXT_HOP 3
|
|
|
|
#define BGP_ATTR_MULTI_EXIT_DISC 4
|
|
|
|
#define BGP_ATTR_LOCAL_PREF 5
|
|
|
|
#define BGP_ATTR_ATOMIC_AGGREGATE 6
|
|
|
|
#define BGP_ATTR_AGGREGATOR 7
|
|
|
|
#define BGP_ATTR_COMMUNITIES 8
|
|
|
|
#define BGP_ATTR_ORIGINATOR_ID 9
|
|
|
|
#define BGP_ATTR_CLUSTER_LIST 10
|
|
|
|
#define BGP_ATTR_DPA 11
|
|
|
|
#define BGP_ATTR_ADVERTISER 12
|
|
|
|
#define BGP_ATTR_RCID_PATH 13
|
|
|
|
#define BGP_ATTR_MP_REACH_NLRI 14
|
|
|
|
#define BGP_ATTR_MP_UNREACH_NLRI 15
|
|
|
|
#define BGP_ATTR_EXT_COMMUNITIES 16
|
[bgpd] Merge AS4 support
2007-10-14 Paul Jakma <paul.jakma@sun.com>
* NEWS: Note that MRT dumps are now version 2
* (general) Merge in Juergen Kammer's AS4 patch.
2007-09-27 Paul Jakma <paul.jakma@sun.com>
* bgp_aspath.c: (assegment_normalise) remove duplicates from
from sets.
(aspath_reconcile_as4) disregard a broken part of the RFC around
error handling in path reconciliation.
* aspath_test.c: Test dupe-weeding from sets.
Test that reconciliation merges AS_PATH and AS4_PATH where
former is shorter than latter.
2007-09-26 Paul Jakma <paul.jakma@sun.com>
* aspath_test.c: Test AS4_PATH reconcilation where length
of AS_PATH and AS4_PATH is same.
2007-09-25 Paul Jakma <paul.jakma@sun.com>
* bgp_open.c: (peek_for_as4_capability) Fix to work.
* bgp_packet.c: (bgp_open_receive) Fix sanity check of as4.
* tests/bgp_capability_test.c: (general) Extend tests to validate
peek_for_as4_capability.
Add test of full OPEN Option block, with multiple capabilities,
both as a series of Option, and a single option.
Add some crap to beginning of stream, to prevent code depending
on getp == 0.
2007-09-18 Paul Jakma <paul.jakma@sun.com>
* bgp_open.c: (bgp_capability_as4) debug printf inline with others.
(peek_for_as4_capability) There's no need to signal failure, as
failure is better dealt with through full capability parser -
just return the AS4, simpler.
* bgp_packet.c: (bgp_open_receive) Update to match
peek_for_as4_capability change.
Allow use of BGP_AS_TRANS by 2b speakers.
Use NOTIFY_OPEN_ERR rather than CEASE for OPEN parsing errors.
(bgp_capability_msg_parse) missing argument to debug print
(bgp_capability_receive) missing return values.
* tests/bgp_capability_test.c: (parse_test) update for changes to
peek_for_as4_capability
2007-07-25 Paul Jakma <paul.jakma@sun.com>
* Remove 2-byte size macros, just make existing macros take
argument to indicate which size to use.
Adjust all users - typically they want '1'.
* bgp_aspath.c: (aspath_has_as4) New, return 1 if there are any
as4's in a path.
(aspath_put) Return the number of bytes actually written, to
fix the bug Juergen noted: Splitting of segments will change
the number of bytes written from that already written to the
AS_PATH header.
(aspath_snmp_pathseg) Pass 2-byte flag to aspath_put. SNMP
is still defined as 2b.
(aspath_aggregate) fix latent bug.
(aspath_reconcile_as4) AS_PATH+NEW_AS_PATH reconciliation
function.
(aspath_key_make) Hash the AS_PATH string, rather than
just taking the addition of assegment ASes as the hash value,
hopefully sligthly more collision resistant.
(bgp_attr_munge_as4_attrs) Collide the NEW_ attributes
together with the OLD 2-byte forms, code Juergen
had in bgp_attr_parse but re-organised a bit.
(bgp_attr_parse) Bunch of code from Juergen moves
to previous function.
(bgp_packet_attribute) Compact significantly by
just /always/ using extended-length attr header.
Fix bug Juergen noted, by using aspath_put's
(new) returned size value for the attr header rather
than the (guesstimate) of aspath_size() - the two could
differ when aspath_put had to split large segments, unlikely
this bug was ever hit in the 'wild'.
(bgp_dump_routes_attr) Always use extended-len and
use aspath_put return for header length. Output 4b ASN
for AS_PATH and AGGREGATOR.
* bgp_ecommunity.c: (ecommunity_{hash_make,cmp}) fix
hash callback declarations to match prototypes.
(ecommunity_gettoken) Updated for ECOMMUNITY_ENCODE_AS4,
complete rewrite of Juergen's changes (no asdot support)
* bgp_open.c: (bgp_capability_as4) New, does what it says
on the tin.
(peek_for_as4_capability) Rewritten to use streams and
bgp_capability_as4.
* bgp_packet.c: (bgp_open_send) minor edit
checked (in the abstract at least) with Juergen.
Changes are to be more accepting, e.g, allow AS_TRANS on
a 2-byte session.
* (general) Update all commands to use CMD_AS_RANGE.
* bgp_vty.c: (bgp_clear) Fix return vals to use CMD_..
Remove stuff replicated by VTY_GET_LONG
(bgp_clear_vty) Return bgp_clear directly to vty.
* tests/aspath_test.c: Exercise 32bit parsing. Test reconcile
function.
* tests/ecommunity_test.c: New, test AS4 ecommunity changes,
positive test only at this time, error cases not tested yet.
2007-07-25 Juergen Kammer <j.kammer@eurodata.de>
* (general) AS4 support.
* bgpd.h: as_t changes to 4-bytes.
* bgp_aspath.h: Add BGP_AS4_MAX and BGP_AS_TRANS defines.
* bgp_aspath.c: AS_VALUE_SIZE becomes 4-byte, AS16_VALUE_SIZE
added for 2-byte.
Add AS16 versions of length calc macros.
(aspath_count_numas) New, count number of ASes.
(aspath_has_as4) New, return 1 if there are any as4's in a
path.
(assegments_parse) Interpret assegment as 4 or 2 byte,
according to how the caller instructs us, with a new
argument.
(aspath_parse) Add use32bit argument to pass to
assegments_parse. Adjust all its callers to pass 1, unless
otherwise noted.
(assegment_data_put) Adjust to be able to write 2 or 4 byte
AS, according to new use32bit argument.
(aspath_put) Adjust to write 2 or 4.
(aspath_gettoken) Use a long for passed in asno.
* bgp_attr.c: (attr_str) Add BGP_ATTR_AS4_PATH and
BGP_ATTR_AS4_AGGREGATOR.
(bgp_attr_aspath) Call aspath_parse with right 2/4 arg, as
determined by received-capability flag.
(bgp_attr_aspath_check) New, code previously in attr_aspath
but moved to new func so it can be run after NEW_AS_PATH
reconciliation.
(bgp_attr_as4_path) New, handle NEW_AS_PATH.
(bgp_attr_aggregator) Adjust to cope with 2/4 byte ASes.
(bgp_attr_as4_aggregator) New, read NEW_AGGREGATOR.
(bgp_attr_parse) Add handoffs to previous parsers for the two
new AS4 NEW_ attributes.
Various checks added for NEW/OLD reconciliation.
(bgp_packet_attribute) Support 2/4 for AS_PATH and
AGGREGATOR, detect when NEW_ attrs need to be sent.
* bgp_debug.{c,h}: Add 'debug bgp as4'.
* bgp_dump.c: MRTv2 support, unconditionally enabled, which
supports AS4. Based on patches from Erik (RIPE?).
* bgp_ecommunity.c: (ecommunity_ecom2str) ECOMMUNITY_ENCODE_AS4
support.
* bgp_open.c: (peek_for_as4_capability) New, peek for AS4
capability prior to full capability parsing, so we know which
ASN to use for struct peer lookup.
(bgp_open_capability) Always send AS4 capability.
* bgp_packet.c: (bgp_open_send) AS4 handling for AS field
(bgp_open_receive) Peek for AS4 capability first, and figure
out which AS to believe.
* bgp_vty.c: (bgp_show_peer) Print AS4 cap
* tests/aspath_test.c: Support asn32 changes, call aspath_parse
with 16 bit.
* vtysh/extract.pl: AS4 compatibility for router bgp ASNUMBER
* vtysh/extract.pl.in: AS4 compatibility for router bgp ASNUMBER
* vtysh/vtysh.c: AS4 compatibility for router bgp ASNUMBER
2007-10-15 00:32:21 +02:00
|
|
|
#define BGP_ATTR_AS4_PATH 17
|
|
|
|
#define BGP_ATTR_AS4_AGGREGATOR 18
|
2007-08-06 17:24:51 +02:00
|
|
|
#define BGP_ATTR_AS_PATHLIMIT 21
|
2018-01-04 12:34:24 +01:00
|
|
|
#define BGP_ATTR_PMSI_TUNNEL 22
|
2016-01-12 19:42:01 +01:00
|
|
|
#define BGP_ATTR_ENCAP 23
|
2016-11-15 11:00:39 +01:00
|
|
|
#define BGP_ATTR_LARGE_COMMUNITIES 32
|
2017-04-26 23:45:32 +02:00
|
|
|
#define BGP_ATTR_PREFIX_SID 40
|
2019-01-07 17:32:54 +01:00
|
|
|
#if ENABLE_BGP_VNC_ATTR
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
#define BGP_ATTR_VNC 255
|
|
|
|
#endif
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP update origin. */
|
|
|
|
#define BGP_ORIGIN_IGP 0
|
|
|
|
#define BGP_ORIGIN_EGP 1
|
|
|
|
#define BGP_ORIGIN_INCOMPLETE 2
|
|
|
|
|
|
|
|
/* BGP notify message codes. */
|
|
|
|
#define BGP_NOTIFY_HEADER_ERR 1
|
|
|
|
#define BGP_NOTIFY_OPEN_ERR 2
|
|
|
|
#define BGP_NOTIFY_UPDATE_ERR 3
|
|
|
|
#define BGP_NOTIFY_HOLD_ERR 4
|
|
|
|
#define BGP_NOTIFY_FSM_ERR 5
|
|
|
|
#define BGP_NOTIFY_CEASE 6
|
|
|
|
#define BGP_NOTIFY_CAPABILITY_ERR 7
|
|
|
|
|
2011-09-21 21:13:22 +02:00
|
|
|
#define BGP_NOTIFY_SUBCODE_UNSPECIFIC 0
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP_NOTIFY_HEADER_ERR sub codes. */
|
|
|
|
#define BGP_NOTIFY_HEADER_NOT_SYNC 1
|
|
|
|
#define BGP_NOTIFY_HEADER_BAD_MESLEN 2
|
|
|
|
#define BGP_NOTIFY_HEADER_BAD_MESTYPE 3
|
|
|
|
|
|
|
|
/* BGP_NOTIFY_OPEN_ERR sub codes. */
|
2015-07-22 21:35:38 +02:00
|
|
|
#define BGP_NOTIFY_OPEN_MALFORMED_ATTR 0
|
2002-12-13 21:15:29 +01:00
|
|
|
#define BGP_NOTIFY_OPEN_UNSUP_VERSION 1
|
|
|
|
#define BGP_NOTIFY_OPEN_BAD_PEER_AS 2
|
|
|
|
#define BGP_NOTIFY_OPEN_BAD_BGP_IDENT 3
|
|
|
|
#define BGP_NOTIFY_OPEN_UNSUP_PARAM 4
|
|
|
|
#define BGP_NOTIFY_OPEN_AUTH_FAILURE 5
|
|
|
|
#define BGP_NOTIFY_OPEN_UNACEP_HOLDTIME 6
|
|
|
|
#define BGP_NOTIFY_OPEN_UNSUP_CAPBL 7
|
|
|
|
|
|
|
|
/* BGP_NOTIFY_UPDATE_ERR sub codes. */
|
|
|
|
#define BGP_NOTIFY_UPDATE_MAL_ATTR 1
|
|
|
|
#define BGP_NOTIFY_UPDATE_UNREC_ATTR 2
|
|
|
|
#define BGP_NOTIFY_UPDATE_MISS_ATTR 3
|
|
|
|
#define BGP_NOTIFY_UPDATE_ATTR_FLAG_ERR 4
|
|
|
|
#define BGP_NOTIFY_UPDATE_ATTR_LENG_ERR 5
|
|
|
|
#define BGP_NOTIFY_UPDATE_INVAL_ORIGIN 6
|
|
|
|
#define BGP_NOTIFY_UPDATE_AS_ROUTE_LOOP 7
|
|
|
|
#define BGP_NOTIFY_UPDATE_INVAL_NEXT_HOP 8
|
|
|
|
#define BGP_NOTIFY_UPDATE_OPT_ATTR_ERR 9
|
|
|
|
#define BGP_NOTIFY_UPDATE_INVAL_NETWORK 10
|
|
|
|
#define BGP_NOTIFY_UPDATE_MAL_AS_PATH 11
|
|
|
|
|
2011-09-21 21:13:22 +02:00
|
|
|
/* BGP_NOTIFY_CEASE sub codes (RFC 4486). */
|
2002-12-13 21:15:29 +01:00
|
|
|
#define BGP_NOTIFY_CEASE_MAX_PREFIX 1
|
|
|
|
#define BGP_NOTIFY_CEASE_ADMIN_SHUTDOWN 2
|
|
|
|
#define BGP_NOTIFY_CEASE_PEER_UNCONFIG 3
|
|
|
|
#define BGP_NOTIFY_CEASE_ADMIN_RESET 4
|
|
|
|
#define BGP_NOTIFY_CEASE_CONNECT_REJECT 5
|
|
|
|
#define BGP_NOTIFY_CEASE_CONFIG_CHANGE 6
|
2004-04-20 17:13:15 +02:00
|
|
|
#define BGP_NOTIFY_CEASE_COLLISION_RESOLUTION 7
|
|
|
|
#define BGP_NOTIFY_CEASE_OUT_OF_RESOURCE 8
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP_NOTIFY_CAPABILITY_ERR sub codes (draft-ietf-idr-dynamic-cap-02). */
|
|
|
|
#define BGP_NOTIFY_CAPABILITY_INVALID_ACTION 1
|
|
|
|
#define BGP_NOTIFY_CAPABILITY_INVALID_LENGTH 2
|
|
|
|
#define BGP_NOTIFY_CAPABILITY_MALFORMED_CODE 3
|
|
|
|
|
|
|
|
/* BGP finite state machine status. */
|
|
|
|
#define Idle 1
|
|
|
|
#define Connect 2
|
|
|
|
#define Active 3
|
|
|
|
#define OpenSent 4
|
|
|
|
#define OpenConfirm 5
|
|
|
|
#define Established 6
|
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states
2006-09-14 Paul Jakma <paul.jakma@sun.com>
* (general) Fix some niggly issues around 'shutdown' and clearing
by adding a Clearing FSM wait-state and a hidden 'Deleted'
FSM state, to allow deleted peers to 'cool off' and hit 0
references. This introduces a slow memory leak of struct peer,
however that's more a testament to the fragility of the
reference counting than a bug in this patch, cleanup of
reference counting to fix this is to follow.
* bgpd.h: Add Clearing, Deleted states and Clearing_Completed
and event.
* bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and
Deleted.
* bgp_fsm.h: Don't allow timer/event threads to set anything
for Deleted peers.
* bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted
needs to stop everything.
(bgp_stop) Remove explicit fsm_change_status call, the
general framework handles the transition.
(bgp_start) Log a warning if a start is attempted on a peer
that should stay down, trying to start a peer.
(struct .. FSM) Add Clearing_Completed
events, has little influence except when in state
Clearing to signal wait-state can end.
Add Clearing and Deleted states, former is a wait-state,
latter is a placeholder state to allow peers to disappear
quietly once refcounts settle.
(bgp_event) Try reduce verbosity of FSM state-change debug,
changes to same state are not interesting (Established->Established)
Allow NULL action functions in FSM.
* bgp_packet.c: (bgp_write) Use FSM events, rather than trying
to twiddle directly with FSM state behind the back of FSM.
(bgp_write_notify) ditto.
(bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else
this patch crashes, now it leaks instead.
* bgp_route.c: (bgp_clear_node_complete) Clearing_Completed
event, to end clearing.
(bgp_clear_route) See extensive comments.
* bgpd.c: (peer_free) should only be called while in Deleted,
peer refcounting controls when peer_free is called.
bgp_sync_delete should be here, not in peer_delete.
(peer_delete) Initiate delete.
Transition to Deleted state manually.
When removing peer from indices that provide visibility of it,
take great care to be idempotent wrt the reference counting
of struct peer through those indices.
Use bgp_timer_set, rather than replicating.
Call to bgp_sync_delete isn't appropriate here, sync can be
referenced while shutting down and finishing deletion.
(peer_group_bind) Take care to be idempotent wrt list references
indexing peers.
2006-09-14 04:58:49 +02:00
|
|
|
#define Clearing 7
|
|
|
|
#define Deleted 8
|
|
|
|
#define BGP_STATUS_MAX 9
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP finite state machine events. */
|
|
|
|
#define BGP_Start 1
|
|
|
|
#define BGP_Stop 2
|
|
|
|
#define TCP_connection_open 3
|
|
|
|
#define TCP_connection_closed 4
|
|
|
|
#define TCP_connection_open_failed 5
|
|
|
|
#define TCP_fatal_error 6
|
|
|
|
#define ConnectRetry_timer_expired 7
|
|
|
|
#define Hold_Timer_expired 8
|
|
|
|
#define KeepAlive_timer_expired 9
|
|
|
|
#define Receive_OPEN_message 10
|
|
|
|
#define Receive_KEEPALIVE_message 11
|
|
|
|
#define Receive_UPDATE_message 12
|
|
|
|
#define Receive_NOTIFICATION_message 13
|
[bgpd] Fix 0.99 shutdown regression, introduce Clearing and Deleted states
2006-09-14 Paul Jakma <paul.jakma@sun.com>
* (general) Fix some niggly issues around 'shutdown' and clearing
by adding a Clearing FSM wait-state and a hidden 'Deleted'
FSM state, to allow deleted peers to 'cool off' and hit 0
references. This introduces a slow memory leak of struct peer,
however that's more a testament to the fragility of the
reference counting than a bug in this patch, cleanup of
reference counting to fix this is to follow.
* bgpd.h: Add Clearing, Deleted states and Clearing_Completed
and event.
* bgp_debug.c: (bgp_status_msg[]) Add strings for Clearing and
Deleted.
* bgp_fsm.h: Don't allow timer/event threads to set anything
for Deleted peers.
* bgp_fsm.c: (bgp_timer_set) Add Clearing and Deleted. Deleted
needs to stop everything.
(bgp_stop) Remove explicit fsm_change_status call, the
general framework handles the transition.
(bgp_start) Log a warning if a start is attempted on a peer
that should stay down, trying to start a peer.
(struct .. FSM) Add Clearing_Completed
events, has little influence except when in state
Clearing to signal wait-state can end.
Add Clearing and Deleted states, former is a wait-state,
latter is a placeholder state to allow peers to disappear
quietly once refcounts settle.
(bgp_event) Try reduce verbosity of FSM state-change debug,
changes to same state are not interesting (Established->Established)
Allow NULL action functions in FSM.
* bgp_packet.c: (bgp_write) Use FSM events, rather than trying
to twiddle directly with FSM state behind the back of FSM.
(bgp_write_notify) ditto.
(bgp_read) Remove the vague ACCEPT_PEER peer_unlock, or else
this patch crashes, now it leaks instead.
* bgp_route.c: (bgp_clear_node_complete) Clearing_Completed
event, to end clearing.
(bgp_clear_route) See extensive comments.
* bgpd.c: (peer_free) should only be called while in Deleted,
peer refcounting controls when peer_free is called.
bgp_sync_delete should be here, not in peer_delete.
(peer_delete) Initiate delete.
Transition to Deleted state manually.
When removing peer from indices that provide visibility of it,
take great care to be idempotent wrt the reference counting
of struct peer through those indices.
Use bgp_timer_set, rather than replicating.
Call to bgp_sync_delete isn't appropriate here, sync can be
referenced while shutting down and finishing deletion.
(peer_group_bind) Take care to be idempotent wrt list references
indexing peers.
2006-09-14 04:58:49 +02:00
|
|
|
#define Clearing_Completed 14
|
|
|
|
#define BGP_EVENTS_MAX 15
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP timers default value. */
|
2015-05-20 02:40:42 +02:00
|
|
|
#define BGP_INIT_START_TIMER 1
|
2019-08-01 18:50:56 +02:00
|
|
|
/* The following 3 are RFC defaults that are overridden in bgp_vty.c with
|
|
|
|
* version-/profile-specific values. The values here do not matter, they only
|
|
|
|
* exist to provide a clear layering separation between core and CLI.
|
|
|
|
*/
|
|
|
|
#define BGP_DEFAULT_HOLDTIME 180
|
|
|
|
#define BGP_DEFAULT_KEEPALIVE 60
|
|
|
|
#define BGP_DEFAULT_CONNECT_RETRY 120
|
|
|
|
|
2015-10-20 23:51:00 +02:00
|
|
|
#define BGP_DEFAULT_EBGP_ROUTEADV 0
|
2015-10-20 23:50:03 +02:00
|
|
|
#define BGP_DEFAULT_IBGP_ROUTEADV 0
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP default local preference. */
|
|
|
|
#define BGP_DEFAULT_LOCAL_PREF 100
|
|
|
|
|
2017-08-25 20:27:49 +02:00
|
|
|
/* BGP local-preference to send when 'bgp graceful-shutdown'
|
|
|
|
* is configured */
|
|
|
|
#define BGP_GSHUT_LOCAL_PREF 0
|
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
/* BGP default subgroup packet queue max . */
|
|
|
|
#define BGP_DEFAULT_SUBGROUP_PKT_QUEUE_MAX 40
|
|
|
|
|
2004-05-21 11:31:30 +02:00
|
|
|
/* BGP graceful restart */
|
|
|
|
#define BGP_DEFAULT_RESTART_TIME 120
|
|
|
|
#define BGP_DEFAULT_STALEPATH_TIME 360
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* BGP uptime string length. */
|
|
|
|
#define BGP_UPTIME_LEN 25
|
|
|
|
|
|
|
|
/* Default configuration settings for bgpd. */
|
|
|
|
#define BGP_VTY_PORT 2605
|
|
|
|
#define BGP_DEFAULT_CONFIG "bgpd.conf"
|
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
/* BGP Dynamic Neighbors feature */
|
|
|
|
#define BGP_DYNAMIC_NEIGHBORS_LIMIT_DEFAULT 100
|
|
|
|
#define BGP_DYNAMIC_NEIGHBORS_LIMIT_MIN 1
|
|
|
|
#define BGP_DYNAMIC_NEIGHBORS_LIMIT_MAX 5000
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
/* Flag for peer_clear_soft(). */
|
2017-07-17 14:03:14 +02:00
|
|
|
enum bgp_clear_type {
|
|
|
|
BGP_CLEAR_SOFT_NONE,
|
|
|
|
BGP_CLEAR_SOFT_OUT,
|
|
|
|
BGP_CLEAR_SOFT_IN,
|
|
|
|
BGP_CLEAR_SOFT_BOTH,
|
|
|
|
BGP_CLEAR_SOFT_IN_ORF_PREFIX
|
2002-12-13 21:15:29 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Macros. */
|
2017-05-02 02:37:45 +02:00
|
|
|
#define BGP_INPUT(P) ((P)->curr)
|
2017-11-08 18:51:16 +01:00
|
|
|
#define BGP_INPUT_PNT(P) (stream_pnt(BGP_INPUT(P)))
|
2017-07-17 14:03:14 +02:00
|
|
|
#define BGP_IS_VALID_STATE_FOR_NOTIF(S) \
|
|
|
|
(((S) == OpenSent) || ((S) == OpenConfirm) || ((S) == Established))
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* BGP error codes. */
|
|
|
|
#define BGP_SUCCESS 0
|
2019-08-01 18:50:56 +02:00
|
|
|
#define BGP_CREATED 1
|
2002-12-13 21:15:29 +01:00
|
|
|
#define BGP_ERR_INVALID_VALUE -1
|
|
|
|
#define BGP_ERR_INVALID_FLAG -2
|
|
|
|
#define BGP_ERR_INVALID_AS -3
|
|
|
|
#define BGP_ERR_INVALID_BGP -4
|
|
|
|
#define BGP_ERR_PEER_GROUP_MEMBER -5
|
BGP: Remove the requirement to rebind a peer to its peer-group under the address-family.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-3868
NOTE: Many of the ibgp peers are not up in the 'show ip bgp summ' output below. This
is because ospf was disabled at the time. The main thing to look for is whether or
not all of the correct peers are listed based on their 'activate' status.
Basic Example
=============
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP activate
neighbor IBGP next-hop-self
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r2(10.0.0.2) 4 10 107 211 0 0 0 00:23:01 Connect
r3(10.0.0.3) 4 10 107 211 0 0 0 00:23:01 Connect
r4(10.0.0.4) 4 10 207 211 0 0 0 00:23:01 Active
r6(20.1.1.6) 4 20 873 975 0 0 0 00:23:29 600
r7(20.1.1.7) 4 20 873 976 0 0 0 00:23:29 600
r8(40.1.1.2) 4 40 874 975 0 0 0 00:23:30 600
r9(40.1.1.6) 4 40 874 975 0 0 0 00:23:30 600
r10(40.1.1.10) 4 40 874 975 0 0 0 00:23:30 600
Total number of neighbors 8
superm-redxp-05#
Example where one member of the peer-group is inactive...we can do this now that
peer-group members can have different outbound policies from the peer-group.
================================================================================
superm-redxp-05# conf t
superm-redxp-05(config)# router bgp 10
superm-redxp-05(config-router)# address-family ipv4 unicast
superm-redxp-05(config-router-af)# no neighbor 10.0.0.3 activate
superm-redxp-05(config-router-af)# do show run
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP activate
neighbor IBGP next-hop-self
no neighbor 10.0.0.3 activate
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r2(10.0.0.2) 4 10 107 211 0 0 0 00:23:24 Connect
r4(10.0.0.4) 4 10 207 211 0 0 0 00:23:24 Active
r6(20.1.1.6) 4 20 881 983 0 0 0 00:23:52 600
r7(20.1.1.7) 4 20 881 984 0 0 0 00:23:52 600
r8(40.1.1.2) 4 40 881 982 0 0 0 00:23:53 600
r9(40.1.1.6) 4 40 881 982 0 0 0 00:23:53 600
r10(40.1.1.10) 4 40 881 982 0 0 0 00:23:53 600
Total number of neighbors 7
superm-redxp-05#
Example where the peer-group is inactive but a member of the peer-group is active:
==================================================================================
superm-redxp-05(config)# router bgp 10
superm-redxp-05(config-router)# address-family ipv4 unicast
superm-redxp-05(config-router-af)# neighbor 10.0.0.3 activate
superm-redxp-05(config-router-af)# no neighbor IBGP activate
superm-redxp-05(config-router-af)#
superm-redxp-05(config-router-af)# neighbor 10.0.0.4 activate
superm-redxp-05(config-router-af)# end
superm-redxp-05# show run
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP next-hop-self
neighbor 10.0.0.4 activate
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r4(10.0.0.4) 4 10 207 211 0 0 0 00:24:56 Active
r6(20.1.1.6) 4 20 911 1013 0 0 0 00:25:24 600
r7(20.1.1.7) 4 20 911 1014 0 0 0 00:25:24 600
r8(40.1.1.2) 4 40 912 1013 0 0 0 00:25:25 600
r9(40.1.1.6) 4 40 912 1013 0 0 0 00:25:25 600
r10(40.1.1.10) 4 40 912 1013 0 0 0 00:25:25 600
Total number of neighbors 6
superm-redxp-05#
2015-11-20 19:53:50 +01:00
|
|
|
#define BGP_ERR_PEER_GROUP_NO_REMOTE_AS -7
|
|
|
|
#define BGP_ERR_PEER_GROUP_CANT_CHANGE -8
|
|
|
|
#define BGP_ERR_PEER_GROUP_MISMATCH -9
|
|
|
|
#define BGP_ERR_PEER_GROUP_PEER_TYPE_DIFFERENT -10
|
|
|
|
#define BGP_ERR_AS_MISMATCH -12
|
|
|
|
#define BGP_ERR_PEER_FLAG_CONFLICT -13
|
|
|
|
#define BGP_ERR_PEER_GROUP_SHUTDOWN -14
|
|
|
|
#define BGP_ERR_PEER_FILTER_CONFLICT -15
|
|
|
|
#define BGP_ERR_NOT_INTERNAL_PEER -16
|
|
|
|
#define BGP_ERR_REMOVE_PRIVATE_AS -17
|
|
|
|
#define BGP_ERR_AF_UNCONFIGURED -18
|
|
|
|
#define BGP_ERR_SOFT_RECONFIG_UNCONFIGURED -19
|
|
|
|
#define BGP_ERR_INSTANCE_MISMATCH -20
|
|
|
|
#define BGP_ERR_LOCAL_AS_ALLOWED_ONLY_FOR_EBGP -21
|
|
|
|
#define BGP_ERR_CANNOT_HAVE_LOCAL_AS_SAME_AS -22
|
|
|
|
#define BGP_ERR_TCPSIG_FAILED -23
|
|
|
|
#define BGP_ERR_NO_EBGP_MULTIHOP_WITH_TTLHACK -24
|
|
|
|
#define BGP_ERR_NO_IBGP_WITH_TTLHACK -25
|
|
|
|
#define BGP_ERR_NO_INTERFACE_CONFIG -26
|
|
|
|
#define BGP_ERR_CANNOT_HAVE_LOCAL_AS_SAME_AS_REMOTE_AS -27
|
|
|
|
#define BGP_ERR_AS_OVERRIDE -28
|
|
|
|
#define BGP_ERR_INVALID_DYNAMIC_NEIGHBORS_LIMIT -29
|
|
|
|
#define BGP_ERR_DYNAMIC_NEIGHBORS_RANGE_EXISTS -30
|
|
|
|
#define BGP_ERR_DYNAMIC_NEIGHBORS_RANGE_NOT_FOUND -31
|
|
|
|
#define BGP_ERR_INVALID_FOR_DYNAMIC_PEER -32
|
|
|
|
#define BGP_ERR_MAX -33
|
2016-07-12 23:13:24 +02:00
|
|
|
#define BGP_ERR_INVALID_FOR_DIRECT_PEER -34
|
2017-06-16 21:12:57 +02:00
|
|
|
#define BGP_ERR_PEER_SAFI_CONFLICT -35
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
/*
|
|
|
|
* Enumeration of different policy kinds a peer can be configured with.
|
|
|
|
*/
|
2017-07-17 14:03:14 +02:00
|
|
|
typedef enum {
|
|
|
|
BGP_POLICY_ROUTE_MAP,
|
|
|
|
BGP_POLICY_FILTER_LIST,
|
|
|
|
BGP_POLICY_PREFIX_LIST,
|
|
|
|
BGP_POLICY_DISTRIBUTE_LIST,
|
2015-05-20 03:03:47 +02:00
|
|
|
} bgp_policy_type_e;
|
|
|
|
|
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_flag_change_type. */
|
|
|
|
enum peer_change_type {
|
|
|
|
peer_change_none,
|
|
|
|
peer_change_reset,
|
|
|
|
peer_change_reset_in,
|
|
|
|
peer_change_reset_out,
|
|
|
|
};
|
|
|
|
|
2002-12-13 21:15:29 +01:00
|
|
|
extern struct bgp_master *bm;
|
2016-11-04 00:59:19 +01:00
|
|
|
extern unsigned int multipath_num;
|
2002-12-13 21:15:29 +01:00
|
|
|
|
|
|
|
/* Prototypes. */
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void bgp_terminate(void);
|
|
|
|
extern void bgp_reset(void);
|
|
|
|
extern time_t bgp_clock(void);
|
|
|
|
extern void bgp_zclient_reset(void);
|
|
|
|
extern struct bgp *bgp_get_default(void);
|
|
|
|
extern struct bgp *bgp_lookup(as_t, const char *);
|
|
|
|
extern struct bgp *bgp_lookup_by_name(const char *);
|
|
|
|
extern struct bgp *bgp_lookup_by_vrf_id(vrf_id_t);
|
2019-03-06 19:09:25 +01:00
|
|
|
extern struct bgp *bgp_get_evpn(void);
|
|
|
|
extern void bgp_set_evpn(struct bgp *bgp);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern struct peer *peer_lookup(struct bgp *, union sockunion *);
|
|
|
|
extern struct peer *peer_lookup_by_conf_if(struct bgp *, const char *);
|
2015-09-11 05:10:16 +02:00
|
|
|
extern struct peer *peer_lookup_by_hostname(struct bgp *, const char *);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void bgp_peer_conf_if_to_su_update(struct peer *);
|
2015-05-20 03:12:17 +02:00
|
|
|
extern int peer_group_listen_range_del(struct peer_group *, struct prefix *);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern struct peer_group *peer_group_lookup(struct bgp *, const char *);
|
|
|
|
extern struct peer_group *peer_group_get(struct bgp *, const char *);
|
|
|
|
extern struct peer *peer_create_bind_dynamic_neighbor(struct bgp *,
|
|
|
|
union sockunion *,
|
|
|
|
struct peer_group *);
|
|
|
|
extern struct prefix *
|
|
|
|
peer_group_lookup_dynamic_neighbor_range(struct peer_group *, struct prefix *);
|
|
|
|
extern struct peer_group *peer_group_lookup_dynamic_neighbor(struct bgp *,
|
|
|
|
struct prefix *,
|
|
|
|
struct prefix **);
|
|
|
|
extern struct peer *peer_lookup_dynamic_neighbor(struct bgp *,
|
|
|
|
union sockunion *);
|
2015-07-22 21:35:38 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Peers are incredibly easy to memory leak
|
|
|
|
* due to the various ways that they are actually used
|
|
|
|
* Provide some functionality to debug locks and unlocks
|
|
|
|
*/
|
|
|
|
extern struct peer *peer_lock_with_caller(const char *, struct peer *);
|
|
|
|
extern struct peer *peer_unlock_with_caller(const char *, struct peer *);
|
|
|
|
#define peer_unlock(A) peer_unlock_with_caller(__FUNCTION__, (A))
|
|
|
|
#define peer_lock(B) peer_lock_with_caller(__FUNCTION__, (B))
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern bgp_peer_sort_t peer_sort(struct peer *peer);
|
|
|
|
extern int peer_active(struct peer *);
|
|
|
|
extern int peer_active_nego(struct peer *);
|
|
|
|
extern void bgp_recalculate_all_bestpaths(struct bgp *bgp);
|
2015-05-20 02:40:40 +02:00
|
|
|
extern struct peer *peer_create(union sockunion *, const char *, struct bgp *,
|
2017-07-17 14:03:14 +02:00
|
|
|
as_t, as_t, int, afi_t, safi_t,
|
|
|
|
struct peer_group *);
|
|
|
|
extern struct peer *peer_create_accept(struct bgp *);
|
|
|
|
extern void peer_xfer_config(struct peer *dst, struct peer *src);
|
2018-08-30 17:54:46 +02:00
|
|
|
extern char *peer_uptime(time_t uptime2, char *buf, size_t len, bool use_json,
|
|
|
|
json_object *json);
|
2015-08-12 15:59:18 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_config_write(struct vty *);
|
2014-06-04 06:53:35 +02:00
|
|
|
|
2019-10-04 20:33:01 +02:00
|
|
|
extern void bgp_master_init(struct thread_master *master,
|
|
|
|
const int buffer_size);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-06-07 15:28:12 +02:00
|
|
|
extern void bgp_init(unsigned short instance);
|
2017-03-29 21:16:28 +02:00
|
|
|
extern void bgp_pthreads_run(void);
|
2017-03-09 00:16:15 +01:00
|
|
|
extern void bgp_pthreads_finish(void);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void bgp_route_map_init(void);
|
|
|
|
extern void bgp_session_reset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_option_set(int);
|
|
|
|
extern int bgp_option_unset(int);
|
|
|
|
extern int bgp_option_check(int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_get(struct bgp **, as_t *, const char *, enum bgp_instance_type);
|
|
|
|
extern void bgp_instance_up(struct bgp *);
|
|
|
|
extern void bgp_instance_down(struct bgp *);
|
|
|
|
extern int bgp_delete(struct bgp *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-01-26 12:25:34 +01:00
|
|
|
extern int bgp_handle_socket(struct bgp *bgp, struct vrf *vrf,
|
|
|
|
vrf_id_t old_vrf_id, bool create);
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_flag_set(struct bgp *, int);
|
|
|
|
extern int bgp_flag_unset(struct bgp *, int);
|
|
|
|
extern int bgp_flag_check(struct bgp *, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void bgp_router_id_zebra_bump(vrf_id_t, const struct prefix *);
|
|
|
|
extern int bgp_router_id_static_set(struct bgp *, struct in_addr);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_cluster_id_set(struct bgp *, struct in_addr *);
|
|
|
|
extern int bgp_cluster_id_unset(struct bgp *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_confederation_id_set(struct bgp *, as_t);
|
|
|
|
extern int bgp_confederation_id_unset(struct bgp *);
|
|
|
|
extern int bgp_confederation_peers_check(struct bgp *, as_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_confederation_peers_add(struct bgp *, as_t);
|
|
|
|
extern int bgp_confederation_peers_remove(struct bgp *, as_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2019-08-01 18:50:56 +02:00
|
|
|
extern int bgp_timers_set(struct bgp *, uint32_t keepalive, uint32_t holdtime,
|
|
|
|
uint32_t connect_retry);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_timers_unset(struct bgp *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int bgp_default_local_preference_set(struct bgp *, uint32_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_default_local_preference_unset(struct bgp *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int bgp_default_subgroup_pkt_queue_max_set(struct bgp *bgp, uint32_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_default_subgroup_pkt_queue_max_unset(struct bgp *bgp);
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_listen_limit_set(struct bgp *, int);
|
|
|
|
extern int bgp_listen_limit_unset(struct bgp *);
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_update_delay_active(struct bgp *);
|
|
|
|
extern int bgp_update_delay_configured(struct bgp *);
|
2017-08-22 20:14:50 +02:00
|
|
|
extern int bgp_afi_safi_peer_exists(struct bgp *bgp, afi_t afi, safi_t safi);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void peer_as_change(struct peer *, as_t, int);
|
|
|
|
extern int peer_remote_as(struct bgp *, union sockunion *, const char *, as_t *,
|
|
|
|
int, afi_t, safi_t);
|
|
|
|
extern int peer_group_remote_as(struct bgp *, const char *, as_t *, int);
|
|
|
|
extern int peer_delete(struct peer *peer);
|
2019-11-05 13:33:31 +01:00
|
|
|
extern int peer_notify_unconfig(struct peer *peer);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_group_delete(struct peer_group *);
|
|
|
|
extern int peer_group_remote_as_delete(struct peer_group *);
|
2015-05-20 03:03:47 +02:00
|
|
|
extern int peer_group_listen_range_add(struct peer_group *, struct prefix *);
|
2019-11-05 13:33:31 +01:00
|
|
|
extern int peer_group_notify_unconfig(struct peer_group *group);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_activate(struct peer *, afi_t, safi_t);
|
|
|
|
extern int peer_deactivate(struct peer *, afi_t, safi_t);
|
|
|
|
extern int peer_afc_set(struct peer *, afi_t, safi_t, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_group_bind(struct bgp *, union sockunion *, struct peer *,
|
|
|
|
struct peer_group *, as_t *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_flag_set(struct peer *, uint32_t);
|
|
|
|
extern int peer_flag_unset(struct peer *, uint32_t);
|
bgpd: Implement group-overrides for peer flags
The current implementation of peer flags (e.g. shutdown, passive, ...)
only has partial support for overriding flags of a peer-group when the
peer is a member. Often settings might get lost if the user toys around
with the peer-group configuration, which can lead to disaster.
This commit introduces the same override implementation which was
previously integrated to support proper peer flag/attribute override on
the address-family level. The code is very similar and the global
attributes now use their separate state-arrays *flags_invert* and
*flags_override*.
The test suite for BGP peer attributes was extended to also check peer
global attributes, so that the newly introduced changes are covered. An
additional feature was added which allows to test an attribute with an
*interface-peer*, which can be configured by running `neighbor IF-TEST
interface`. This was introduced so that the dynamic runtime inversion of
the `extended-nexthop` flag, which is only enabled by default for
interface peers, can also be tested.
Last but not least, two small changes have been made to the current bgpd
implementation:
- The command `strict-capability-match` can now also be set on a
peer-group, it seems like this command slipped through while
implementing peer-groups in the very past.
- The macro `COND_FLAG` was introduced inside lib/zebra.h, which now
allows to either set or unset a flag based on a condition. The syntax
for using this macro is: `COND_FLAG(flag_variable, flag, condition)`
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
2018-06-11 19:49:20 +02:00
|
|
|
extern void peer_flag_inherit(struct peer *peer, uint32_t flag);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_af_flag_set(struct peer *, afi_t, safi_t, uint32_t);
|
|
|
|
extern int peer_af_flag_unset(struct peer *, afi_t, safi_t, uint32_t);
|
|
|
|
extern int peer_af_flag_check(struct peer *, afi_t, safi_t, uint32_t);
|
2018-05-27 19:36:48 +02:00
|
|
|
extern void peer_af_flag_inherit(struct peer *peer, afi_t afi, safi_t safi,
|
|
|
|
uint32_t flag);
|
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
|
|
|
extern void peer_change_action(struct peer *peer, afi_t afi, safi_t safi,
|
|
|
|
enum peer_change_type type);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_ebgp_multihop_set(struct peer *, int);
|
|
|
|
extern int peer_ebgp_multihop_unset(struct peer *);
|
|
|
|
extern int is_ebgp_multihop_configured(struct peer *peer);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_description_set(struct peer *, const char *);
|
|
|
|
extern int peer_description_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_update_source_if_set(struct peer *, const char *);
|
|
|
|
extern int peer_update_source_addr_set(struct peer *, const union sockunion *);
|
|
|
|
extern int peer_update_source_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-09-14 10:56:46 +02:00
|
|
|
extern int peer_default_originate_set(struct peer *peer, afi_t afi, safi_t safi,
|
|
|
|
const char *rmap,
|
|
|
|
struct route_map *route_map);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_default_originate_unset(struct peer *, afi_t, safi_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_port_set(struct peer *, uint16_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_port_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_weight_set(struct peer *, afi_t, safi_t, uint16_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_weight_unset(struct peer *, afi_t, safi_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_timers_set(struct peer *, uint32_t keepalive,
|
|
|
|
uint32_t holdtime);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_timers_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_timers_connect_set(struct peer *, uint32_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_timers_connect_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_advertise_interval_set(struct peer *, uint32_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_advertise_interval_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern void peer_interface_set(struct peer *, const char *);
|
|
|
|
extern void peer_interface_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_distribute_set(struct peer *, afi_t, safi_t, int, const char *);
|
|
|
|
extern int peer_distribute_unset(struct peer *, afi_t, safi_t, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_allowas_in_set(struct peer *, afi_t, safi_t, int, int);
|
|
|
|
extern int peer_allowas_in_unset(struct peer *, afi_t, safi_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_local_as_set(struct peer *, as_t, int, int);
|
|
|
|
extern int peer_local_as_unset(struct peer *);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_prefix_list_set(struct peer *, afi_t, safi_t, int,
|
|
|
|
const char *);
|
|
|
|
extern int peer_prefix_list_unset(struct peer *, afi_t, safi_t, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_aslist_set(struct peer *, afi_t, safi_t, int, const char *);
|
|
|
|
extern int peer_aslist_unset(struct peer *, afi_t, safi_t, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-09-14 10:56:46 +02:00
|
|
|
extern int peer_route_map_set(struct peer *peer, afi_t afi, safi_t safi, int,
|
|
|
|
const char *name, struct route_map *route_map);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_route_map_unset(struct peer *, afi_t, safi_t, int);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-09-14 10:56:46 +02:00
|
|
|
extern int peer_unsuppress_map_set(struct peer *peer, afi_t afi, safi_t safi,
|
|
|
|
const char *name,
|
|
|
|
struct route_map *route_map);
|
[bgpd] TCP-MD5: password vty configuration and initial Linux support
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* bgp_packet.c: (bgp_open_receive) fix warning in a zlog call
* bgp_vty.c: (bgp_vty_return) add return code
* bgpd.c: (bgp_master_init) setup the socket list.
* bgp_network.c: Remove the dual IPv4/6 socket thing for now, which
was implemented by Michael, until such time as its clear its
required for Linux (see sockopt comments). IPv6 support, including
IPv4 sessions on AF_INET6 sockets, therefore is broken, and the
'-l 0.0.0.0' arguments would need to be given to bgpd to make
things work here.
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Tomohiko Kusuda <kusuda@inetcore.com>
Leigh Brown <leigh@solinno.co.uk>
* bgp_network.c: (bgp_md5_set_one) shim between libzebra tcp-md5
sockopt and bgpd.
(bgp_md5_set_socket) Helper for bgp_connect
(bgp_md5_set) setup TCP-MD5SIG for the given peer.
(bgp_connect) call out to bgp_md5_set_socket for the outgoing
connect socket.
(bgp_socket) save references to the listen sockets, needed if
TCP-MD5SIG is applied later or changed.
* bgp_vty.c: (*neighbor_password_cmd) New 'neighbor ... password'
commands.
* bgpd.c: (peer_{new,delete) manage TCP-MD5 password
(peer_group2peer_config_copy) inherit TCP-MD5 password
(peer_password_{un,}set) orchestrate the whole add/remove of TCP-MD5
passwords: applying checks, stopping peers, and trying to return
errors to UI, etc.
(bgp_config_write_peer) save password.
Fix missing newline in writeout of neighbor ... port.
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* sockunion.c: ifdef out various places that converted
v4mapped sockets to pure v4. Doesn't seem necessary at all,
presumably a workaround for now historical inet_ntop bugs (?)
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* sockopt.{c,h}: (sockopt_tcp_signature) Add TCP-MD5SIG support.
2008-07-21 23:02:49 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_password_set(struct peer *, const char *);
|
|
|
|
extern int peer_password_unset(struct peer *);
|
[bgpd] TCP-MD5: password vty configuration and initial Linux support
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* bgp_packet.c: (bgp_open_receive) fix warning in a zlog call
* bgp_vty.c: (bgp_vty_return) add return code
* bgpd.c: (bgp_master_init) setup the socket list.
* bgp_network.c: Remove the dual IPv4/6 socket thing for now, which
was implemented by Michael, until such time as its clear its
required for Linux (see sockopt comments). IPv6 support, including
IPv4 sessions on AF_INET6 sockets, therefore is broken, and the
'-l 0.0.0.0' arguments would need to be given to bgpd to make
things work here.
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Tomohiko Kusuda <kusuda@inetcore.com>
Leigh Brown <leigh@solinno.co.uk>
* bgp_network.c: (bgp_md5_set_one) shim between libzebra tcp-md5
sockopt and bgpd.
(bgp_md5_set_socket) Helper for bgp_connect
(bgp_md5_set) setup TCP-MD5SIG for the given peer.
(bgp_connect) call out to bgp_md5_set_socket for the outgoing
connect socket.
(bgp_socket) save references to the listen sockets, needed if
TCP-MD5SIG is applied later or changed.
* bgp_vty.c: (*neighbor_password_cmd) New 'neighbor ... password'
commands.
* bgpd.c: (peer_{new,delete) manage TCP-MD5 password
(peer_group2peer_config_copy) inherit TCP-MD5 password
(peer_password_{un,}set) orchestrate the whole add/remove of TCP-MD5
passwords: applying checks, stopping peers, and trying to return
errors to UI, etc.
(bgp_config_write_peer) save password.
Fix missing newline in writeout of neighbor ... port.
2008-07-21 Paul Jakma <paul.jakma@sun.com>
* sockunion.c: ifdef out various places that converted
v4mapped sockets to pure v4. Doesn't seem necessary at all,
presumably a workaround for now historical inet_ntop bugs (?)
2008-07-21 Michael H. Warfield <mhw@wittsend.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
* sockopt.{c,h}: (sockopt_tcp_signature) Add TCP-MD5SIG support.
2008-07-21 23:02:49 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_unsuppress_map_unset(struct peer *, afi_t, safi_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2018-03-27 21:13:34 +02:00
|
|
|
extern int peer_maximum_prefix_set(struct peer *, afi_t, safi_t, uint32_t,
|
|
|
|
uint8_t, int, uint16_t);
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_maximum_prefix_unset(struct peer *, afi_t, safi_t);
|
2002-12-13 21:15:29 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_clear(struct peer *, struct listnode **);
|
|
|
|
extern int peer_clear_soft(struct peer *, afi_t, safi_t, enum bgp_clear_type);
|
2005-02-02 15:40:33 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_ttl_security_hops_set(struct peer *, int);
|
|
|
|
extern int peer_ttl_security_hops_unset(struct peer *);
|
bgpd: RFC 5082 Generalized TTL Security Mechanism support
* bgpd: Add support for RFC 5082 GTSM, which allows the TTL field to be used
to verify that incoming packets have been sent from neighbours no more
than X IP hops away. In other words, this allows packets that were sent from
further away (i.e. not by the neighbour with known distance, and so possibly
a miscreant) to be filtered out.
* lib/sockunion.{c,h}: (sockopt_minttl) new function, to set a minimum TTL
using the IP_MINTTL socket opt.
* bgpd.h: (BGP_ERR_NO_EBGP_MULTIHOP_WITH_TTLHACK) define for command
error for minttl.
(struct peer) add a config variable, to store the configured minttl.
(peer_ttl_security_hops_{set,unset}) configuration handlers
* bgpd.c: (peer_group_get) init gtsm_hops
(peer_ebgp_multihop_{un,}set) check for conflicts with GTSM. Multihop and
GTSM can't both be active for a peer at the same time.
(peer_ttl_security_hops_set) set minttl, taking care to avoid conflicts with
ebgp_multihop.
(bgp_config_write_peer) write out minttl as "neighbor .. ttl-security hops X".
* bgp_vty.c: (bgp_vty_return) message for
BGP_ERR_NO_EBGP_MULTIHOP_WITH_TTLHACK
(peer_ebgp_multihop_{un,}set_vty)
* bgp_network.c: (bgp_accept) set minttl on accepted sockets if appropriate.
(bgp_connect) ditto for outbound.
2011-03-23 16:33:17 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_tx_shutdown_message_set(struct peer *, const char *msg);
|
|
|
|
extern int peer_tx_shutdown_message_unset(struct peer *);
|
2017-01-25 03:30:52 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int bgp_route_map_update_timer(struct thread *thread);
|
2015-05-20 02:40:45 +02:00
|
|
|
extern void bgp_route_map_terminate(void);
|
2015-05-20 02:58:12 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern int peer_cmp(struct peer *p1, struct peer *p2);
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2017-08-01 02:06:40 +02:00
|
|
|
extern int bgp_map_afi_safi_iana2int(iana_afi_t pkt_afi, iana_safi_t pkt_safi,
|
2017-07-17 14:03:14 +02:00
|
|
|
afi_t *afi, safi_t *safi);
|
|
|
|
extern int bgp_map_afi_safi_int2iana(afi_t afi, safi_t safi,
|
2018-02-09 19:22:50 +01:00
|
|
|
iana_afi_t *pkt_afi,
|
|
|
|
iana_safi_t *pkt_safi);
|
2016-06-15 19:25:35 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
extern struct peer_af *peer_af_create(struct peer *, afi_t, safi_t);
|
|
|
|
extern struct peer_af *peer_af_find(struct peer *, afi_t, safi_t);
|
|
|
|
extern int peer_af_delete(struct peer *, afi_t, safi_t);
|
2015-05-20 03:03:47 +02:00
|
|
|
|
2015-05-20 03:12:17 +02:00
|
|
|
extern void bgp_close(void);
|
2017-08-07 13:40:10 +02:00
|
|
|
extern void bgp_free(struct bgp *);
|
|
|
|
|
|
|
|
static inline struct bgp *bgp_lock(struct bgp *bgp)
|
|
|
|
{
|
|
|
|
bgp->lock++;
|
|
|
|
return bgp;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void bgp_unlock(struct bgp *bgp)
|
|
|
|
{
|
|
|
|
assert(bgp->lock > 0);
|
|
|
|
if (--bgp->lock == 0)
|
|
|
|
bgp_free(bgp);
|
|
|
|
}
|
2015-05-20 03:12:17 +02:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int afindex(afi_t afi, safi_t safi)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
switch (afi) {
|
|
|
|
case AFI_IP:
|
|
|
|
switch (safi) {
|
|
|
|
case SAFI_UNICAST:
|
|
|
|
return BGP_AF_IPV4_UNICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_MULTICAST:
|
|
|
|
return BGP_AF_IPV4_MULTICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_LABELED_UNICAST:
|
|
|
|
return BGP_AF_IPV4_LBL_UNICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_MPLS_VPN:
|
|
|
|
return BGP_AF_IPV4_VPN;
|
|
|
|
break;
|
|
|
|
case SAFI_ENCAP:
|
|
|
|
return BGP_AF_IPV4_ENCAP;
|
|
|
|
break;
|
2017-01-23 03:45:30 +01:00
|
|
|
case SAFI_FLOWSPEC:
|
|
|
|
return BGP_AF_IPV4_FLOWSPEC;
|
2017-07-17 14:03:14 +02:00
|
|
|
default:
|
|
|
|
return BGP_AF_MAX;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case AFI_IP6:
|
|
|
|
switch (safi) {
|
|
|
|
case SAFI_UNICAST:
|
|
|
|
return BGP_AF_IPV6_UNICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_MULTICAST:
|
|
|
|
return BGP_AF_IPV6_MULTICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_LABELED_UNICAST:
|
|
|
|
return BGP_AF_IPV6_LBL_UNICAST;
|
|
|
|
break;
|
|
|
|
case SAFI_MPLS_VPN:
|
|
|
|
return BGP_AF_IPV6_VPN;
|
|
|
|
break;
|
|
|
|
case SAFI_ENCAP:
|
|
|
|
return BGP_AF_IPV6_ENCAP;
|
|
|
|
break;
|
2017-01-23 03:45:30 +01:00
|
|
|
case SAFI_FLOWSPEC:
|
|
|
|
return BGP_AF_IPV6_FLOWSPEC;
|
2017-07-17 14:03:14 +02:00
|
|
|
default:
|
|
|
|
return BGP_AF_MAX;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case AFI_L2VPN:
|
|
|
|
switch (safi) {
|
|
|
|
case SAFI_EVPN:
|
|
|
|
return BGP_AF_L2VPN_EVPN;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return BGP_AF_MAX;
|
|
|
|
break;
|
|
|
|
}
|
2015-05-20 03:03:47 +02:00
|
|
|
default:
|
2017-07-17 14:03:14 +02:00
|
|
|
return BGP_AF_MAX;
|
|
|
|
break;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
BGP: Remove the requirement to rebind a peer to its peer-group under the address-family.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-3868
NOTE: Many of the ibgp peers are not up in the 'show ip bgp summ' output below. This
is because ospf was disabled at the time. The main thing to look for is whether or
not all of the correct peers are listed based on their 'activate' status.
Basic Example
=============
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP activate
neighbor IBGP next-hop-self
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r2(10.0.0.2) 4 10 107 211 0 0 0 00:23:01 Connect
r3(10.0.0.3) 4 10 107 211 0 0 0 00:23:01 Connect
r4(10.0.0.4) 4 10 207 211 0 0 0 00:23:01 Active
r6(20.1.1.6) 4 20 873 975 0 0 0 00:23:29 600
r7(20.1.1.7) 4 20 873 976 0 0 0 00:23:29 600
r8(40.1.1.2) 4 40 874 975 0 0 0 00:23:30 600
r9(40.1.1.6) 4 40 874 975 0 0 0 00:23:30 600
r10(40.1.1.10) 4 40 874 975 0 0 0 00:23:30 600
Total number of neighbors 8
superm-redxp-05#
Example where one member of the peer-group is inactive...we can do this now that
peer-group members can have different outbound policies from the peer-group.
================================================================================
superm-redxp-05# conf t
superm-redxp-05(config)# router bgp 10
superm-redxp-05(config-router)# address-family ipv4 unicast
superm-redxp-05(config-router-af)# no neighbor 10.0.0.3 activate
superm-redxp-05(config-router-af)# do show run
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP activate
neighbor IBGP next-hop-self
no neighbor 10.0.0.3 activate
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r2(10.0.0.2) 4 10 107 211 0 0 0 00:23:24 Connect
r4(10.0.0.4) 4 10 207 211 0 0 0 00:23:24 Active
r6(20.1.1.6) 4 20 881 983 0 0 0 00:23:52 600
r7(20.1.1.7) 4 20 881 984 0 0 0 00:23:52 600
r8(40.1.1.2) 4 40 881 982 0 0 0 00:23:53 600
r9(40.1.1.6) 4 40 881 982 0 0 0 00:23:53 600
r10(40.1.1.10) 4 40 881 982 0 0 0 00:23:53 600
Total number of neighbors 7
superm-redxp-05#
Example where the peer-group is inactive but a member of the peer-group is active:
==================================================================================
superm-redxp-05(config)# router bgp 10
superm-redxp-05(config-router)# address-family ipv4 unicast
superm-redxp-05(config-router-af)# neighbor 10.0.0.3 activate
superm-redxp-05(config-router-af)# no neighbor IBGP activate
superm-redxp-05(config-router-af)#
superm-redxp-05(config-router-af)# neighbor 10.0.0.4 activate
superm-redxp-05(config-router-af)# end
superm-redxp-05# show run
router bgp 10
bgp router-id 10.0.0.1
no bgp default ipv4-unicast
no bgp bestpath as-path multipath-relax
bgp bestpath compare-routerid
bgp route-map delay-timer 1
neighbor EBGP peer-group
neighbor EBGP advertisement-interval 1
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source 10.0.0.1
neighbor IBGP advertisement-interval 1
neighbor 10.0.0.2 peer-group IBGP
neighbor 10.0.0.3 peer-group IBGP
neighbor 10.0.0.4 peer-group IBGP
neighbor 20.1.1.6 remote-as 20
neighbor 20.1.1.6 peer-group EBGP
neighbor 20.1.1.7 remote-as 20
neighbor 20.1.1.7 peer-group EBGP
neighbor 40.1.1.2 remote-as 40
neighbor 40.1.1.2 peer-group EBGP
neighbor 40.1.1.6 remote-as 40
neighbor 40.1.1.6 peer-group EBGP
neighbor 40.1.1.10 remote-as 40
neighbor 40.1.1.10 peer-group EBGP
!
address-family ipv4 unicast
neighbor EBGP activate
neighbor IBGP next-hop-self
neighbor 10.0.0.4 activate
exit-address-family
!
superm-redxp-05# show ip bgp summ
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 4200
RIB entries 2399, using 281 KiB of memory
Peers 8, using 129 KiB of memory
Peer groups 2, using 112 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
r4(10.0.0.4) 4 10 207 211 0 0 0 00:24:56 Active
r6(20.1.1.6) 4 20 911 1013 0 0 0 00:25:24 600
r7(20.1.1.7) 4 20 911 1014 0 0 0 00:25:24 600
r8(40.1.1.2) 4 40 912 1013 0 0 0 00:25:25 600
r9(40.1.1.6) 4 40 912 1013 0 0 0 00:25:25 600
r10(40.1.1.10) 4 40 912 1013 0 0 0 00:25:25 600
Total number of neighbors 6
superm-redxp-05#
2015-11-20 19:53:50 +01:00
|
|
|
/* If the peer is not a peer-group but is bound to a peer-group return 1 */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_group_active(struct peer *peer)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
if (!CHECK_FLAG(peer->sflags, PEER_STATUS_GROUP) && peer->group)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* If peer is negotiated at least one address family return 1. */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_afi_active_nego(const struct peer *peer, afi_t afi)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
if (peer->afc_nego[afi][SAFI_UNICAST]
|
|
|
|
|| peer->afc_nego[afi][SAFI_MULTICAST]
|
|
|
|
|| peer->afc_nego[afi][SAFI_LABELED_UNICAST]
|
|
|
|
|| peer->afc_nego[afi][SAFI_MPLS_VPN]
|
|
|
|
|| peer->afc_nego[afi][SAFI_ENCAP]
|
2017-01-23 03:45:30 +01:00
|
|
|
|| peer->afc_nego[afi][SAFI_FLOWSPEC]
|
2017-07-17 14:03:14 +02:00
|
|
|
|| peer->afc_nego[afi][SAFI_EVPN])
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
2015-05-20 03:03:47 +02:00
|
|
|
/* If at least one address family activated for group, return 1. */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_group_af_configured(struct peer_group *group)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
struct peer *peer = group->conf;
|
|
|
|
|
|
|
|
if (peer->afc[AFI_IP][SAFI_UNICAST] || peer->afc[AFI_IP][SAFI_MULTICAST]
|
|
|
|
|| peer->afc[AFI_IP][SAFI_LABELED_UNICAST]
|
2017-01-23 03:45:30 +01:00
|
|
|
|| peer->afc[AFI_IP][SAFI_FLOWSPEC]
|
2017-07-17 14:03:14 +02:00
|
|
|
|| peer->afc[AFI_IP][SAFI_MPLS_VPN] || peer->afc[AFI_IP][SAFI_ENCAP]
|
|
|
|
|| peer->afc[AFI_IP6][SAFI_UNICAST]
|
|
|
|
|| peer->afc[AFI_IP6][SAFI_MULTICAST]
|
|
|
|
|| peer->afc[AFI_IP6][SAFI_LABELED_UNICAST]
|
|
|
|
|| peer->afc[AFI_IP6][SAFI_MPLS_VPN]
|
2017-06-14 04:12:10 +02:00
|
|
|
|| peer->afc[AFI_IP6][SAFI_ENCAP]
|
2017-01-23 03:45:30 +01:00
|
|
|
|| peer->afc[AFI_IP6][SAFI_FLOWSPEC]
|
2017-06-14 04:12:10 +02:00
|
|
|
|| peer->afc[AFI_L2VPN][SAFI_EVPN])
|
2017-07-17 14:03:14 +02:00
|
|
|
return 1;
|
|
|
|
return 0;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline char *timestamp_string(time_t ts)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
time_t tbuf;
|
|
|
|
tbuf = time(NULL) - (bgp_clock() - ts);
|
|
|
|
return ctime(&tbuf);
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_established(struct peer *peer)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
if (peer->status == Established)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_dynamic_neighbor(struct peer *peer)
|
2015-05-20 03:03:47 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
return (CHECK_FLAG(peer->flags, PEER_FLAG_DYNAMIC_NEIGHBOR)) ? 1 : 0;
|
2015-05-20 03:03:47 +02:00
|
|
|
}
|
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline int peer_cap_enhe(struct peer *peer, afi_t afi, safi_t safi)
|
2015-06-11 18:19:12 +02:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
return (CHECK_FLAG(peer->af_cap[afi][safi], PEER_CAP_ENHE_AF_NEGO));
|
2015-06-11 18:19:12 +02:00
|
|
|
}
|
|
|
|
|
2016-02-20 03:43:30 +01:00
|
|
|
/* Lookup VRF for BGP instance based on its type. */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline struct vrf *bgp_vrf_lookup_by_instance_type(struct bgp *bgp)
|
2016-02-20 03:43:30 +01:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
struct vrf *vrf;
|
2016-02-20 03:43:30 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
if (bgp->inst_type == BGP_INSTANCE_TYPE_DEFAULT)
|
|
|
|
vrf = vrf_lookup_by_id(VRF_DEFAULT);
|
|
|
|
else if (bgp->inst_type == BGP_INSTANCE_TYPE_VRF)
|
|
|
|
vrf = vrf_lookup_by_name(bgp->name);
|
|
|
|
else
|
|
|
|
vrf = NULL;
|
2016-02-20 03:43:30 +01:00
|
|
|
|
2017-07-17 14:03:14 +02:00
|
|
|
return vrf;
|
2016-02-20 03:43:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Link BGP instance to VRF. */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline void bgp_vrf_link(struct bgp *bgp, struct vrf *vrf)
|
2016-02-20 03:43:30 +01:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
bgp->vrf_id = vrf->vrf_id;
|
2017-08-07 13:40:10 +02:00
|
|
|
if (vrf->info != (void *)bgp)
|
|
|
|
vrf->info = (void *)bgp_lock(bgp);
|
2016-02-20 03:43:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Unlink BGP instance from VRF. */
|
2017-07-17 14:03:14 +02:00
|
|
|
static inline void bgp_vrf_unlink(struct bgp *bgp, struct vrf *vrf)
|
2016-02-20 03:43:30 +01:00
|
|
|
{
|
2017-07-17 14:03:14 +02:00
|
|
|
if (vrf->info == (void *)bgp) {
|
|
|
|
vrf->info = NULL;
|
|
|
|
bgp_unlock(bgp);
|
|
|
|
}
|
|
|
|
bgp->vrf_id = VRF_UNKNOWN;
|
2016-02-20 03:43:30 +01:00
|
|
|
}
|
|
|
|
|
2019-03-14 16:17:47 +01:00
|
|
|
extern void bgp_unset_redist_vrf_bitmaps(struct bgp *, vrf_id_t);
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
|
|
|
|
/* For benefit of rfapi */
|
2017-07-17 14:03:14 +02:00
|
|
|
extern struct peer *peer_new(struct bgp *bgp);
|
2019-08-08 04:58:18 +02:00
|
|
|
|
|
|
|
extern struct peer *peer_lookup_in_view(struct vty *vty, struct bgp *bgp,
|
|
|
|
const char *ip_str, bool use_json);
|
|
|
|
|
2019-08-09 19:53:01 +02:00
|
|
|
/* Hooks */
|
|
|
|
DECLARE_HOOK(peer_status_changed, (struct peer * peer), (peer))
|
|
|
|
|
2005-05-23 16:19:54 +02:00
|
|
|
#endif /* _QUAGGA_BGPD_H */
|