summaryrefslogtreecommitdiff
path: root/bgpd/bgp_zebra.c
AgeCommit message (Collapse)Author
2025-02-13bgpd: When bgp notices a change to shared_network inform bfd of itDonald Sharp
When bgp is started up and reads the config in *before* it has received interface addresses from zebra, shared_network can be set to false in this case. Later on once bgp attempts to reconnect it will refigure out the shared_network again( because it has received the data from zebra now ). In this case tell bfd about it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-01-21bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' tableKrishnasamy R
Issue: During FRR restart, we fail to add some of the local interface's MAC to the 'bgp mac hash'. Not having local MAC in the hash table can cause lookup issues while receiving EVPN RT-2. Currently, we have code to add local MAC(bgp_mac_add_mac_entry) while handling interface add/up events in BGP(bgp_ifp_up/bgp_ifp_create). But the code 'bgp_mac_add_mac_entry' in bgp_ifp_create is not getting invoked as it is placed under a specific check(vrf->bgp link check). Fix: We can skip this check 'vrf->bgp link existence' as the tenant VRF might not have BGP instance but still we want to cache the tenant VRF local MACs. So keeping this check in bgp_ifp_create inline with bgp_ifp_up. Ticket: #4204154 Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com> (cherry picked from commit 016528364e686fb3b23a688707bd6ae6c5ea5f41)
2024-12-11bgpd: Fix bgp core with a possible Intf deleteRajasekar Raja
Although trigger unknown, based on the backtrace in one of the internal testing, we do see some delete in the Intf where we can have the peer ifp pointer null and we try to dereference it while trying to install the route leading to a crash Skip updating the ifindex in such cases and since the nexthop is not properly updated, BGP skips sending it to zebra. BackTrace: 0 0x00007faef05e7ebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 1 0x00007faef0598fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 2 0x00007faef09900dc in core_handler (signo=11, siginfo=0x7ffdde8cb4b0, context=<optimized out>) at lib/sigevent.c:274 3 <signal handler called> 4 0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc, nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273 5 bgp_zebra_announce_actual (dest=dest@entry=0x5560afcfa950, info=0x5560b21187d0, bgp=0x5560ace04df0) at bgpd/bgp_zebra.c:1521 6 0x00005560aad4bc85 in bgp_handle_route_announcements_to_zebra (e=<optimized out>) at bgpd/bgp_zebra.c:1896 7 0x00007faef09a1c0d in thread_call (thread=thread@entry=0x7ffdde8d7580) at lib/thread.c:2008 8 0x00007faef095a598 in frr_run (master=0x5560ac7e5190) at lib/libfrr.c:1223 9 0x00005560aac65db6 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:557 (gdb) f 4 4 0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc, nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273 1273 in bgpd/bgp_zebra.c (gdb) p pi->peer->ifp $26 = (struct interface *) 0x0 Ticket :#4203904 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-10-29bgpd: add `bgp ipv6-auto-ra` commandMikhail Sokolovskiy
Introduce a command to stop bgpd from enabling IPv6 router advertisement messages sending on interfaces. Signed-off-by: Mikhail Sokolovskiy <sokolmish@gmail.com>
2024-06-21bgpd: fix do not use api.backup_nexthop in ZAPI messagePhilippe Guibert
The backup_nexthop entry list has been populated by mistake, and should not. Fix this by reverting the introduced behavior. Fixes: 237ebf8d4503 ("bgpd: rework bgp_zebra_announce() function, separate nexthop handling") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> (cherry picked from commit d4390fc21795b09b84a6b95b1f8fa1ac2b3dcda9)
2024-05-06bgpd: Fix the order of NULL check and ZAPI decodeCarmine Scarpitta
When BGP receives an SRV6_LOCATOR_ADD message from zebra, it calls the `bgp_zebra_process_srv6_locator_add()` function to process the message. `bgp_zebra_process_srv6_locator_add()` decodes the message first, and then if the pointer to the default BGP instance is NULL (i.e. the default BGP instance is not configured yet), it returns early without doing anything and without using the decoded message information. This commit fixes the order of the operations executed by `bgp_zebra_process_srv6_locator_add()`. We first ensure that the default BGP instance is ready and we return early if it is not. Then, we decode the message and do something with the information contained in it. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit bdc2c7bc5473b5582419702211c22e5d29bf0631)
2024-05-06bgpd: Fix crash when deleting the SRv6 locatorCarmine Scarpitta
When BGP receives a `SRV6_LOCATOR_DEL` from zebra, it invokes `bgp_zebra_process_srv6_locator_delete` to process the message. `bgp_zebra_process_srv6_locator_delete` obtains a pointer to the default BGP instance and then dereferences this pointer. If the default BGP instance is not ready / not configured yet, this pointer this pointer is `NULL` and dereferencing it causes BGP to crash. This commit fix the issue by adding a a check to verify if the pointer is `NULL` and returning early if it is. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit ae3241b96d7be08d627f142030a41031492ffaf5)
2024-04-03bgpd: Note when receiving but not understanding a route notificationDonald Sharp
When BGP has been asked to wait for FIB installation, on route removal a return call is likely to not have the dest since BGP will have cleaned up the node, entirely. Let's just note that the prefix cannot be found if debugs are turned on and move on. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 7c603146529dc90f2d948e1943750efb1911c8ba)
2024-02-09bgpd: fix route recursion on leaked routesLouis Scalbert
Leaked recursive routes are not resolved. > VRF r1-cust1: > B> 5.1.0.0/24 [200/98] via 99.0.0.1 (recursive), weight 1, 00:00:08 > * via 192.168.1.2, r1-eth4, weight 1, 00:00:08 > B>* 99.0.0.1/32 [200/0] via 192.168.1.2, r1-eth4, weight 1, 00:00:08 > VRF r1-cust4: > B 5.1.0.0/24 [20/98] via 99.0.0.1 (vrf r1-cust1) inactive, weight 1, 00:00:08 > B>* 99.0.0.1/32 [20/0] via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:08 When announcing the routes to zebra, use the peer of the ultimate bgp path info instead of the one of the first parent path info to determine whether the route is recursive. The result is: > VRF r1-cust4: > B> 5.1.0.0/24 [20/98] via 99.0.0.1 (vrf r1-cust1) (recursive), weight 1, 00:00:02 > * via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:02 > B>* 99.0.0.1/32 [20/0] via 192.168.1.2, r1-eth4 (vrf r1-cust1), weight 1, 00:00:02 Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-02-07bgpd: fix flushing ipv6 flowspec entries when peering stopsPhilippe Guibert
When a BGP flowspec peering stops, the BGP RIB entries for IPv6 flowspec entries are removed, but not the ZEBRA RIB IPv6 entries. Actually, when calling bgp_zebra_withdraw() function call, only the AFI_IP parameter is passed to the bgp_pbr_update_entry() function in charge of the Flowspec add/delete in zebra. Fix this by passing the AFI parameter to the bgp_zebra_withdraw() function. Note that using topotest does not show up the problem as the flowspec driver code is not present and was refused. Without that, routes are not installed, and can not be uninstalled. Fixes: 529efa234655 ("bgpd: allow flowspec entries to be announced to zebra") Link: https://github.com/FRRouting/frr/pull/2025 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-01-09Merge pull request #15001 from pguibert6WIND/zebra_nexthop_reworkRuss White
Zebra nexthop rework
2023-12-27bgpd: revamp evpn debugs nexthop and l3vniChirag Shah
Add nexthop fied when import/unimport evpn route in vrf, print bgp vrf instance name which contains "VRF" keyword. Include pathcount which is list of paths linked to nexthop. add and delete l3vni to keep symmetric "L3VNI" keyword as used in other debug statements. Ticket: #3671288 Testing Done: 2023/12/27 05:10:03.339616 BGP: [HPE1G-3H7F2] ... new pi VRF vrf2 dest 0x55663e8372c0 (l 2) pi 0x55663e8374d0 (l 1, f 0x4010) nh 6.0.0.1 2023/12/27 05:58:56.650116 BGP: [MC0JJ-7ZYQB] ... delete pi VRF vrf2 dest 0x55663e885110 (l 5) pi 0x55663e8851e0 (l 1, f 0x4098) nh 6.0.0.1 2023/12/27 05:10:03.339581 BGP: [P4TBX-3W31N] evpn VRF vrf2 nh 6.0.0.1 rmac 00:02:00:00:00:04 add to zebra 2023/12/27 06:13:12.685906 BGP: [SWSCZ-2Z6M4] evpn vrf VRF vrf1 nh 6.0.0.1 del to zebra 2023/12/27 05:10:03.339603 BGP: [Y2EAK-4N7FV] path 60.1.1.111/32 linked to VRF vrf2 nh 6.0.0.1 pathcount 0 2023/12/27 05:58:56.650125 BGP: [GVE17-CSNTB] path 81.1.1.0/24 unlinked from VRF vrf2 nh 6.0.0.1 pathcount 16 2023/12/27 05:08:10.108038 ZEBRA: [Q8ZEK-CT776] Send L3VNI ADD 104001 VRF vrf1 RMAC 00:04:ba:10:10:62 VRR 1c:34:da:19:59:62 local-ip 6.0.0.31 filter none to bgp 2023/12/27 05:08:26.043121 ZEBRA: [R43YF-2MKZ3] Send L3VNI DEL 104001 VRF vrf1 to bgp Signed-off-by: Chirag Shah <chirag@nvidia.com>
2023-12-18bgpd, lib: add zapi_route_set_nhg_id() supportPhilippe Guibert
There is no function that both sets the nhg id, and sets the ZAPI_MESSAGE_NHG flag if the nhg id is valid. Create a ZAPI API to do this, and apply the changes wherever needed. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-12-18bgpd: rework bgp_zebra_announce() function, separate nexthop handlingPhilippe Guibert
Separate the processing in bgp_zebra_announce(), by separating the nexthop code in a separate function called bgp_zebra_announce_parse_nexthop(). This commit does not bring any functional change. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-12-18bgpd: rework debug nexthop in separate functionPhilippe Guibert
When adding/removing a route, the next-hop can be dumped with debugging turned on. Move this function in a separate function. There is no other change in this commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-11-29bgpd: Free Memory for SRv6 Functions and Locator ChunksKeelan10
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks. The list callback deletion functions have been set. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180 ================================================================= ==4180==ERROR: LeakSanitizer: detected memory leaks Direct leak of 544 byte(s) in 2 object(s) allocated from: #0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f8d1709f238 in qcalloc lib/memory.c:105 #2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591 #3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712 #4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758 #5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849 #6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299 #7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704 #8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164 #9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459 #10 0x7f8d1713f034 in event_call lib/event.c:1974 #11 0x7f8d1708242b in frr_run lib/libfrr.c:1214 #12 0x55d5db99d19d in main bgpd/bgp_main.c:510 #13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Direct leak of 296 byte(s) in 1 object(s) allocated from: #0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f8d1709f238 in qcalloc lib/memory.c:105 #2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135 #3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144 #4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459 #5 0x7f8d1713f034 in event_call lib/event.c:1974 #6 0x7f8d1708242b in frr_run lib/libfrr.c:1214 #7 0x55d5db99d19d in main bgpd/bgp_main.c:510 #8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
2023-11-25Merge pull request #14867 from opensourcerouting/zclient-options-cleanupDonald Sharp
*: clean up `zclient` options
2023-11-23*: add `zclient_options_sync`David Lamparter
... and use it instead of fiddling with the `.synchronous` field. (Make it const while at it.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-11-22*: convert `struct interface->connected` to DLISTDavid Lamparter
Replace `struct list *` with `DLIST(if_connected, ...)`. NB: while converting this, I found multiple places using connected prefixes assuming they were IPv4 without checking: - vrrpd/vrrp.c: vrrp_socket() - zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(), irdp_advert_off() (these fixes are really hard to split off into separate commits as that would require going back and reapplying the change but with the old list handling) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-11-22Merge pull request #14850 from donaldsharp/IFNAMSIZ_GET_YOUR_SHIT_TOGETHERDonatas Abraitis
*: Let's use the native IFNAMSIZ instead of INTERFACE_NAMSIZ
2023-11-21*: Let's use the native IFNAMSIZ instead of INTERFACE_NAMSIZDonald Sharp
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ is the standard for interface name length on all platforms that FRR currently compiles on. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-11-20bgpd: use `zclient->nexthop_update`David Lamparter
Same as before. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-11-13bgpd: Used %pBD instead of %pRNDonald Sharp
Let's use the natural data structure in bgp for the prefix display instead of a bunch of places where we call a translator function. The %pBD does this and actually ensures data is correct. Also fix a few spots in bgp_zebra.c where the cast to a NULL pointer causes the catcher functionality to not work and fix the resulting crash that resulted. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-11-10bgpd: Add guard for `zlog_debug`Carmine Scarpitta
Add guard for `zlog_debug` when bgpd is not connected to zebra or zebra does not know the bgp instance. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2023-11-07*: Move distance related defines into their own headerDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-11-02lib: convert if_zapi_callbacks into actual hooksDavid Lamparter
...so that multiple functions can be subscribed. The create/destroy hooks are renamed to real/unreal because that's what they *actually* signal. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-10-31Merge pull request #14388 from pguibert6WIND/redistribute_table_bgp_2Russ White
Redistribute table bgp without copying data to the default routing table
2023-10-20bgpd: add redistribute table-direct supportPhilippe Guibert
Add the 'redistribute table-direct' command under the bgp address-family node. Handle the table-direct support wherever needed in the BGP code. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-10-18bgpd: fix hardset l3vpn label available in mpls poolPhilippe Guibert
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-10-12bgpd: Remove unused cumulative bandwidth variableDonald Sharp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-12bgpd: Just pass down the Bandwidth unmodified so that Zebra can use itDonald Sharp
Instead of scaling the bandwith to something between 1 and 100, just send down the bandwidth Available for the link. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-10Revert "bgpd: do not announce link-state routes to zebra"Donald Sharp
This reverts commit 39fb34275f827b3e1134549ed1731d74e72e6c79.
2023-10-07*: remove ZEBRA_INTERFACE_VRF_UPDATEanlan_cs
Currently when one interface changes its VRF, zebra will send these messages to all daemons in *order*: 1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF ) 2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF ) 3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF ) When daemons deal with `VRF_UPDATE`, they use `zebra_interface_vrf_update_read()->if_lookup_by_name()` to check the interface exist or not in old VRF. This check will always return *NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't find this interface in old VRF. Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough, they will deal with RB tree, so don't send this `VRF_UPDATE` message when vrf changes. Since all daemons have good mechanism to deal with changing vrf, and don't use this `VRF_UPDATE` mechanism. So, it is safe to completely remove all the code with `VRF_UPDATE`. Signed-off-by: anlan_cs <anlan_cs@tom.com>
2023-09-26Merge pull request #12649 from louis-6wind/bgp-link-stateRuss White
bgpd: add basic support of BGP Link-State RFC7752
2023-09-20bgpd,lib,sharpd,zebra: srv6 introduce multiple segs/SIDs in nexthopDmytro Shytyi
Append zebra and lib to use muliple SRv6 segs SIDs, and keep one seg SID for bgpd and sharpd. Note: bgpd and sharpd compilation relies on the lib and zebra files, i.e if we separate this: lib or zebra or bgpd or sharpd in different commits - this will not compile. Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
2023-09-18bgpd: do not announce link-state routes to zebraLouis Scalbert
Link-state prefixes are only intended to be read for a link-state consumer (i.e. a controler). They cannot be installed in Forwarding Information Base (FIB). Do not announce them to zebra. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2023-09-10bgpd: bgp_fsm_change_status/BGP_TIMER_ON and BGP_EVENT_ADDDonald Sharp
Modify bgp_fsm_change_status to be connection oriented and also make the BGP_TIMER_ON and BGP_EVENT_ADD macros connection oriented as well. Attempt to make peer_xfer_conn a bit more understandable because, frankly it was/is confusing. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-09-10bgpd: peer_established should be connection orientedDonald Sharp
The peer_established function should be connection oriented. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-08-31Merge pull request #14282 from pguibert6WIND/fix_redistribute_table_flushDonatas Abraitis
bgpd: fix redistribute table command after bgp restarts
2023-08-29bgpd: fix redistribute table command after bgp restartsPhilippe Guibert
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-22bgpd: Convert from struct bgp_node to struct bgp_destYuqing Zhao
This is based on @donaldsharp's work The current code base is the struct bgp_node data structure. The problem with this is that it creates a bunch of extra data per route_node. The table structure generates ‘holder’ nodes that are never going to receive bgp routes, and now the memory of those nodes is allocated as if they are a full bgp_node. After splitting up the bgp_node into bgp_dest and route_node, the memory of ‘holder’ node which does not have any bgp data will be allocated as the route_node, not the bgp_node, and the memory usage is reduced. The memory usage of BGP node will be reduced from 200B to 96B. The total memory usage optimization of this part is ~16.00%. Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Yuqing Zhao <xiaopanghu99@163.com>
2023-08-13Merge pull request #14126 from LabNConsulting/ziemba-pbr-actions-manglingDonatas Abraitis
pbrd: (3/3) add packet mangling actions (src/dst ip-addr/port, dscp, ecn)
2023-08-09Merge pull request #14099 from lkClare/formated_sync_0727Donatas Abraitis
bgpd: bgp_path_info_extra memory optimization
2023-08-08pbrd: add explicit 'family' field for rulesG. Paul Ziemba
In the netlink-mediated kernel dataplane, each rule is stored in either an IPv4-specific database or an IPv6-specific database. PBRD opportunistically gleans each rule's address family value from its source or destination IP address match value (if either exists), or from its nexthop or nexthop-group (if it exists). The 'family' value is particularly needed for netlink during incremental rule deletion when none of the above fields remain set. Before now, this address family has been encoded by occult means in the (possibly otherwise unset) source/destination IP match fields in ZAPI and zebra. This commit documents the reasons for maintaining the 'family' field in the PBRD rule structure, adds a 'family' field in the common lib/pbr.h rule structure, and carries it explicitly in ZAPI. Signed-off-by: G. Paul Ziemba <paulz@labn.net>
2023-08-08bgpd: bgp_path_info_extra memory optimizationValerian_He
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-03bgpd: Have bgp notice the zebra ability to use v6_with_v4_nexthopsDonald Sharp
Store the data. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-07-26Merge pull request #14064 from donaldsharp/pim_cleanupmobash-rasool
Cleanup from examining gcov runs
2023-07-21bgpd: Cleanup bgp_zebra_announce_default to be cleanerDonald Sharp
Over time the bgp_zebra_announce_default function has gotten slightly convoluted, clean it up so it's easier to read Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-07-20lib: zapi PBR common encode/decodeG. Paul Ziemba
bgpd, pbrd: use common pbr encoder zebra: use common pbr decoder tests: pbr_topo1: check more filter fields Purpose: 1. Reduce likelihood of zapi format mismatches when adding PBR fields due to multiple parallel encoder implementations 2. Encourage common PBR structure usage among various daemons 3. Reduce coding errors via explicit per-field enable flags Signed-off-by: G. Paul Ziemba <paulz@labn.net>
2023-07-19pbrd: add vlan filters pcp/vlan-id/vlan-flags; ip-protocol any (zapi)G. Paul Ziemba
Subset: ZAPI changes to send the new data Also adds filter_bm field; currently for PBR_FILTER_PCP, but in the future to be used for all of the filter fields. Changes by: Josh Werner <joshuawerner@mitre.org> Eli Baum <ebaum@mitre.org> G. Paul Ziemba <paulz@labn.net> Signed-off-by: G. Paul Ziemba <paulz@labn.net>