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

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

141 lines
6.1 KiB
C
Raw Normal View History

*: auto-convert to SPDX License IDs Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-08 13:17:09 +01:00
// SPDX-License-Identifier: GPL-2.0-or-later
Initial revision
2002-12-13 21:15:29 +01:00
/* zebra connection and redistribute fucntions.
*: make consistent & update GPLv2 file headers The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-05-13 10:25:29 +02:00
* Copyright (C) 1999 Kunihiro Ishiguro
*/
Initial revision
2002-12-13 21:15:29 +01:00
2005-05-23 Paul Jakma <paul@dishone.st> * bgp_fsm.h: Add extern qualifier to exported functions * bgp_nexthop.c: add static to nexthop specific globals * *.h: Add guard defines
2005-05-23 16:19:54 +02:00
#ifndef _QUAGGA_BGP_ZEBRA_H
#define _QUAGGA_BGP_ZEBRA_H
bgpd/zebra/lib: EVPN support for asymmetric VxLan routing 1. Advertise gateway mac-ip in EVPN 2. Advertise VRR mac-ip in EVPN 3. Ignore gateway mac-ip advertisements in case of distributed gateway 4. Config knob to enable/disable gateway mac-ip advertisements Ticket: CM-16456, CM-16543, CM-16555, CM-16778 Review: CCR-6283 Unit-test: Manual Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
2017-06-28 10:51:10 +02:00
#include "vxlan.h"
bgpd: Few code optimisations Description: Added a macro which optimises some part of the code. Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
2021-09-17 17:50:03 +02:00
/* Macro to update bgp_original based on bpg_path_info */
#define BGP_ORIGINAL_UPDATE(_bgp_orig, _mpinfo, _bgp) \
bgpd: bgp_path_info_extra memory optimization Even if some of the attributes in bgp_path_info_extra are not used, their memory is still allocated every time. It cause a waste of memory. This commit code deletes all unnecessary attributes and changes the optional attributes to pointer storage. Memory will only be allocated when they are actually used. After optimization, extra info related memory is reduced by about half(~400B -> ~200B). Signed-off-by: Valerian_He <1826906282@qq.com>
2023-08-08 12:47:29 +02:00
((_mpinfo->extra && _mpinfo->extra->vrfleak && \
_mpinfo->extra->vrfleak->bgp_orig && \
_mpinfo->sub_type == BGP_ROUTE_IMPORTED) \
? (_bgp_orig = _mpinfo->extra->vrfleak->bgp_orig) \
bgpd: Few code optimisations Description: Added a macro which optimises some part of the code. Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
2021-09-17 17:50:03 +02:00
: (_bgp_orig = _bgp))
bgpd: Implement options for link bandwidth handling Support configurable options to control how link bandwidth is handled by the receiver. The default behavior is to automatically honor the link bandwidths received and use it to perform a weighted ECMP BUT only if all paths in the multipath have associated link bandwidth; if one or more paths do not have link bandwidth, normal ECMP is performed among the multipaths. This behavior is as recommended by https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth. The additional options available are to (a) completely ignore any link bandwidth (i.e., weighted ECMP is effectively disabled), (b) skip paths in the multipath which do not have link bandwidth and perform weighted ECMP among the other paths (if at least some paths have the bandwidth) or (c) use a default weight (value chosen is 1) for the paths which do not have link bandwidth. The command syntax is bgp bestpath bandwidth <ignore|skip-missing|default-weight-for-missing> Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2020-03-24 22:38:37 +01:00
/* Default weight for next hop, if doing weighted ECMP. */
#define BGP_ZEBRA_DEFAULT_NHOP_WEIGHT 1
*: Convert `struct event_master` to `struct event_loop` Let's find a better name for it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-07 20:14:41 +01:00
extern void bgp_zebra_init(struct event_loop *master, unsigned short instance);
bgpd: add 'mpls bgp forwarding' to ease mpls vpn ebgp peering RFC4364 describes peerings between multiple AS domains, to ease the continuity of VPN services across multiple SPs. This commit implements a sub-set of IETF option b) described in chapter 10 b. The ASBR to ASBR approach is taken, with an EBGP peering between the two routers. The EBGP peering must be directly connected to the outgoing interface used. In those conditions, the next hop is directly connected, and there is no need to have a transport label to convey the VPN label. A new vty command is added on a per interface basis: This command if enabled, will permit to convey BGP VPN labels without any transport labels (i.e. with implicit-null label). restriction: this command is used only for EBGP directly connected peerings. Other use cases are not covered. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2022-08-17 11:52:51 +02:00
extern void bgp_if_init(void);
bgpd: do not install BGP FS entries, while table range not obtained Sometimes at startup, BGP Flowspec may be allocated a routing table identifier not in the range of the predefined table range. This issue is due to the fact that BGP peering goes up, while the BGP did not yet retrieve the Table Range allocator. The fix is done so that BGP PBR entries are not installed while routing table identifier range is not obtained. Once the routing table identifier is obtained, parse the FS entries and check that all selected entries are installed, and if not, install it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-05-23 14:14:53 +02:00
extern void bgp_zebra_init_tm_connect(struct bgp *bgp);
bgpd: get table identifier from table manager A table chunk of 100000 is allocated from zebra, and when needed in flowspec, the table identifier is extracted from that chunk. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-04-03 15:06:50 +02:00
extern uint32_t bgp_zebra_tm_get_id(void);
bgpd: do not install BGP FS entries, while table range not obtained Sometimes at startup, BGP Flowspec may be allocated a routing table identifier not in the range of the predefined table range. This issue is due to the fact that BGP peering goes up, while the BGP did not yet retrieve the Table Range allocator. The fix is done so that BGP PBR entries are not installed while routing table identifier range is not obtained. Once the routing table identifier is obtained, parse the FS entries and check that all selected entries are installed, and if not, install it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-05-23 14:14:53 +02:00
extern bool bgp_zebra_tm_chunk_obtained(void);
bgpd: improve cleanup in bgp_delete() Signed-off-by: Lou Berger <lberger@labn.net> (cherry picked from commit 82dd707988b7481e203cab058c92f0b3041dd558) Conflicts: bgpd/bgp_nexthop.h bgpd/bgp_route.c bgpd/bgp_routemap.c bgpd/bgp_zebra.h bgpd/bgpd.c bgpd/bgpd.h
2016-01-12 19:41:57 +01:00
extern void bgp_zebra_destroy(void);
bgpd: Fix table manager to use the synchronous client bgp_zebra_tm_connect calls bgp_zebra_get_table_range which just used the global zclient. Which of course still had us exposing the global zclient to read and drop important data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-07-10 16:40:38 +02:00
extern int bgp_zebra_get_table_range(struct zclient *zc, uint32_t chunk_size,
bgpd: add API to allocate a range of table identifiers In BGP, doing policy-routing requires to use table identifiers. Flowspec protocol will need to have that. 1 API from bgp zebra has been done to get the table chunk. Internally, onec flowspec is enabled, the BGP engine will try to connect smoothly to the table manager. If zebra is not connected, it will try to connect 10 seconds later. If zebra is connected, and it is success, then a polling mechanism each 60 seconds is put in place. All the internal mechanism has no impact on the BGP process. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-05 18:09:57 +01:00
uint32_t *start, uint32_t *end);
2005-06-28 Paul Jakma <paul.jakma@sun.com> * (global) The great bgpd extern and static'ification. * bgp_routemap.c: remove unused ROUTE_MATCH_ASPATH_OLD code (route_set_metric_compile) fix u_int32_t to ULONG_MAX comparison warnings. * bgp_route.h: (bgp_process, bgp_withdraw, bgp_update) export these used by various files which had their own private declarations, in the case of mplsvpn - incorrect.
2005-06-28 14:44:16 +02:00
extern int bgp_if_update_all(void);
bgpd : backpressure - Handle BGP-Zebra Install evt Creation BGP is now keeping a list of dests with the dest having a pointer to the bgp_path_info that it will be working on. 1) When bgp receives a prefix, process it, add the bgp_dest of the prefix into the new Fifo list if not present, update the flags (Ex: earlier if the prefix was advertised and now it is a withdrawn), increment the ref_count and DO NOT advertise the install/withdraw to zebra yet. 2) Schedule an event to wake up to invoke the new function which will walk the list one by one and installs/withdraws the routes into zebra. a) if BUFFER_EMPTY, process the next item on the list b) if BUFFER_PENDING, bail out and the callback in zclient_flush_data() will invoke the same function when BUFFER_EMPTY Changes - rename old bgp_zebra_announce to bgp_zebra_announce_actual - rename old bgp_zebra_withdrw to bgp_zebra_withdraw_actual - Handle new fifo list cleanup in bgp_exit() - New funcs: bgp_handle_route_announcements_to_zebra() and bgp_zebra_route_install() - Define a callback function to invoke bgp_handle_route_announcements_to_zebra() when BUFFER_EMPTY in zclient_flush_data() The current change deals with bgp installing routes via bgp_process_main_one() Ticket: #3390099 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-01-26 20:48:53 +01:00
extern void bgp_zebra_route_install(struct bgp_dest *dest,
struct bgp_path_info *path, struct bgp *bgp,
bgpd : backpressure - Handle BGP-Zebra(EPVN) Install evt Creation Current changes deals with EVPN routes installation to zebra. In evpn_route_select_install() we invoke evpn_zebra_install/uninstall which sends zclient_send_message(). This is a continuation of code changes (similar to ccfe452763d16c432fa81fd20e805bec819b345e) but to handle evpn part of the code. Ticket: #3390099 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-02-15 20:23:51 +01:00
bool install, struct bgpevpn *vpn,
bool is_sync);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern void bgp_zebra_announce_table(struct bgp *bgp, afi_t afi, safi_t safi);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: set/unset bgpd no-rib option at runtime * Added vtysh cli commands and functions to set/unset bgp daemons no-rib option during runtime and withdraw/announce routes in bgp instances RIB from/to Zebra. Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2020-09-02 18:20:08 +02:00
/* Announce routes of any bgp subtype of a table to zebra */
extern void bgp_zebra_announce_table_all_subtypes(struct bgp *bgp, afi_t afi,
safi_t safi);
/* Withdraw all entries of any subtype in a BGP instances RIB table from Zebra */
extern void bgp_zebra_withdraw_table_all_subtypes(struct bgp *bgp, afi_t afi,
safi_t safi);
BGP: Trigger IPv6 router advertisements upon config of unnumbered neighbor Instead of turning on IPv6 RA on every interface as soon as it has an IPv6 address, only enable it upon configuration of BGP neighbor. When the BGP neighbor is deleted, signal that RAs can be turned off. To support this, introduce new message interaction between BGP and Zebra. Also, take appropriate actions in BGP upon interface add/del since the unnumbered neighbor could exist prior to interface creation etc. Only unnumbered IPv6 neighbors require RA, the /30 or /31 based neighbors don't. However, to keep the interaction simple and not have to deal with too many dynamic conditions (e.g., address deletes or neighbor change to/from 'v6only'), RAs on the interface are triggered upon any unnumbered neighbor configuration. BGP-triggered RAs will cause RAs to be initiated on the interface; however, if BGP asks that RAs be stopped (upon delete of unnumbered neighbor), RAs will continue to be exchanged if the operator has explicitly enabled. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Ticket: CM-10640 Reviewed By: CCR-4589 Testing Done: Various manual and automated (refer to defect)
2016-05-02 22:53:38 +02:00
extern void bgp_zebra_initiate_radv(struct bgp *bgp, struct peer *peer);
extern void bgp_zebra_terminate_radv(struct bgp *bgp, struct peer *peer);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern void bgp_zebra_instance_register(struct bgp *bgp);
extern void bgp_zebra_instance_deregister(struct bgp *bgp);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: move bgp_update_redist_vrf_bitmaps to bgp_zebra.c for wider use beyond bgp_vty Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
2019-03-13 19:41:29 +01:00
extern void bgp_redistribute_redo(struct bgp *bgp);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern struct bgp_redist *bgp_redist_lookup(struct bgp *bgp, afi_t afi,
uint8_t type,
unsigned short instance);
extern struct bgp_redist *bgp_redist_add(struct bgp *bgp, afi_t afi,
uint8_t type, unsigned short instance);
extern int bgp_redistribute_set(struct bgp *bgp, afi_t afi, int type,
unsigned short instance, bool changed);
extern int bgp_redistribute_resend(struct bgp *bgp, afi_t afi, int type,
unsigned short instance);
bgpd: Convert lots of int type functions to bool/void Some were converted to bool, where true/false status is needed. Converted to void only those, where the return status was only false or true. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
2020-03-20 10:57:54 +01:00
extern bool bgp_redistribute_rmap_set(struct bgp_redist *red, const char *name,
struct route_map *route_map);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern bool bgp_redistribute_metric_set(struct bgp *bgp, struct bgp_redist *red,
afi_t afi, int type, uint32_t metric);
bgpd: fix redistribute table command after bgp restarts When the BGP 'redistribute table' command is used for a given route table, and BGP configuration is flushed and rebuilt, the redistribution does not work. Actually, when flushing the BGP configuration with the 'no router bgp' command, the BGP redistribute entries related to the 'redistribute table' entries are not flushed. Actually, at BGP deletion, the table number is not given as parameter in bgp_redistribute_unset() function, and the redistribution entry is not removed in zebra. Fix this by adding some code to flush all the redistribute table instances. Fixes: 7c8ff89e9346 ("Multi-Instance OSPF Summary") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-08-28 12:23:24 +02:00
extern void bgp_redistribute_unset(struct bgp *bgp, afi_t afi, int type,
unsigned short instance);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern int bgp_redistribute_unreg(struct bgp *bgp, afi_t afi, int type,
unsigned short instance);
*: reindent indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2017-07-17 14:03:14 +02:00
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern struct interface *if_lookup_by_ipv4(struct in_addr *addr,
vrf_id_t vrf_id);
extern struct interface *if_lookup_by_ipv4_exact(struct in_addr *addr,
vrf_id_t vrf_id);
extern struct interface *if_lookup_by_ipv6(struct in6_addr *addr,
ifindex_t ifindex, vrf_id_t vrf_id);
extern struct interface *if_lookup_by_ipv6_exact(struct in6_addr *addr,
ifindex_t ifindex,
vrf_id_t vrf_id);
bgpd: advertise VNI subnet In EVPN symmetric routing, not all subnets are presents everywhere. We have multiple scenarios where a host might not get learned locally. 1. GARP miss 2. SVI down/up 3. Silent host We need a mechanism to resolve such hosts. In order to achieve this, we will be advertising a subnet route from a box and that box will help in resolving the ARP to such hosts. Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
2017-11-20 06:47:04 +01:00
extern int bgp_zebra_advertise_subnet(struct bgp *bgp, int advertise,
vni_t vni);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern int bgp_zebra_advertise_gw_macip(struct bgp *bgp, int advertise,
vni_t vni);
bgpd: advertise svi ip as macip zebra parse api Ticket:CM-23782 Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2019-02-04 02:29:59 +01:00
extern int bgp_zebra_advertise_svi_macip(struct bgp *bgp, int advertise,
vni_t vni);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern int bgp_zebra_advertise_all_vni(struct bgp *bgp, int advertise);
bgpd: dup addr detect config cli Duplicate address detection configuration clis under bgp l2vpn evpn config mode. - Enabled/Disable (global knob) for feature. - Configure cli for duplicate detection action freeze and freze until time (auto-recovery). Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
2018-11-01 16:28:08 +01:00
extern int bgp_zebra_dup_addr_detection(struct bgp *bgp);
bgpd: Add '[no] flood <disable|head-end-replication>' Add the '[no] flood <disable|head-end-replication>' command to the l2vpn evpn afi/safi sub commands for bgp. This command when entered as 'flood disable' will turn off type 3 route generation for the transmittal of the type 3 route necessary for BUM replication on the remote VTEP. Additionally it will turn off the BUM handling via the new zebra command, ZEBRA_VXLAN_FLOOD_CONTROL. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-10-05 01:20:12 +02:00
extern int bgp_zebra_vxlan_flood_control(struct bgp *bgp,
enum vxlan_flood_control flood_ctrl);
bgpd: Implement EVPN enable/disable Implement the command 'advertise-all-vni' under the EVPN address-family in order to allow the local system to learn about local VNIs (and MACs and Neighbors corresponding to those VNIs) and exchange with other EVPN speakers. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2017-05-15 23:30:19 +02:00
bgp: ignore NHT when bgpd has never connected to zebra
2016-10-07 15:44:42 +02:00
extern int bgp_zebra_num_connects(void);
bgpd: Align bgp_zebra.h to our standards bgp_zebra.h has function declarations that are not properly aligned with our standard on how to do so. Fix. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-05-12 14:28:11 +02:00
extern bool bgp_zebra_nexthop_set(union sockunion *local,
union sockunion *remote,
struct bgp_nexthop *nexthop,
struct peer *peer);
bgpd: communication with zebra for ipset & iprule handling The APIs that handle ipset and iprule contexts from zebra are being handled in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-08 15:39:19 +01:00
struct bgp_pbr_action;
struct bgp_pbr_match;
bgpd: ip rule zebra layer adapted to handle both cases now, ip rule can be created from two differnt ways; however a single zebra API has been defined. so make it consistent by adding a parameter to the bgp zebra layer. the function will handle the rest. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-11-29 15:14:41 +01:00
struct bgp_pbr_rule;
bgpd: communication with zebra for ipset & iprule handling The APIs that handle ipset and iprule contexts from zebra are being handled in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-08 15:39:19 +01:00
struct bgp_pbr_match_entry;
bgpd: Adding header files for BGPD-ZEBRA integration for GR. Data Structures, function declaration and Macros forSignalling from BGPD to ZEBRA to enable or disable GR feature in ZEBRA depending on bgp per peer gr configuration. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-25 17:42:39 +02:00
bgpd: communication with zebra for ipset & iprule handling The APIs that handle ipset and iprule contexts from zebra are being handled in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-08 15:39:19 +01:00
extern void bgp_send_pbr_rule_action(struct bgp_pbr_action *pbra,
bgpd: ip rule zebra layer adapted to handle both cases now, ip rule can be created from two differnt ways; however a single zebra API has been defined. so make it consistent by adding a parameter to the bgp zebra layer. the function will handle the rest. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-11-29 15:14:41 +01:00
struct bgp_pbr_rule *pbr,
bool install);
bgpd: communication with zebra for ipset & iprule handling The APIs that handle ipset and iprule contexts from zebra are being handled in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-08 15:39:19 +01:00
extern void bgp_send_pbr_ipset_match(struct bgp_pbr_match *pbrim,
bool install);
extern void bgp_send_pbr_ipset_entry_match(struct bgp_pbr_match_entry *pbrime,
bool install);
bgpd: handle configuration of iptables with zebra The API for filling in an IPTABLE_ADD and IPTABLE_DELETE message. Also, the API is handling the notification callback, so as to know if zebra managed to add or delete the relevant iptable entry. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-12 09:38:53 +01:00
extern void bgp_send_pbr_iptable(struct bgp_pbr_action *pba,
struct bgp_pbr_match *pbm,
bool install);
bgpd: communication with zebra for ipset & iprule handling The APIs that handle ipset and iprule contexts from zebra are being handled in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-08 15:39:19 +01:00
bgpd: handle FS redirect IP rule in PBR If a new rule is identified, a new table identifier is created. In that table, add a default route when possible. If redirect IP rule is identified, then add a default route to that IP address. If redirect VRF is identified, nothing is done for now Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2018-03-28 14:51:57 +02:00
extern void bgp_zebra_announce_default(struct bgp *bgp, struct nexthop *nh,
afi_t afi, uint32_t table_id, bool announce);
bgpd: Adding header files for BGPD-ZEBRA integration for GR. Data Structures, function declaration and Macros forSignalling from BGPD to ZEBRA to enable or disable GR feature in ZEBRA depending on bgp per peer gr configuration. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-25 17:42:39 +02:00
extern int bgp_zebra_send_capabilities(struct bgp *bgp, bool disable);
lib, bgpd: Add more debugs to GR Capability exchange a) Make it legible what type of message is being passed back and forth instead of having to guess it from the insufficient debugs b) Make it explicit which bgp instance is sending this data c) Cleanup bgp_zebra_update to have a cleaner api Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-09 14:36:51 +01:00
extern int bgp_zebra_update(struct bgp *bgp, afi_t afi, safi_t safi,
enum zserv_client_capabilities);
bgpd: Adding header files for BGPD-ZEBRA integration for GR. Data Structures, function declaration and Macros forSignalling from BGPD to ZEBRA to enable or disable GR feature in ZEBRA depending on bgp per peer gr configuration. Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
2019-10-25 17:42:39 +02:00
extern int bgp_zebra_stale_timer_update(struct bgp *bgp);
bgpd: cli for srv6-locator assignment (step4) This commit add command to speficy SRv6 locator for BGP SRv6-VPN. CLI example is follow. CLI block of "segment-routing" is already implemented by previous commits and it's managed by zebra. Zebra manage just the ownership of locator's prefix. Zlient can request to get srv6-locator's prefix chunk using srv6_manager_get_locator_chunk() which is usuful func to execute ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK api. This request is wokring as async, And zebra calls same api to Zclients when zebra allocate locator prefix chunk. And then, finally zclient(bgpd) catch the information via process_srv6_lcoator_chunk callback function. router bgp 1 segment-routing srv6 locator loc1 ! ! segment-routing srv6 locators locator loc1 prefix 2001:db8:1:1::/64 ! ! ! ! [POINT_OF_REVIEW] In current implementation, user can just configure srv6 locator but user can't de-configure srv6 locator. Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
2020-12-19 02:50:18 +01:00
extern int bgp_zebra_srv6_manager_get_locator_chunk(const char *name);
bgpd: add no-cli for srv6 on bgpd-side (1) Implement zapi wrapper func to release srv6-locator-chunk (2) Implement no locator NAME command router bgp 1 segment-routing srv6 no locator loc1 (3) Implement no segment-routing srv6 command router bgp 1 no segment-routing srv6 Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
2021-09-14 00:11:11 +02:00
extern int bgp_zebra_srv6_manager_release_locator_chunk(const char *name);
bgpd: Add API to get SRv6 locator info Add an API to request information from the SRv6 SID Manager (zebra) regarding a specific SRv6 locator. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-03-23 19:07:33 +01:00
extern int bgp_zebra_srv6_manager_get_locator(const char *name);
bgpd: Add API to get/release SRv6 SIDs Add an API to get/release SRv6 SIDs through the SRv6 SID Manager. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-03-23 19:17:48 +01:00
extern bool bgp_zebra_request_srv6_sid(const struct srv6_sid_ctx *ctx,
struct in6_addr *sid_value,
const char *locator_name,
uint32_t *sid_func);
extern void bgp_zebra_release_srv6_sid(const struct srv6_sid_ctx *ctx);
bgpd: Add API to get SRv6 locator info Add an API to request information from the SRv6 SID Manager (zebra) regarding a specific SRv6 locator. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-03-23 19:07:33 +01:00
bgpd: add support for l3vpn per-nexthop label This commit introduces a new method to associate a label to prefixes to export to a VPNv4 backbone. All the methods to associate a label to a BGP update is documented in rfc4364, chapter 4.3.2. Initially, the "single label for an entire VRF" method was available. This commit adds "single label for each attachment circuit" method. The change impacts the control-plane, because each BGP update is checked to know if the nexthop has reachability in the VRF or not. If this is the case, then a unique label for a given destination IP in the VRF will be picked up. This label will be reused for an other BGP update that will have the same nexthop IP address. The change impacts the data-plane, because the MPLs pop mechanism applied to incoming labelled packets changes: the MPLS label is popped, and the packet is directly sent to the connected nexthop described in the previous outgoing BGP VPN update. By default per-vrf mode is done, but the user may choose the per-nexthop mode, by using the vty command from the previous commit. In the latter case, a per-vrf label will however be allocated to handle networks that are not directly connected. This is the case for local traffic for instance. The change also include the following: - ECMP case In case a route is learnt in a given VRF, and is resolved via an ECMP nexthop. This implies that when exporting the route as a BGP update, if label allocation per nexthop is used, then two possible MPLS values could be picked up, which is not possible with the current implementation. Actually, the NLRI for VPNv4 stores one prefix, and one single label value, not two. Today, RFC8277 with multiple label capability is not yet available. To avoid this corner case, when a route is resolved via more than one nexthop, the label allocation per nexthop will not apply, and the default per-vrf label will be chosen. Let us imagine BGP redistributes a static route using the `172.31.0.20` nexthop. The nexthop resolution will find two different nexthops fo a unique BGP update. > r1# show running-config > [..] > vrf vrf1 > ip route 172.31.0.30/32 172.31.0.20 > r1# show bgp vrf vrf1 nexthop > [..] > 172.31.0.20 valid [IGP metric 0], #paths 1 > gate 192.0.2.11 > gate 192.0.2.12 > Last update: Mon Jan 16 09:27:09 2023 > Paths: > 1/1 172.31.0.30/32 VRF vrf1 flags 0x20018 To avoid this situation, BGP updates that resolve over multiple nexthops are using the unique per-vrf label. - recursive route case Prefixes that need a recursive route to be resolved can also be eligible for mpls allocation per nexthop. In that case, the nexthop will be the recursive nexthop calculated. To achieve this, all nexthop types in bnc contexts are valid, except for the blackhole nexthops. - network declared prefixes Nexthop tracking is used to look for the reachability of the prefixes. When the the 'no bgp network import-check' command is used, network declared prefixes are maintained active, even if there is no active nexthop. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-28 14:25:02 +01:00
extern void bgp_zebra_send_nexthop_label(int cmd, mpls_label_t label,
bgpd: use nexthop interface when adding LSP in BGP MPLSVPN BGP MPLSVPN next hop label allocation was using only the next-hop IP address. As MPLSVPN contexts rely on bnc contexts, the real nexthop interface is known, and the LSP entry to enter can apply to the specific interface. To illustrate, the BGP service is able to handle the following two iproute2 commands: > ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1 > ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-16 10:39:40 +01:00
ifindex_t index, vrf_id_t vrfid,
bgpd: add support for l3vpn per-nexthop label This commit introduces a new method to associate a label to prefixes to export to a VPNv4 backbone. All the methods to associate a label to a BGP update is documented in rfc4364, chapter 4.3.2. Initially, the "single label for an entire VRF" method was available. This commit adds "single label for each attachment circuit" method. The change impacts the control-plane, because each BGP update is checked to know if the nexthop has reachability in the VRF or not. If this is the case, then a unique label for a given destination IP in the VRF will be picked up. This label will be reused for an other BGP update that will have the same nexthop IP address. The change impacts the data-plane, because the MPLs pop mechanism applied to incoming labelled packets changes: the MPLS label is popped, and the packet is directly sent to the connected nexthop described in the previous outgoing BGP VPN update. By default per-vrf mode is done, but the user may choose the per-nexthop mode, by using the vty command from the previous commit. In the latter case, a per-vrf label will however be allocated to handle networks that are not directly connected. This is the case for local traffic for instance. The change also include the following: - ECMP case In case a route is learnt in a given VRF, and is resolved via an ECMP nexthop. This implies that when exporting the route as a BGP update, if label allocation per nexthop is used, then two possible MPLS values could be picked up, which is not possible with the current implementation. Actually, the NLRI for VPNv4 stores one prefix, and one single label value, not two. Today, RFC8277 with multiple label capability is not yet available. To avoid this corner case, when a route is resolved via more than one nexthop, the label allocation per nexthop will not apply, and the default per-vrf label will be chosen. Let us imagine BGP redistributes a static route using the `172.31.0.20` nexthop. The nexthop resolution will find two different nexthops fo a unique BGP update. > r1# show running-config > [..] > vrf vrf1 > ip route 172.31.0.30/32 172.31.0.20 > r1# show bgp vrf vrf1 nexthop > [..] > 172.31.0.20 valid [IGP metric 0], #paths 1 > gate 192.0.2.11 > gate 192.0.2.12 > Last update: Mon Jan 16 09:27:09 2023 > Paths: > 1/1 172.31.0.30/32 VRF vrf1 flags 0x20018 To avoid this situation, BGP updates that resolve over multiple nexthops are using the unique per-vrf label. - recursive route case Prefixes that need a recursive route to be resolved can also be eligible for mpls allocation per nexthop. In that case, the nexthop will be the recursive nexthop calculated. To achieve this, all nexthop types in bnc contexts are valid, except for the blackhole nexthops. - network declared prefixes Nexthop tracking is used to look for the reachability of the prefixes. When the the 'no bgp network import-check' command is used, network declared prefixes are maintained active, even if there is no active nexthop. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-02-28 14:25:02 +01:00
enum lsp_types_t ltype,
bgpd: store number of labels with 8 bits 8 bits are sufficient to store the number of labels because the current maximum is 2. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-02-26 18:11:09 +01:00
struct prefix *p, uint8_t num_labels,
bgpd: update the mpls entry to handle return traffic When advertising an mpls vpn entry with a new label, the return traffic is redirected to the local machine, but the MPLS traffic is dropped. Add an MPLS entry to handle MPLS packets which have the new label value. Traffic is swapped to the original label value from the mpls vpn next-hop entry; then it is sent to the resolved next-hop of the original next-hop from the mpls vpn next-hop entry. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-05-11 15:42:08 +02:00
mpls_label_t out_labels[]);
bgpd: fix hardset l3vpn label available in mpls pool Today, when configuring BGP L3VPN mpls, the operator may use that command to hardset a label value: > router bgp 65500 vrf vrf1 > address-family ipv4 unicast > label vpn export <hardset_label_value> Today, BGP uses this value without checks, leading to potential conflicts with other control planes like LDP. For instance, if LDP initiates with a label chunk of [16;72] and BGP also uses the 50 label value, a conflict arises. The 'label manager' service in zebra oversees label allocations. While all the control plane daemons use it, BGP doesn't when a hardset label is in place. This update fixes this problem. Now, when a hardset label is set for l3vpn export, a request is made to the label manager for approval, ensuring no conflicts with other daemons. But, this means some existing BGP configurations might become non-operational if they conflict with labels already allocated to another daemon but not used. note: Labels below 16 are reserved and won't be checked for consistency by the label manager. Fixes: ddb5b4880ba8 ("bgpd: vpn-vrf route leaking") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-09-01 17:14:06 +02:00
extern bool bgp_zebra_request_label_range(uint32_t base, uint32_t chunk_size,
bool label_auto);
bgpd: Use synchronous way to get labels from Zebra Both the label manager and table manager zapi code send data requests via zapi to zebra and then immediately listen for a response from zebra. The problem here is of course that the listen part is throwing away any zapi command that is not the one it is looking for. ISIS/OSPF and PIM all have synchronous abilities via zapi, which they all do through a special zapi connection to zebra. BGP needs to follow this model as well. Additionally the new zclient_sync connection that should be created, a once a second timer should wake up and read any data on the socket to prevent problems too much data accumulating in the socket. ``` r3# sh bgp labelpool summary Labelpool Summary ----------------- Ledger: 3 InUse: 3 Requests: 0 LabelChunks: 1 Pending: 128 Reconnects: 1 r3# sh bgp labelpool inuse Prefix Label --------------------------- 10.0.0.1/32 16 192.168.31.0/24 17 192.168.32.0/24 18 r3# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-06-12 16:09:52 +02:00
extern void bgp_zebra_release_label_range(uint32_t start, uint32_t end);
bgpd : backpressure - Handle BGP-Zebra Install evt Creation BGP is now keeping a list of dests with the dest having a pointer to the bgp_path_info that it will be working on. 1) When bgp receives a prefix, process it, add the bgp_dest of the prefix into the new Fifo list if not present, update the flags (Ex: earlier if the prefix was advertised and now it is a withdrawn), increment the ref_count and DO NOT advertise the install/withdraw to zebra yet. 2) Schedule an event to wake up to invoke the new function which will walk the list one by one and installs/withdraws the routes into zebra. a) if BUFFER_EMPTY, process the next item on the list b) if BUFFER_PENDING, bail out and the callback in zclient_flush_data() will invoke the same function when BUFFER_EMPTY Changes - rename old bgp_zebra_announce to bgp_zebra_announce_actual - rename old bgp_zebra_withdrw to bgp_zebra_withdraw_actual - Handle new fifo list cleanup in bgp_exit() - New funcs: bgp_handle_route_announcements_to_zebra() and bgp_zebra_route_install() - Define a callback function to invoke bgp_handle_route_announcements_to_zebra() when BUFFER_EMPTY in zclient_flush_data() The current change deals with bgp installing routes via bgp_process_main_one() Ticket: #3390099 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-01-26 20:48:53 +01:00
extern enum zclient_send_status
bgp_zebra_withdraw_actual(struct bgp_dest *dest, struct bgp_path_info *info,
struct bgp *bgp);
bgpd: backpressure - Optimize EVPN L2VNI remote routes processing Anytime BGP gets a L2 VNI ADD from zebra, - Walking the entire global routing table per L2VNI is very expensive. - The next read (say of another VNI ADD) from the socket does not proceed unless this walk is complete. So for triggers where a bulk of L2VNI's are flapped, this results in huge output buffer FIFO growth spiking up the memory in zebra since bgp is slow/busy processing the first message. To avoid this, idea is to hookup the VPN off the bgp_master struct and maintain a VPN FIFO list which is processed later on, where we walk a chunk of VPNs and do the remote route install. Note: So far in the L3 backpressure cases(#15524), we have considered the fact that zebra is slow, and the buffer grows in the BGP. However this is the reverse i.e. BGP is very busy processing the first ZAPI message from zebra due to which the buffer grows huge in zebra and memory spikes up. Ticket :#3864372 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-08-28 20:38:53 +02:00
extern void bgp_zebra_process_remote_routes_for_l2vni(struct event *e);
bgpd: backpressure - Optimize EVPN L3VNI remote routes processing Anytime BGP gets a L3 VNI ADD/DEL from zebra, - Walking the entire global routing table per L3VNI is very expensive. - The next read (say of another VNI ADD/DEL) from the socket does not proceed unless this walk is complete. So for triggers where a bulk of L3VNI's are flapped, this results in huge output buffer FIFO growth spiking up the memory in zebra since bgp is slow/busy processing the first message. To avoid this, idea is to hookup the BGP-VRF off the struct bgp_master and maintain a struct bgp FIFO list which is processed later on, where we walk a chunk of BGP-VRFs and do the remote route install/uninstall. Ticket :#3864372 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-11-27 09:04:51 +01:00
extern void bgp_zebra_process_remote_routes_for_l3vrf(struct event *e);
2005-05-23 Paul Jakma <paul@dishone.st> * bgp_fsm.h: Add extern qualifier to exported functions * bgp_nexthop.c: add static to nexthop specific globals * *.h: Add guard defines
2005-05-23 16:19:54 +02:00
#endif /* _QUAGGA_BGP_ZEBRA_H */
Copy permalink