summaryrefslogtreecommitdiff
path: root/bgpd/bgp_route.c
AgeCommit message (Collapse)Author
2025-03-15bgpd: Fixed crash upon bgp network import-check commandManpreet Kaur
BT: ``` 3 <signal handler called> 4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40, bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232 5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413 6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0, argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609 7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000, ``` The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because pi->extra->vrfleak was NULL. ``` (gdb) p pi->extra->vrfleak $1 = (struct bgp_path_info_extra_vrfleak *) 0x0 (gdb) p pi->extra->vrfleak->bgp_orig Cannot access memory at address 0x8 ``` Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig to prevent the segmentation fault. Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com> (cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
2025-02-21bgpd: remove dmed check not required in bestpath selectionDonald Sharp
As part of the upstream master commit (f3575f61c7 bgpd: Sort the bgp_path_inf) the snippet of the code for dmed check condition left out, which leads to an issue of selecting incorrect bestpath. As an example: During the bestpath selection local route looses to another path due to dmed condition being hit. The snippet of the logs: 2025/02/20 03:06:20.131441 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.7 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted 2025/02/20 03:06:20.131445 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.7 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local 2025/02/20 03:06:20.131452 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.8 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted 2025/02/20 03:06:20.131456 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.8 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local 2025/02/20 03:06:20.131458 BGP: [WEWEC-8SE72] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): path Static announcement is the bestpath from AS 0 <<<< static is best 2025/02/20 03:06:20.131463 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.7 dmed 2025/02/20 03:06:20.131467 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.8 dmed 2025/02/20 03:06:20.131471 BGP: [N6CTF-2RSKS] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): After path selection, newbest is path 27.0.0.7 oldbest was Static announce Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 83ad94694bc061e1ff5f43db42cba46320e0df73)
2025-02-12bgpd: fix incorrect json in bgp_show_table_rdLouis Scalbert
In bgp_show_table_rd(), the is_last argument is determined using the expression "next == NULL" to check if the RD table is the last one. This helps ensure proper JSON formatting. However, if next is not NULL but is no longer associated with a BGP table, the JSON output becomes malformed. Updates the condition to also verify the existence of the next bgp_dest table. Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit cf0269649cdd09b8d3f2dd8815caf6ecf9cdeef9)
2025-02-01bgpd: With suppress-fib-pending ensure withdrawal is sentDonald Sharp
When you have suppress-fib-pending turned on it is possible to end up in a situation where the prefix is not withdrawn from downstream peers. Here is the timing that I believe is happening: a) have 2 paths to a peer. b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING and send the route install to zebra. c) receive a withdrawal from the other path. d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING old_select the path_info going away, new_select is NULL e) A bit further down we call group_announce_route() which calls the code to see if we should advertise the path. It sees the BGP_NODE_FIB_INSTALL_PENDING flag and says, nope. f) the route is sent to zebra to withdraw, which unsets the BGP_NODE_FIB_INSTALL_PENDING. g) This function winds up and deletes the path_info. Dest now has no path infos. h) BGP receives the route install(from step b) and unsets the BGP_NODE_FIB_INSTALL_PENDING flag i) BGP receives the route removed from zebra (from step f) and unsets the flag again. We know if there is no new_select, let's go ahead and just unset the PENDING flag to allow the withdrawal to go out at the time when the second withdrawal is received. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 4e8eda74ec7d30ba84e7f53f077f4b896728505a)
2025-01-14bgpd: fix memory leak in bgp_aggregate_install()Enke Chen
Potential memory leak with as-set and matching-MED-only config. Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 94ca6ddfae959a08e84a7a5a070f44ddba70f156)
2025-01-14bgpd: apply route-map for aggregate before attribute comparisonEnke Chen
Currently when re-evaluating an aggregate route, the full attribute of the aggregate route is not compared with the existing one in the BGP table. That can result in unnecessary churns (un-install and then install) of the aggregate route when a more specific route is added or deleted, or when the route-map for the aggregate changes. The churn would impact route installation and route advertisement. The fix is to apply the route-map for the aggregate first and then compare the attribute. Here is an example of the churn: debug bgp aggregate prefix 5.5.5.0/24 ! route-map set-comm permit 10 set community 65004:200 ! router bgp 65001 address-family ipv4 unicast redistribute static aggregate-address 5.5.5.0/24 route-map set-comm ! Step 1: ip route 5.5.5.1/32 Null0 Jan 8 10:28:49 enke-vm1 bgpd[285786]: [J7PXJ-A7YA2] bgp_aggregate_install: aggregate 5.5.5.0/24, count 1 Jan 8 10:28:49 enke-vm1 bgpd[285786]: [Y444T-HEVNG] aggregate 5.5.5.0/24: installed Step 2: ip route 5.5.5.2/32 Null0 Jan 8 10:29:03 enke-vm1 bgpd[285786]: [J7PXJ-A7YA2] bgp_aggregate_install: aggregate 5.5.5.0/24, count 2 Jan 8 10:29:03 enke-vm1 bgpd[285786]: [S2EH5-EQSX6] aggregate 5.5.5.0/24: existing, removed Jan 8 10:29:03 enke-vm1 bgpd[285786]: [Y444T-HEVNG] aggregate 5.5.5.0/24: installed --- Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit 22d95f4ba8444171944eab29e99dfa6087813d6f)
2025-01-14Revert "bgpd: Reinstall aggregated routes if using route-maps and it was ↵Enke Chen
changed" This reverts commit ee1986f1b5ae6b94b446b12e1b77cc30d8f5f46d. The fix is incomplete, and is no longer needed with the fix that applies the route-map for an aggregate and then compares the attribute. Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit 74c9d89aaf3df1b583de341169c4cb77eaa1b3b4)
2024-12-17bgpd: Fix evpn bestpath calculation when path is not establishedDonald Sharp
If you have a bestpath list that looks something like this: <local evpn mac route> <learned from peer out swp60> <learned from peer out swp57> And a network event happens that causes the peer out swp60 to not be in an established state, yet we still have the path_info for the destination for swp60, bestpath will currently end up with this order: <learned from peer out swp60> <local evpn mac route> <learned from peer out swp57> This causes the local evpn mac route to be deleted in zebra( Wrong! ). This is happening because swp60 is skipped in bestpath calculation and not considered to be a path yet it stays at the front of the list. Modify bestpath calculation such that when pulling the unsorted_list together to pull path info's into that list when they are also not in a established state. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 9f88cb56dc0fe7a4ce864f672c6ca420fcd420c2)
2024-11-26bgpd: fix version attribute is an int, not a stringPhilippe Guibert
The json display of the version attribute is originally an integer. It has changed, most probably mistakenly. > { > "vrfId": 7, > "vrfName": "vrf1", > "tableVersion": 3, > "routerId": "192.0.2.1", > "defaultLocPrf": 100, > "localAS": 65500, > "routes": { > "172.31.0.1/32": { > "prefix": "172.31.0.1/32", > "version": "1", <--- int or string ?? Let us fix it, by using the integer display instead. Fixes: f9f2d188e398 ("bgpd: fix 'json detail' output structure") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit c5d7815cccb92c192ca6b752843b8b827a607b53)
2024-11-17bgpd: Validate both nexthop information (NEXTHOP and NLRI)Donatas Abraitis
If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we have at least one a valid nexthop. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit a0d2734e879f78fbef5f1815429de331b9940c73)
2024-11-10bgpd: Fix for match source-protocol in route-map for redistribute cmdRajasekar Raja
A redistribute cmd can have a route-map attached to it and adding the match source-protocol to that route-map means BGP to filter which protocol routes to accept among the bunch of routes zebra is sending. Fixing this since this wasnt implemented earlier. Ticket :#4119692 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com> (cherry picked from commit 68358c0f928eafe50c9e73b0cb6a443c03f2a33f) Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-08bgpd: Clear all paths including addpath once GR expiresDonatas Abraitis
We iterated over all bgp_path_info's, but once we remove the path, we didn't check for other paths under the same bgp_dest. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-10-28bgpd: fix display of local label in show bgpLouis Scalbert
Fix the display of the local label in show bgp. > r1# show bgp ipv4 labeled-unicast 172.16.2.2/32 > BGP routing table entry for 172.16.2.2/32, version 2 > Local label: 16 <---- MISSING > Paths: (1 available, best #1, table default, vrf (null)) > Advertised to non peer-group peers: > 192.168.1.2 > 65501 > 192.168.1.2 from 192.168.1.2 (172.16.2.2) > Origin IGP, metric 0, valid, external, best (First path received) > Remote label: 3 > Last update: Fri Oct 25 17:55:45 2024 Fixes: 67f67ba481 ("bgpd: Drop label_ntop/label_pton functions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> (cherry picked from commit e7b3276ace65d59edb4d614158d4f2959f12f868)
2024-10-25bgpd: compare aigp after local route check in bgp_path_info_cmp()Enke Chen
For consistency between RIB and BGP, the aigp comparison should be made after the local route check in bgp bestpath selection. Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit 6a7049aaacc32e6a473a4d56ca61444d1e1eb45d)
2024-10-22bgpd: Do not filter no-export community for BGP OAD (one administration domain)Donatas Abraitis
OAD is treated as an _internal_ BGP peer, and some of the rules (including BGP attributes) can be relaxed. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit e63b1520f1ad1036455c1626a388ac3afb7f9d6d)
2024-10-17bgpd: fix several issues in sourcing AIGP attributeEnke Chen
Fix several issues in sourcing AIGP attribute: 1) AIGP should not be set as default for a redistributed route or a static network. It should be set by config instead. 2) AIGP sourced by "set aigp-metric igp-metric" in a route-map does not set the correct value for a redistributed route. 3) When redistribute a connected route like loopback, the AGIP (with value 0) is sourced by "set aigp-metric igp-metric", but the attribute is not propagated as the attribute flag is not set. Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit f65356d8bb9a43b1725fafdbd30aba0de9d214fa)
2024-10-15bgpd: fix route selection with AIGPEnke Chen
The nexthop metric should be added to AIGP when calculating the bestpath in bgp_path_info_cmp(). Signed-off-by: Enke Chen <enchen@paloaltonetworks.com> (cherry picked from commit 081422e8e71085d3a3d4d2ff0bc1e1abaff0d52e)
2024-08-29Merge pull request #16587 from ↵Jafar Al-Gharaibeh
opensourcerouting/fix/revert_ipv4_mapped_ipv6_stuff_10.1 Revert IPv4 mapped IPv6 stuff for 10.1
2024-08-27bgpd: fix labels static-analyserLouis Scalbert
Fix static-analyser warnings with BGP labels: > $ scan-build make -j12 > bgpd/bgp_updgrp_packet.c:819:10: warning: Access to field 'extra' results in a dereference of a null pointer (loaded from variable 'path') [core.NullDereference] > ? &path->extra->labels->label[0] > ^~~~~~~~~ Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-08-15bgpd: fix memory type for static->prd_prettyPhilippe Guibert
A crash happens when executing the following command: > ubuntu2204hwe# conf > ubuntu2204hwe(config)# router bgp 65500 > ubuntu2204hwe(config-router)# ! > ubuntu2204hwe(config-router)# address-family ipv4 unicast > ubuntu2204hwe(config-router-af)# sid vpn export auto > ubuntu2204hwe(config-router-af)# exit-address-family > ubuntu2204hwe(config-router)# ! > ubuntu2204hwe(config-router)# address-family ipv4 vpn > ubuntu2204hwe(config-router-af)# network 4.4.4.4/32 rd 55:55 label 556 > ubuntu2204hwe(config-router-af)# network 5.5.5.5/32 rd 662:33 label 232 > ubuntu2204hwe(config-router-af)# exit-address-family > ubuntu2204hwe(config-router)# exit > ubuntu2204hwe(config)# ! > ubuntu2204hwe(config)# no router bgp The crash analysis indicates a memory item has been freed. > #6 0x000076066a629c15 in mt_count_free (mt=0x56b57be85e00 <MTYPE_BGP_NAME>, ptr=0x60200038b4f0) > at lib/memory.c:73 > #7 mt_count_free (ptr=0x60200038b4f0, mt=0x56b57be85e00 <MTYPE_BGP_NAME>) at lib/memory.c:69 > #8 qfree (mt=mt@entry=0x56b57be85e00 <MTYPE_BGP_NAME>, ptr=0x60200038b4f0) at lib/memory.c:129 > #9 0x000056b57bb09ce9 in bgp_free (bgp=<optimized out>) at bgpd/bgpd.c:4120 > #10 0x000056b57bb0aa73 in bgp_unlock (bgp=<optimized out>) at ./bgpd/bgpd.h:2513 > #11 peer_free (peer=0x62a000000200) at bgpd/bgpd.c:1313 > #12 0x000056b57bb0aca8 in peer_unlock_with_caller (name=<optimized out>, peer=<optimized out>) > at bgpd/bgpd.c:1344 > #13 0x000076066a6dbb2c in event_call (thread=thread@entry=0x7ffc8cae1d60) at lib/event.c:2011 > #14 0x000076066a60aa88 in frr_run (master=0x613000000040) at lib/libfrr.c:1214 > #15 0x000056b57b8b2c44 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:543 Actually, the BGP_NAME item has not been used at allocation for static->prd_pretty, and this results in reaching 0 quicker at bgp deletion. Fix this by reassigning MTYPE_BGP_NAME to prd_pretty. Fixes: 16600df2c4f4 ("bgpd: fix show run of network route-distinguisher") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit 64594f8a6830eec5cc20b9c8a8676d1f62a16bcd)
2024-08-14Revert "bgpd: fix "used" json key on link-local nexthop"Donatas Abraitis
This reverts commit 2de4dfc97adfec788e45e148b4204196d612c81c.
2024-07-01bgpd: Ignore RFC8212 for BGP ConfederationsDonatas Abraitis
RFC 8212 should be restricted for eBGP peers. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit fa2cc09d45d3f843564f7bd1e02346373c5741a8)
2024-06-25bgpd: Relax OAD (One-Administration-Domain) for RFC8212Donatas Abraitis
RFC 8212 defines leak prevention for eBGP peers, but BGP-OAD defines a new peering type One Administrative Domain (OAD), where multiple ASNs could be used inside a single administrative domain. OAD allows sending non-transitive attributes, so this prevention should be relaxed too. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 3b98ddf5018cf7526b50c15018cbaf71a38fa752)
2024-06-05bgpd: fix labels in adj-rib-inPhilippe Guibert
In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with 'soft-reconfiguration inbound'), after applying a deny route-map and removing it, the remote MPLS label information is lost. As a result, BGP is unable to re-install the related routes in the RIB. For example, > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4 vpn > neighbor 192.0.2.2 activate > neighbor 192.0.2.2 soft-reconfiguration inbound The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP RIB. > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Remote label: 102 A route-map now filter all incoming BGP updates: > route-map rmap deny 1 > router bgp 65500 > address-family ipv4 vpn > neighbor 192.0.2.2 route-map rmap in The prefix is now filtered: > # show bgp ipv4 vpn 192.168.0.0/24 > # The route-map is detached: > router bgp 65500 > address-family ipv4 vpn > no neighbor 192.168.0.1 route-map rmap in The BGP RIB entry is present but the remote label is lost: > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 The reason for the loose is that labels are stored within struct attr -> struct extra -> struct bgp_labels but not in the struct bgp_adj_in. Reference the bgp_labels pointer in struct bgp_adj_in and use its values when doing a soft reconfiguration of the BGP table. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: get rid of has_valid_label in bgp_update()Louis Scalbert
Get rid of has_valid_label in bgp_update() to prepare the next commits. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: move labels from extra to extra->labelsLouis Scalbert
Move labels from extra to extra->labels. Labels are now stored in a hash list. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: store number of labels with 8 bitsLouis Scalbert
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-06-05bgpd: add bgp_path_info_num_labels()Louis Scalbert
Add bgp_path_info_num_labels() to get the number of labels stored in a path_info structure. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: rework vni printing in route_vty_out_detail()Louis Scalbert
In route_vty_out_detail(), tag_buf stores a string representation of the VNI label. Rename tag_buf to vni_buf for clarity and rework the code a little bit to prepare the following commits. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_labels_same()Louis Scalbert
Add bgp_path_info_labels_same() to compare labels with labels from path_info. Remove labels_same() that was used for mplsvpn only. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: optimize label copy for new path_infoLouis Scalbert
In bgp_update(), path_info *new has just been created and has void labels. bgp_labels_same() is always false. Do not compare previous labels before setting them. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: do not init labels in extraLouis Scalbert
No need to init labels at extra allocation. num_labels is the number of set labels in label[] and is initialized to 0 by default. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_has_valid_label()Louis Scalbert
Add bgp_path_has_valid_label to check that a path_info has a valid label. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: check and set extra num_labelsLouis Scalbert
The handling of MPLS labels in BGP faces an issue due to the way labels are stored in memory. They are stored in bgp_path_info but not in bgp_adj_in and bgp_adj_out structures. As a consequence, some configuration changes result in losing labels or even a bgpd crash. For example, when retrieving routes from the Adj-RIB-in table ("soft-reconfiguration inbound" enabled), labels are missing. bgp_path_info stores the MPLS labels, as shown below: > struct bgp_path_info { > struct bgp_path_info_extra *extra; > [...] > struct bgp_path_info_extra { > mpls_label_t label[BGP_MAX_LABELS]; > uint32_t num_labels; > [...] To solve those issues, a solution would be to set label data to the bgp_adj_in and bgp_adj_out structures in addition to the bgp_path_info_extra structure. The idea is to reference a common label pointer in all these three structures. And to store the data in a hash list in order to save memory. However, an issue in the code prevents us from setting clean data without a rework. The extra->num_labels field, which is intended to indicate the number of labels in extra->label[], is not reliably checked or set. The code often incorrectly assumes that if the extra pointer is present, then a label must also be present, leading to direct access to extra->label[] without verifying extra->num_labels. This assumption usually works because extra->label[0] is set to MPLS_INVALID_LABEL when a new bgp_path_info_extra is created, but it is technically incorrect. Cleanup the label code by setting num_labels each time values are set in extra->label[] and checking extra->num_labels before accessing the labels. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-05-17bgpd: backpressure - Fix to withdraw evpn type-5 routes immediatelyRajasekar Raja
As part of backpressure changes, there is a bug where immediate withdraw is to be sent for evpn imported type-5 prefix to clear the nh neigh and RMAC entry. Fixing this by sending withdraw immediately to keep it inline with the code today Ticket: #3905571 Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-05-13Merge pull request #15911 from ↵Russ White
opensourcerouting/feature/bgpd_dampening_per_neighbor bgpd: per-neighbor dampening support
2024-05-10Merge pull request #15614 from louis-6wind/fix-6pe-addressDonatas Abraitis
bgpd: fix ipv4-mapped ipv6 on non 6pe
2024-05-03bgpd: Reduce the nesting level for bgp_clear_damp_route()Donatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-05-03bgpd: Pass the right reuse_list when handling it via bgp_reuse_timer threadDonatas Abraitis
This fixes the crash: ``` ==14759== Invalid read of size 8 ==14759== at 0x31032B: bgp_reuselist_del (bgp_damp.c:51) ==14759== by 0x310392: bgp_damp_info_unclaim (bgp_damp.c:69) ==14759== by 0x310CD6: bgp_damp_info_free (bgp_damp.c:387) ==14759== by 0x311016: bgp_reuse_timer (bgp_damp.c:230) ==14759== by 0x4F227CC: thread_call (thread.c:2008) ==14759== by 0x4EDB7D7: frr_run (libfrr.c:1216) ==14759== by 0x1EF748: main (bgp_main.c:525) ==14759== Address 0x48 is not stack'd, malloc'd or (recently) free'd ==14759== ==14759== ==14759== Process terminating with default action of signal 11 (SIGSEGV) ==14759== at 0x59CC7F5: raise (raise.c:46) ==14759== by 0x4F10CEB: core_handler (sigevent.c:261) ==14759== by 0x59CC97F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so) ==14759== by 0x31032A: bgp_reuselist_del (bgp_damp.c:51) ==14759== by 0x310392: bgp_damp_info_unclaim (bgp_damp.c:69) ==14759== by 0x310CD6: bgp_damp_info_free (bgp_damp.c:387) ==14759== by 0x311016: bgp_reuse_timer (bgp_damp.c:230) ==14759== by 0x4F227CC: thread_call (thread.c:2008) ==14759== by 0x4EDB7D7: frr_run (libfrr.c:1216) ==14759== by 0x1EF748: main (bgp_main.c:525) ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-05-03bgpd: fix missing damp info free when cleaning bgp pathIgor Ryzhov
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2024-05-03bgpd: cleanup bgp_damp_info_freeIgor Ryzhov
bgp_damp_config, afi and safi are never used. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-05-03bgpd: Drop double-pointer for bgp_damp_info_free()Donatas Abraitis
This causes a crash using `clear ip bgp dampening <prefix>`. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-05-03bgpd: clear ip bgp dampening was not triggering the route calculation for ↵sudhanshukumar22
the prefix Description: clear ip bgp dampening was not triggering the route calculation for the prefix, Due to this prefix are not install in RIB(Zebra) and not adv to neighbor Problem Description/Summary : clear ip bgp dampening was not triggering the route calculation for the prefix, Due to this prefix are not install in RIB(Zebra) and not adv to neighbor Fix: When clear ip bgp dampening, route are put for route-calculation as that it is install in the Zebra and adv to neighbor. Signed-off-by: sudhanshukumar22 <sudhanshu.kumar@broadcom.com>
2024-05-03bgpd: peer / peer group dampening profilesDavid Schweizer
Changes implement dampening profiles for peers and peer groups. This is achieved by introducing the possibility to have multible existing dampening configurations with their own sets of parameters and lists of associated paths. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org> Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
2024-04-26Merge pull request #15845 from pguibert6WIND/bmp_improvementsDonatas Abraitis
Bmp improvements about statistics
2024-04-26Merge pull request #15723 from ↵Russ White
opensourcerouting/feature/extended_link_bw_refactored_v1 bgpd: Implement extended link-bandwidth
2024-04-26bgpd: add bmp loc-rib 64 bit gauge valuePhilippe Guibert
There is no support for option 8, as per RFC7854. Add the 64 bit counter in the peer structure. Add the missing per peer statistic. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-04-23bgpd: fix "used" json key on link-local nexthopLouis Scalbert
When a peer has no IPv6 global address to send as nexthop, it sends the IPv6 link-local instead as global. "show bgp ipv6 json" displays the same address in global and link-local scopes. > "nexthops": [ > { > "ip": "fe80::a495:38ff:fea6:6ea3", > "afi": "ipv6", > "scope": "global", > "used": true > }, > { > "ip": "fe80::a495:38ff:fea6:6ea3", > "afi": "ipv6", > "scope": "link-local" > } > ] However, "used" key is set on the global nexthop but not in link-local. It is correct but it makes difficult to test JSON to expect the usage of a link-local. The contrary is also correct. Set "used" key on the link-local nexhop instead to facilitate the tests. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-04-23bgpd: fix show run of network route-distinguisherLouis Scalbert
Route-distinguisher (RD) is not printed properly in show run: > address-family ipv6 vpn > network ff01::/64 rd (null) label 7 > network ff01::/64 rd (null) label 8 ad151f66aa ("bgpd: Refactor bgp_static_set/bgp_static_set_safi") merged bgp_static_set_safi into bgp_static_set but inadvertently omitted the handling of prd_pretty. Copy the pretty RD string if available. > address-family ipv6 vpn > network ff01::/64 rd 75:5 label 7 > network ff01::/64 rd 85:5 label 8 Fixes: ad151f66aa ("bgpd: Refactor bgp_static_set/bgp_static_set_safi") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-04-22bgpd: Implement draft-li-idr-link-bandwidth-ext-01Donatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>