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

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

160 lines
5.4 KiB
C
Raw Permalink Normal View History

*: auto-convert to SPDX License IDs Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-02-08 13:17:09 +01:00
// SPDX-License-Identifier: GPL-2.0-or-later
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP nexthop scan
*: 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) 2000 Kunihiro Ishiguro
*/
Initial revision
2002-12-13 21:15:29 +01:00
2005-05-23 Paul Jakma <paul@dishone.st> * bgp_fsm.h: Add extern qualifier to exported functions * bgp_nexthop.c: add static to nexthop specific globals * *.h: Add guard defines
2005-05-23 16:19:54 +02:00
#ifndef _QUAGGA_BGP_NEXTHOP_H
#define _QUAGGA_BGP_NEXTHOP_H
[bgpd] Include header dependency in bgp_nexthop.h 2006-03-19 Paul Jakma <paul.jakma@sun.com> * bgp_nexthop.h: Include if.h as a dependent header, for struct connected.
2006-03-30 16:01:14 +02:00
#include "if.h"
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
#include "queue.h"
#include "prefix.h"
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
#include "bgp_table.h"
[bgpd] Include header dependency in bgp_nexthop.h 2006-03-19 Paul Jakma <paul.jakma@sun.com> * bgp_nexthop.h: Include if.h as a dependent header, for struct connected.
2006-03-30 16:01:14 +02:00
bgpd: add nexthop length to AF macro Signed-off-by: Lou Berger <lberger@labn.net> Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 3e841d3b49bdb475ce793eee5d82e5137dff57d3)
2016-01-12 19:41:51 +01:00
#define NEXTHOP_FAMILY(nexthop_len) \
(((nexthop_len) == 4 || (nexthop_len) == 12 \
? AF_INET \
: ((nexthop_len) == 16 || (nexthop_len) == 24 \
bgpd: Handle connected routes and IPv6 link-local nexthops for route leaking Connected routes redistributed into BGP as well as IPv4 routes with IPv6 link-local next hops (RFC 5549) need information about the associated interface in BGP if they are candidates to be leaked into another VRF. In the absence of route leaking, this was not necessary. Introduce the appropriate mechanism and ensure this is used during route install (in the target VRF). Ticket: CM-20343, CM-20382 Testing done: 1. Manually verified failed scenarios and some additional ones - logs in the tickets. 2. Ran bgp-min and evpn-min - results are good. 3. Ran vrf smoke - has some failures, but none which look new Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2018-04-05 19:42:27 +02:00
|| (nexthop_len) == 32 \
bgpd: add nexthop length to AF macro Signed-off-by: Lou Berger <lberger@labn.net> Signed-off-by: David Lamparter <equinox@opensourcerouting.org> (cherry picked from commit 3e841d3b49bdb475ce793eee5d82e5137dff57d3)
2016-01-12 19:41:51 +01:00
|| (nexthop_len) == 48 \
? AF_INET6 \
: AF_UNSPEC)))
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_MP_NEXTHOP_FAMILY NEXTHOP_FAMILY
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
PREDECL_RBTREE_UNIQ(bgp_nexthop_cache);
Initial revision
2002-12-13 21:15:29 +01:00
/* BGP nexthop cache value structure. */
struct bgp_nexthop_cache {
bgpd: Ensure BGP does not stop monitoring nexthops In some cases BGP can be monitoring the same prefix in both the nexthop and import check tables. If this is the case, when unregistering one bnc from one table make sure we are not still registered in the other Example of the problem: r1(config-router)# address-family ipv4 uni r1(config-router-af)# no network 192.168.100.41/32 r1(config-router-af)# exit r1# show bgp import-check-table Current BGP import check cache: r1# show bgp nexthop Current BGP nexthop cache: 192.168.100.41 valid [IGP metric 0], #paths 1, peer 192.168.100.41 if r1-eth0 Last update: Wed Dec 6 11:01:40 2023 BGP now believes it is only watching 192.168.100.41 in the nexthop cache, but zebra doesn't have anything: r1# show ip import-check VRF default: Resolve via default: on r1# show ip nht VRF default: Resolve via default: on So if anything happens to the route that is being matched for 192.168.100.41 bgp is no longer going to be notified about this. The source of this problem is that zebra has dropped the two different tables into 1 table, while bgp has 2 tables to track this. The solution to this problem (other than the rewrite that is being done ) is to have BGP have a bit of smarts about looking in both tables for the bnc and if found in both don't send the delete of the prefix tracking to zebra. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-11-06 19:02:01 +01:00
afi_t afi;
bgpd: Switch LL nexthop tracking to be interface based bgp is currently registering v6 LL as nexthops to be tracked from zebra. This presents several problems. a) zebra does not properly track multiple prefixes that match the same route properly at this point in time. b) BGP was receiving nexthops that were just incorrect because of (a). c) When a nexthop changed that really didn't affect the v6 LL we were responding incorrectly because of this Modify the code such that bgp nexthop tracking notices that we are trying to register a v6 LL. When we do so, shortcut and watch interface up/down events for this v6 LL and do the work when an interface goes up / down for this type of tracking. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-17 15:46:30 +01:00
/* The ifindex of the outgoing interface *if* it's a v6 LL */
bgpd: rename bnc->ifindex to bnc->ifindex_ipv6_ll This commit changes the 'ifindex' name of the bnc structure. As it is used only to handle ipv6 link local addresses, let us use the 'ifindex_ipv6_ll' naming to avoid any confusions with the ifindex value of the resolved next-hops of the bnc structure. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-05-11 17:10:58 +02:00
ifindex_t ifindex_ipv6_ll;
bgpd: Switch LL nexthop tracking to be interface based bgp is currently registering v6 LL as nexthops to be tracked from zebra. This presents several problems. a) zebra does not properly track multiple prefixes that match the same route properly at this point in time. b) BGP was receiving nexthops that were just incorrect because of (a). c) When a nexthop changed that really didn't affect the v6 LL we were responding incorrectly because of this Modify the code such that bgp nexthop tracking notices that we are trying to register a v6 LL. When we do so, shortcut and watch interface up/down events for this v6 LL and do the work when an interface goes up / down for this type of tracking. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-17 15:46:30 +01:00
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
/* RB-tree entry. */
struct bgp_nexthop_cache_item entry;
Initial revision
2002-12-13 21:15:29 +01:00
/* IGP route's metric. */
*: use C99 standard fixed-width integer types The following types are nonstandard: - u_char - u_short - u_int - u_long - u_int8_t - u_int16_t - u_int32_t Replace them with the C99 standard types: - uint8_t - unsigned short - unsigned int - unsigned long - uint8_t - uint16_t - uint32_t Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-03-27 21:13:34 +02:00
uint32_t metric;
Initial revision
2002-12-13 21:15:29 +01:00
/* Nexthop number and nexthop linked list.*/
*: Allow 16 bit size for nexthops Currently FRR is limiting the nexthop count to a uint8_t not a uint16_t. This leads to issues when the nexthop count is 256 which results in the count to overflow to 0 causing problems in the code. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-10-07 18:40:46 +02:00
uint16_t nexthop_num;
bgpd: Optimize memory for bgp_nexthop_cache struct ``` struct bgp_nexthop_cache { afi_t afi; /* 0 4 */ ifindex_t ifindex_ipv6_ll; /* 4 4 */ struct bgp_nexthop_cache_item entry; /* 8 32 */ uint32_t metric; /* 40 4 */ uint8_t nexthop_num; /* 44 1 */ _Bool is_evpn_gwip_nexthop; /* 45 1 */ uint16_t change_flags; /* 46 2 */ struct nexthop * nexthop; /* 48 8 */ time_t last_update; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ uint16_t flags; /* 64 2 */ /* XXX 2 bytes hole, try to pack */ uint32_t srte_color; /* 68 4 */ struct bgp_nexthop_cache_head * tree; /* 72 8 */ struct prefix prefix __attribute__((__aligned__(8))); /* 80 56 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ void * nht_info; /* 136 8 */ struct path_list paths; /* 144 8 */ unsigned int path_count; /* 152 4 */ /* XXX 4 bytes hole, try to pack */ struct bgp * bgp; /* 160 8 */ /* size: 168, cachelines: 3, members: 17 */ /* sum members: 162, holes: 2, sum holes: 6 */ /* forced alignments: 1 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); /* saved 16 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-09 16:25:05 +01:00
/* This flag is set to TRUE for a bnc that is gateway IP overlay index
* nexthop.
*/
bool is_evpn_gwip_nexthop;
bgpd: Remove unused BGP_NEXTHOP_CONNECTED_CHANGED flag for nexthop Also reduce the size of change_flags, which is way enough to be 1 byte. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-10-15 11:43:38 +02:00
uint8_t change_flags;
bgpd: Optimize memory for bgp_nexthop_cache struct ``` struct bgp_nexthop_cache { afi_t afi; /* 0 4 */ ifindex_t ifindex_ipv6_ll; /* 4 4 */ struct bgp_nexthop_cache_item entry; /* 8 32 */ uint32_t metric; /* 40 4 */ uint8_t nexthop_num; /* 44 1 */ _Bool is_evpn_gwip_nexthop; /* 45 1 */ uint16_t change_flags; /* 46 2 */ struct nexthop * nexthop; /* 48 8 */ time_t last_update; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ uint16_t flags; /* 64 2 */ /* XXX 2 bytes hole, try to pack */ uint32_t srte_color; /* 68 4 */ struct bgp_nexthop_cache_head * tree; /* 72 8 */ struct prefix prefix __attribute__((__aligned__(8))); /* 80 56 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ void * nht_info; /* 136 8 */ struct path_list paths; /* 144 8 */ unsigned int path_count; /* 152 4 */ /* XXX 4 bytes hole, try to pack */ struct bgp * bgp; /* 160 8 */ /* size: 168, cachelines: 3, members: 17 */ /* sum members: 162, holes: 2, sum holes: 6 */ /* forced alignments: 1 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); /* saved 16 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-09 16:25:05 +01:00
#define BGP_NEXTHOP_CHANGED (1 << 0)
#define BGP_NEXTHOP_METRIC_CHANGED (1 << 1)
bgpd: Remove unused BGP_NEXTHOP_CONNECTED_CHANGED flag for nexthop Also reduce the size of change_flags, which is way enough to be 1 byte. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-10-15 11:43:38 +02:00
#define BGP_NEXTHOP_MACIP_CHANGED (1 << 2)
bgpd: Optimize memory for bgp_nexthop_cache struct ``` struct bgp_nexthop_cache { afi_t afi; /* 0 4 */ ifindex_t ifindex_ipv6_ll; /* 4 4 */ struct bgp_nexthop_cache_item entry; /* 8 32 */ uint32_t metric; /* 40 4 */ uint8_t nexthop_num; /* 44 1 */ _Bool is_evpn_gwip_nexthop; /* 45 1 */ uint16_t change_flags; /* 46 2 */ struct nexthop * nexthop; /* 48 8 */ time_t last_update; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ uint16_t flags; /* 64 2 */ /* XXX 2 bytes hole, try to pack */ uint32_t srte_color; /* 68 4 */ struct bgp_nexthop_cache_head * tree; /* 72 8 */ struct prefix prefix __attribute__((__aligned__(8))); /* 80 56 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ void * nht_info; /* 136 8 */ struct path_list paths; /* 144 8 */ unsigned int path_count; /* 152 4 */ /* XXX 4 bytes hole, try to pack */ struct bgp * bgp; /* 160 8 */ /* size: 168, cachelines: 3, members: 17 */ /* sum members: 162, holes: 2, sum holes: 6 */ /* forced alignments: 1 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); /* saved 16 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-09 16:25:05 +01:00
Initial revision
2002-12-13 21:15:29 +01:00
struct nexthop *nexthop;
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
time_t last_update;
*: use C99 standard fixed-width integer types The following types are nonstandard: - u_char - u_short - u_int - u_long - u_int8_t - u_int16_t - u_int32_t Replace them with the C99 standard types: - uint8_t - unsigned short - unsigned int - unsigned long - uint8_t - uint16_t - uint32_t Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-03-27 21:13:34 +02:00
uint16_t flags;
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
bgpd: EVPN route type-5 to type-2 recursive resolution using gateway IP When EVPN prefix route with a gateway IP overlay index is imported into the IP vrf at the ingress PE, BGP nexthop of this route is set to the gateway IP. For this vrf route to be valid, following conditions must be met. - Gateway IP nexthop of this route should be L3 reachable, i.e., this route should be resolved in RIB. - A remote MAC/IP route should be present for the gateway IP address in the EVI(L2VPN table). To check for the first condition, gateway IP is registered with nht (nexthop tracking) to receive the reachability notifications for this IP from zebra RIB. If the gateway IP is reachable, zebra sends the reachability information (i.e., nexthop interface) for the gateway IP. This nexthop interface should be the SVI interface. Now, to find out type-2 route corresponding to the gateway IP, we need to fetch the VNI for the above SVI. To do this VNI lookup effitiently, define a hashtable of struct bgpevpn with svi_ifindex as key. struct hash *vni_svi_hash; An EVI instance is added to vni_svi_hash if its svi_ifindex is nonzero. Using this hash, we obtain struct bgpevpn corresponding to the gateway IP. For gateway IP overlay index recursive lookup, once we find the correct EVI, we have to lookup its route table for a MAC/IP prefix. As we have to iterate the entire route table for every lookup, this lookup is expensive. We can optimize this lookup by adding all the remote IP addresses in a hash table. Following hash table is defined for this purpose in struct bgpevpn Struct hash *remote_ip_hash; When a MAC/IP route is installed in the EVI table, it is also added to remote_ip_hash. It is possible to have multiple MAC/IP routes with the same IP address because of host move scenarios. Thus, for every address addr in remote_ip_hash, we maintain list of all the MAC/IP routes having addr as their IP address. Following structure defines an address in remote_ip_hash. struct evpn_remote_ip { struct ipaddr addr; struct list *macip_path_list; }; A Boolean field is added to struct bgp_nexthop_cache to indicate that the nexthop is EVPN gateway IP overlay index. bool is_evpn_gwip_nexthop; A flag BGP_NEXTHOP_EVPN_INCOMPLETE is added to struct bgp_nexthop_cache. This flag is set when the gateway IP is L3 reachable but not yet resolved by a MAC/IP route. Following table explains the combination of L3 and L2 reachability w.r.t. BGP_NEXTHOP_VALID and BGP_NEXTHOP_EVPN_INCOMPLETE flags * | MACIP resolved | MACIP unresolved *----------------|----------------|------------------ * L3 reachable | VALID = 1 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 1 * ---------------|----------------|-------------------- * L3 unreachable | VALID = 0 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 0 Procedure that we use to check if the gateway IP is resolvable by a MAC/IP route: - Find the EVI/L2VRF that belongs to the nexthop SVI using vni_svi_hash. - Check if the gateway IP is present in remote_ip_hash in this EVI. When the gateway IP is L3 reachable and it is also resolved by a MAC/IP route, unset BGP_NEXTHOP_EVPN_INCOMPLETE flag and set BGP_NEXTHOP_VALID flag. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
2021-01-11 12:51:56 +01:00
/*
* If the nexthop is EVPN gateway IP NH, VALID flag is set only if the nexthop
* is RIB reachable as well as MAC/IP is present
*/
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
#define BGP_NEXTHOP_VALID (1 << 0)
#define BGP_NEXTHOP_REGISTERED (1 << 1)
#define BGP_NEXTHOP_CONNECTED (1 << 2)
#define BGP_NEXTHOP_PEER_NOTIFIED (1 << 3)
bgpd-nht-import-check-fix.patch BGP: Fix network import check use with NHT instead of scanner When next hop tracking was implemented and the bgp scanner was eliminated, the "network import-check" command got broken. This patch fixes that issue. NHT is used to not just track nexthops, but also the static routes that are announced as part of BGP's network command. The routes are registered only when import-check is enabled. To optimize performance, we register static routes only when import-check is enabled. Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
2015-05-20 03:04:20 +02:00
#define BGP_STATIC_ROUTE (1 << 4)
#define BGP_STATIC_ROUTE_EXACT_MATCH (1 << 5)
bgpd: nexthop tracking with labels for vrf-vpn leaking Routes that have labels must be sent via a nexthop that also has labels. This change notes whether any path in a nexthop update from zebra contains labels. If so, then the nexthop is valid for routes that have labels. If a nexthop update has no labeled paths, then any labeled routes referencing the nexthop are marked not valid. Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself as nexthop when announcing" so that we can track our notion of the nexthop without revealing it to peers. Signed-off-by: G. Paul Ziemba <paulz@labn.net>
2018-03-24 00:57:03 +01:00
#define BGP_NEXTHOP_LABELED_VALID (1 << 6)
bgpd: Validate imported routes next-hop that is in a default VRF Without this patch: ``` r1# sh ip bgp vrf CUSTOMER-A BGP table version is 1, local router ID is 20.20.20.0, vrf id 4 Default local pref 100, local AS 65000 Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path 192.168.2.0/24 192.168.179.5@0< 0 0 479 ? Displayed 1 routes and 1 total paths r1# ``` This is because the route is imported, next-hop is in a default VRF, and we should evaluate an ultimate path info, not the current path info. After: ``` r1# sh ip bgp vrf CUSTOMER-A BGP table version is 1, local router ID is 20.20.20.0, vrf id 4 Default local pref 100, local AS 65000 Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 192.168.2.0/24 192.168.179.5@0< 0 0 479 ? Displayed 1 routes and 1 total paths r1# ``` In both cases next-hop in cache table is valid: ``` r1# sh ip bgp nexthop Current BGP nexthop cache: 192.168.179.5 valid [IGP metric 0], #paths 2, peer 192.168.179.5 Resolved prefix 192.168.179.0/24 if r1-eth0 Last update: Thu Sep 5 11:24:37 2024 r1# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-09-05 10:24:53 +02:00
#define BGP_NEXTHOP_ULTIMATE (1 << 7)
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
bgpd: EVPN route type-5 to type-2 recursive resolution using gateway IP When EVPN prefix route with a gateway IP overlay index is imported into the IP vrf at the ingress PE, BGP nexthop of this route is set to the gateway IP. For this vrf route to be valid, following conditions must be met. - Gateway IP nexthop of this route should be L3 reachable, i.e., this route should be resolved in RIB. - A remote MAC/IP route should be present for the gateway IP address in the EVI(L2VPN table). To check for the first condition, gateway IP is registered with nht (nexthop tracking) to receive the reachability notifications for this IP from zebra RIB. If the gateway IP is reachable, zebra sends the reachability information (i.e., nexthop interface) for the gateway IP. This nexthop interface should be the SVI interface. Now, to find out type-2 route corresponding to the gateway IP, we need to fetch the VNI for the above SVI. To do this VNI lookup effitiently, define a hashtable of struct bgpevpn with svi_ifindex as key. struct hash *vni_svi_hash; An EVI instance is added to vni_svi_hash if its svi_ifindex is nonzero. Using this hash, we obtain struct bgpevpn corresponding to the gateway IP. For gateway IP overlay index recursive lookup, once we find the correct EVI, we have to lookup its route table for a MAC/IP prefix. As we have to iterate the entire route table for every lookup, this lookup is expensive. We can optimize this lookup by adding all the remote IP addresses in a hash table. Following hash table is defined for this purpose in struct bgpevpn Struct hash *remote_ip_hash; When a MAC/IP route is installed in the EVI table, it is also added to remote_ip_hash. It is possible to have multiple MAC/IP routes with the same IP address because of host move scenarios. Thus, for every address addr in remote_ip_hash, we maintain list of all the MAC/IP routes having addr as their IP address. Following structure defines an address in remote_ip_hash. struct evpn_remote_ip { struct ipaddr addr; struct list *macip_path_list; }; A Boolean field is added to struct bgp_nexthop_cache to indicate that the nexthop is EVPN gateway IP overlay index. bool is_evpn_gwip_nexthop; A flag BGP_NEXTHOP_EVPN_INCOMPLETE is added to struct bgp_nexthop_cache. This flag is set when the gateway IP is L3 reachable but not yet resolved by a MAC/IP route. Following table explains the combination of L3 and L2 reachability w.r.t. BGP_NEXTHOP_VALID and BGP_NEXTHOP_EVPN_INCOMPLETE flags * | MACIP resolved | MACIP unresolved *----------------|----------------|------------------ * L3 reachable | VALID = 1 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 1 * ---------------|----------------|-------------------- * L3 unreachable | VALID = 0 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 0 Procedure that we use to check if the gateway IP is resolvable by a MAC/IP route: - Find the EVI/L2VRF that belongs to the nexthop SVI using vni_svi_hash. - Check if the gateway IP is present in remote_ip_hash in this EVI. When the gateway IP is L3 reachable and it is also resolved by a MAC/IP route, unset BGP_NEXTHOP_EVPN_INCOMPLETE flag and set BGP_NEXTHOP_VALID flag. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
2021-01-11 12:51:56 +01:00
/*
* This flag is added for EVPN gateway IP nexthops.
* If the nexthop is RIB reachable, but a MAC/IP is not yet
* resolved, this flag is set.
* Following table explains the combination of L3 and L2 reachability w.r.t.
* VALID and INCOMPLETE flags
*
* | MACIP resolved | MACIP unresolved
*----------------|----------------|------------------
* L3 reachable | VALID = 1 | VALID = 0
* | INCOMPLETE = 0 | INCOMPLETE = 1
* ---------------|----------------|--------------------
* L3 unreachable | VALID = 0 | VALID = 0
* | INCOMPLETE = 0 | INCOMPLETE = 0
*/
bgpd: Use unique value for BGP_NEXTHOP_EVPN_INCOMPLETE flag This was reused with BGP_NEXTHOP_ULTIMATE by error. Fixes: 93fd9cbb5022e0c40827cd6d6ef339624a8b5daa ("bgpd: Validate imported routes next-hop that is in a default VRF") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-05 20:42:18 +01:00
#define BGP_NEXTHOP_EVPN_INCOMPLETE (1 << 8)
bgpd: EVPN route type-5 to type-2 recursive resolution using gateway IP When EVPN prefix route with a gateway IP overlay index is imported into the IP vrf at the ingress PE, BGP nexthop of this route is set to the gateway IP. For this vrf route to be valid, following conditions must be met. - Gateway IP nexthop of this route should be L3 reachable, i.e., this route should be resolved in RIB. - A remote MAC/IP route should be present for the gateway IP address in the EVI(L2VPN table). To check for the first condition, gateway IP is registered with nht (nexthop tracking) to receive the reachability notifications for this IP from zebra RIB. If the gateway IP is reachable, zebra sends the reachability information (i.e., nexthop interface) for the gateway IP. This nexthop interface should be the SVI interface. Now, to find out type-2 route corresponding to the gateway IP, we need to fetch the VNI for the above SVI. To do this VNI lookup effitiently, define a hashtable of struct bgpevpn with svi_ifindex as key. struct hash *vni_svi_hash; An EVI instance is added to vni_svi_hash if its svi_ifindex is nonzero. Using this hash, we obtain struct bgpevpn corresponding to the gateway IP. For gateway IP overlay index recursive lookup, once we find the correct EVI, we have to lookup its route table for a MAC/IP prefix. As we have to iterate the entire route table for every lookup, this lookup is expensive. We can optimize this lookup by adding all the remote IP addresses in a hash table. Following hash table is defined for this purpose in struct bgpevpn Struct hash *remote_ip_hash; When a MAC/IP route is installed in the EVI table, it is also added to remote_ip_hash. It is possible to have multiple MAC/IP routes with the same IP address because of host move scenarios. Thus, for every address addr in remote_ip_hash, we maintain list of all the MAC/IP routes having addr as their IP address. Following structure defines an address in remote_ip_hash. struct evpn_remote_ip { struct ipaddr addr; struct list *macip_path_list; }; A Boolean field is added to struct bgp_nexthop_cache to indicate that the nexthop is EVPN gateway IP overlay index. bool is_evpn_gwip_nexthop; A flag BGP_NEXTHOP_EVPN_INCOMPLETE is added to struct bgp_nexthop_cache. This flag is set when the gateway IP is L3 reachable but not yet resolved by a MAC/IP route. Following table explains the combination of L3 and L2 reachability w.r.t. BGP_NEXTHOP_VALID and BGP_NEXTHOP_EVPN_INCOMPLETE flags * | MACIP resolved | MACIP unresolved *----------------|----------------|------------------ * L3 reachable | VALID = 1 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 1 * ---------------|----------------|-------------------- * L3 unreachable | VALID = 0 | VALID = 0 * | INCOMPLETE = 0 | INCOMPLETE = 0 Procedure that we use to check if the gateway IP is resolvable by a MAC/IP route: - Find the EVI/L2VRF that belongs to the nexthop SVI using vni_svi_hash. - Check if the gateway IP is present in remote_ip_hash in this EVI. When the gateway IP is L3 reachable and it is also resolved by a MAC/IP route, unset BGP_NEXTHOP_EVPN_INCOMPLETE flag and set BGP_NEXTHOP_VALID flag. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
2021-01-11 12:51:56 +01:00
bgpd: Optimize memory for bgp_nexthop_cache struct ``` struct bgp_nexthop_cache { afi_t afi; /* 0 4 */ ifindex_t ifindex_ipv6_ll; /* 4 4 */ struct bgp_nexthop_cache_item entry; /* 8 32 */ uint32_t metric; /* 40 4 */ uint8_t nexthop_num; /* 44 1 */ _Bool is_evpn_gwip_nexthop; /* 45 1 */ uint16_t change_flags; /* 46 2 */ struct nexthop * nexthop; /* 48 8 */ time_t last_update; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ uint16_t flags; /* 64 2 */ /* XXX 2 bytes hole, try to pack */ uint32_t srte_color; /* 68 4 */ struct bgp_nexthop_cache_head * tree; /* 72 8 */ struct prefix prefix __attribute__((__aligned__(8))); /* 80 56 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ void * nht_info; /* 136 8 */ struct path_list paths; /* 144 8 */ unsigned int path_count; /* 152 4 */ /* XXX 4 bytes hole, try to pack */ struct bgp * bgp; /* 160 8 */ /* size: 168, cachelines: 3, members: 17 */ /* sum members: 162, holes: 2, sum holes: 6 */ /* forced alignments: 1 */ /* last cacheline: 40 bytes */ } __attribute__((__aligned__(8))); /* saved 16 bytes! */ ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-02-09 16:25:05 +01:00
uint32_t srte_color;
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
/* Back pointer to the cache tree this entry belongs to. */
struct bgp_nexthop_cache_head *tree;
struct prefix prefix;
bgpd: add resolved_prefix visibility on nht The nexthop tracking never displays the prefix that has been used in ZEBRA to resolve its nexthop. This information will be useful if some decision has to be taken regarding any loops, that is to say if for instance a BGP prefix is resolved over a prefix in ZEBRA that is exactly the same. Store the value in bgp nexthop context, and display it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-03-29 12:07:14 +01:00
struct prefix resolved_prefix;
bgpd-nht-connected-route.patch BGP: Use next hop tracking for connected routes too And cleanup obsolete code in bgp_scan and bgp_import.
2015-05-20 02:47:21 +02:00
void *nht_info; /* In BGP, peer session */
bgpd: Convert `struct bgp_info` to `struct bgp_path_info` Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`. This commit will setup the rename of variables as well. This is being done because `struct bgp_info` is not descriptive of what this data actually is. It is path information for routes that we keep to build the actual routes nexthops plus some extra information. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-10-02 22:41:30 +02:00
LIST_HEAD(path_list, bgp_path_info) paths;
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
unsigned int path_count;
When internal operations are performed (e.g., best-path selection, next-hop change processing etc.) that refer to the BGP instance, the correct BGP instance must be referenced and not the default BGP instance. The default BGP instance is the first instance on the instance list. In a scenario where one BGP instance is deleted (through operator action such as a "no router bgp" command) and another instance exists or is created, there may still be events in-flight that need to be processed against the deleted instance. Trying to process these against the default instance is erroneous. The calls to bgp_get_default() must be limited to the user interface (vtysh) context. Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
2015-05-20 03:03:50 +02:00
struct bgp *bgp;
Initial revision
2002-12-13 21:15:29 +01:00
};
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
extern int bgp_nexthop_cache_compare(const struct bgp_nexthop_cache *a,
const struct bgp_nexthop_cache *b);
DECLARE_RBTREE_UNIQ(bgp_nexthop_cache, struct bgp_nexthop_cache, entry,
bgp_nexthop_cache_compare);
bgpd: Ignore EVPN routes from CLAG peer when VNI comes up There are two parts to this commit: 1. create a database of self tunnel-ip for used in martian nexthop check In a CLAG setup, the tunnel-ip (VNI UP) notification comes before the clag-anycast-ip comes up in the system. This was causing our self next hop check to fail and we were instaling routes with martian nexthop in zebra. We need to keep this info in a seperate database for all local tunnel-ip. This database will be used in parallel with the self next hop database to martian nexthop checks. 2. When a local VNI comes up, update the tunnel-ip database and filter routes in the RD table if necessary In case of EVPN we might receive routes from clag peer before the clag-anycast ip and VNI is up on the system. We will store the routes in the RD table for later processing. When VNI comes UP, we loop thorugh all the routes and install them in zebra if required. However, we were missing the martian nexthop check in this code path. From now onwards, when a VNI comes UP, we will first update the tunnel-ip database We then loop through all the routes in RD table and apply martian next hop filter if required. Things not covered in this commit but are required: This processing is needed in general when an address becomes a connected address. We need to loop through all the routes in BGP and apply martian nexthop filter if necessary. This will be taken care in a seperate bug Ticket:CM-17271/CM-16911 Reviewed By: ccr-6542 Testing Done: Manual Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
2017-08-17 08:19:58 +02:00
/* Own tunnel-ip address structure */
struct tip_addr {
struct in_addr addr;
int refcnt;
};
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
/* Forward declaration(s). */
struct peer;
struct update_subgroup;
struct bgp_dest;
struct attr;
bgpd: Add bgp_nexthop_dump_bnc_flags Add a function that allows us to see a string version of the bnc->flags bit fields. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-28 01:56:13 +01:00
#define BNC_FLAG_DUMP_SIZE 180
extern char *bgp_nexthop_dump_bnc_flags(struct bgp_nexthop_cache *bnc,
char *buf, size_t len);
bgpd: Add `bgp_nexthop_dump_bnc_change_flags` function Allow us to read what the change flags are instead of having to look them up. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-28 02:03:03 +01:00
extern char *bgp_nexthop_dump_bnc_change_flags(struct bgp_nexthop_cache *bnc,
char *buf, size_t len);
bgpd: Add the ability to use a VRF to bgp Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
2016-02-02 13:36:20 +01:00
extern void bgp_connected_add(struct bgp *bgp, struct connected *c);
extern void bgp_connected_delete(struct bgp *bgp, struct connected *c);
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_subgrp_multiaccess_check_v4(struct in_addr nexthop,
struct update_subgroup *subgrp,
struct peer *exclude);
extern bool bgp_subgrp_multiaccess_check_v6(struct in6_addr nexthop,
struct update_subgroup *subgrp,
struct peer *exclude);
extern bool bgp_multiaccess_check_v4(struct in_addr nexthop, struct peer *peer);
extern bool bgp_multiaccess_check_v6(struct in6_addr nexthop,
struct peer *peer);
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_config_write_scan_time(struct vty *);
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_nexthop_self(struct bgp *bgp, afi_t afi, uint8_t type,
uint8_t sub_type, struct attr *attr,
bgp: rename bgp_node to bgp_dest This is the bulk part extracted from "bgpd: Convert from `struct bgp_node` to `struct bgp_dest`". It should not result in any functional change. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2020-03-27 00:11:58 +01:00
struct bgp_dest *dest);
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
extern struct bgp_nexthop_cache *bnc_new(struct bgp_nexthop_cache_head *tree,
bgpd: extend the NHT code to understand SR-TE colors Extend the NHT code so that only the affected BGP routes are affected whenever an SR-policy is updated on zebra. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-08-26 19:39:33 +02:00
struct prefix *prefix,
Revert "bgpd: combine import_check_table and nexthop_check_table"
2023-11-06 16:07:58 +01:00
uint32_t srte_color,
ifindex_t ifindex);
bgpd: do not unregister for prefix nexthop updates if nh exists since the addition of srte_color to the comparison for bgp nexthops it is possible to have several nexthops per prefix but since zebra only sores a per prefix registration we should not unregister for nh notifications for a prefix unti all the nexthops for that prefix have been deleted. Otherwise we can get into a deadlock situation where BGP thinks we have registered but we have unregistered from zebra. Signed-off-by: Pat Ruddy <pat@voltanet.io>
2020-06-26 18:37:30 +02:00
extern bool bnc_existing_for_prefix(struct bgp_nexthop_cache *bnc);
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
extern void bnc_free(struct bgp_nexthop_cache *bnc);
bgpd: convert NHT code to use rb-trees instead of routing tables Fist, routing tables aren't the most appropriate data structure to store nexthops and imported routes since we don't need to do longest prefix matches with that information. Second, by converting the NHT code to use rb-trees, we can index the nexthops using additional information, not only the destination address. This will be useful later to index bgpd's nexthops by both destination and SR-TE color. Co-authored-by: Sebastien Merle <sebastien@netdef.org> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-04-09 20:56:11 +02:00
extern struct bgp_nexthop_cache *bnc_find(struct bgp_nexthop_cache_head *tree,
bgpd: extend the NHT code to understand SR-TE colors Extend the NHT code so that only the affected BGP routes are affected whenever an SR-policy is updated on zebra. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-08-26 19:39:33 +02:00
struct prefix *prefix,
bgpd: LL peers need bnc's per peer FRR should create a bnc per peer. Not have one's that write over others. Currently when FRR has multiple Interface based peering, BGP wa creating a single BNC. This is insufficient in that we were accidently overwriting the one LL with other data. This causes issues when there are multiple and there is weird starting issues with those interfaces that you are peering over. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2022-07-21 21:42:51 +02:00
uint32_t srte_color,
ifindex_t ifindex);
nexthop-tracking.patch quagga: nexthop-tracking.patch Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt. Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
2015-05-20 02:40:34 +02:00
extern void bnc_nexthop_free(struct bgp_nexthop_cache *bnc);
bgpd: Add the ability to use a VRF to bgp Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
2016-02-02 13:36:20 +01:00
extern void bgp_scan_init(struct bgp *bgp);
extern void bgp_scan_finish(struct bgp *bgp);
bgpd: bgpd-warnings.patch Remove compile warnings for the bgpd directory Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by:
2015-05-20 03:12:17 +02:00
extern void bgp_scan_vty_init(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_address_init(struct bgp *bgp);
extern void bgp_address_destroy(struct bgp *bgp);
bgpd: only unimport routes if tunnel-ip changes When processing a new local VNI, we were always walking the global EVPN table to look for routes that needed to be removed due to a martian nexthop change (specifically a tunnel-ip change). Since the martian TIP table is global (all VNIs) + the walk is also in the global table (all VNIs), we can trust that any new TIP from any VNI would result in routes getting removed from the global table and unimported from all live (L2)VNIs. i.e. The only time this update is actionable is if we are adding/removing an IP from the martian TIP table, and we do not need to walk the table for normal refcount adjustments. Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
2023-01-25 19:07:43 +01:00
extern bool bgp_tip_add(struct bgp *bgp, struct in_addr *tip);
bgpd: Ignore EVPN routes from CLAG peer when VNI comes up There are two parts to this commit: 1. create a database of self tunnel-ip for used in martian nexthop check In a CLAG setup, the tunnel-ip (VNI UP) notification comes before the clag-anycast-ip comes up in the system. This was causing our self next hop check to fail and we were instaling routes with martian nexthop in zebra. We need to keep this info in a seperate database for all local tunnel-ip. This database will be used in parallel with the self next hop database to martian nexthop checks. 2. When a local VNI comes up, update the tunnel-ip database and filter routes in the RD table if necessary In case of EVPN we might receive routes from clag peer before the clag-anycast ip and VNI is up on the system. We will store the routes in the RD table for later processing. When VNI comes UP, we loop thorugh all the routes and install them in zebra if required. However, we were missing the martian nexthop check in this code path. From now onwards, when a VNI comes UP, we will first update the tunnel-ip database We then loop through all the routes in RD table and apply martian next hop filter if required. Things not covered in this commit but are required: This processing is needed in general when an address becomes a connected address. We need to loop through all the routes in BGP and apply martian nexthop filter if necessary. This will be taken care in a seperate bug Ticket:CM-17271/CM-16911 Reviewed By: ccr-6542 Testing Done: Manual Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
2017-08-17 08:19:58 +02:00
extern void bgp_tip_del(struct bgp *bgp, struct in_addr *tip);
extern void bgp_tip_hash_init(struct bgp *bgp);
extern void bgp_tip_hash_destroy(struct bgp *bgp);
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
bgpd: Make `struct bgp_addr` a private data structure The `struct bgp_addr` is not needed for anything other than the address hash. Isolate this data structure so that it is not polluting up the name space. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
2018-09-21 21:50:47 +02:00
extern void bgp_nexthop_show_address_hash(struct vty *vty, struct bgp *bgp);
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_NEXTHOP_H */
Copy permalink