summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-10build: FRR 9.2 development versionfrr-9.2-devDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-10-10Merge pull request #13617 from anlancs/fix/pimd-remove-pimreg-vrfbase_9.1mergify/bp/dev/9.1/pr-13617mobash-rasool
pimd: Fix missing pimreg interface
2023-10-10Merge pull request #14535 from opensourcerouting/fix/bgp_aggregate_stuffRuss White
bgpd: Drop redundant assignment for aspath segment type and length
2023-10-10Merge pull request #14515 from mjstapp/fix_nhg_intf_uninstallChirag Shah
zebra: be more careful removing 'installed' flag from nhgs
2023-10-10Merge pull request #14548 from raja-rajasekar/frr_dev1Russ White
zebra: Prevent leaking ctx memory in err condition
2023-10-10Merge pull request #14550 from Keelan10/fix-nexthop_group-leakDonald Sharp
zebra: Free nexthop_group
2023-10-10zebra: Free nexthop_groupKeelan10
`ng` was not properly freed, leading to a memory leak. The commit calls `nexthop_group_delete` to free memory associated with `ng`. The ASan leak log for reference: ``` *********************************************************************************** Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308 ================================================================= ==24308==ERROR: LeakSanitizer: detected memory leaks Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270 #3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681 #4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 #8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 #9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 #10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 #11 0x7f4f475dc7f2 in event_call lib/event.c:1969 #12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 #13 0x562ded69e818 in main zebra/main.c:486 #14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) Indirect leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105 #2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376 #3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914 #4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444 #5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682 #6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972 #7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993 #8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860 #9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138 #10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178 #11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228 #12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266 #13 0x7f4f475dc7f2 in event_call lib/event.c:1969 #14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213 #15 0x562ded69e818 in main zebra/main.c:486 #16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s). *********************************************************************************** ``` Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
2023-10-10Merge pull request #14451 from m-varasteh/ospf-coverity-issuesDonatas Abraitis
ospfd: a possible fix for TAINTED_SCALAR coverity issues
2023-10-09Merge pull request #14533 from mjstapp/fix_rule_notify_vrfDonald Sharp
lib,*: add vrf id to pbr rule results zapi message
2023-10-09zebra: Prevent leaking ctx memory in err conditionRajasekar Raja
When netlink_link_change() errors out for a new link for interface without MTU set, the allocated ctx is not freed.. Adding code for correctness Ticket# 3628313 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2023-10-09Merge pull request #14543 from mjstapp/fix_pbr_rule_uniqueDonald Sharp
zebra: add zclient to iprules key
2023-10-08Merge pull request #10733 from anlancs/zebra-remove-updateRafael Zalamena
zebra: remove ZEBRA_INTERFACE_VRF_UPDATE
2023-10-08Merge pull request #14541 from idryzhov/isis-fix-cb-destroyRafael Zalamena
isisd: remove redundant northbound destroy callbacks
2023-10-07doc: replace commands list with header fileanlan_cs
Signed-off-by: anlan_cs <anlan_cs@tom.com>
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-10-06zebra: add zclient to iprules keyMark Stapp
Include a zclient value in the hash and tree key computations for iprules in zebra: clients may collide without this. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-10-06isisd: remove redundant northbound destroy callbacksIgor Ryzhov
Fixes startup warnings: ``` ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-segs-left' ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-end-pop' ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-h-encaps' ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'destroy' callback for '/frr-isisd:isis/instance/segment-routing-srv6/msd/node-msd/max-end-d' ``` Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
2023-10-05lib,*: add vrf id to pbr rule results zapi messageMark Stapp
The iprule/pbr rule object has a vrf id, and zebra uses that internally, but the vrf id isn't returned to clients who install rules and are waiting for results. Include the vrf_id sent by the client in the zapi result notification message; update the existing clients so they decode the id. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-10-05bgpd: Drop redundant assignment for aspath segment type and lengthDonatas Abraitis
They are already initialized via assegment_new(). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-10-05Merge pull request #14534 from mjstapp/fix_topo_nhgidDonald Sharp
tests: locate nhg id from json output in all_proto_startup
2023-10-05tests: locate nhg id from json output in all_proto_startupMark Stapp
Don't hard-code a sharpd nhg id: those values aren't stable if the daemons/protos/route-types change. Use json show output to find the id in the 'resilient' nhg test case in the all_protocol_startup suite. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-10-05Merge pull request #14517 from adrianomarto/pim-msdp-sa-rpDonald Sharp
pimd: Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA message
2023-10-05Merge pull request #14474 from donaldsharp/strsep_fixupRafael Zalamena
staticd: Memory leak of string in staticd
2023-10-04staticd: Memory leak of string in staticdDonald Sharp
XSTRDUP and then calling strsep mangles the pointer returned by XSTRDUP. Keep a copy of the orig and when we are done, free that instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-10-04Merge pull request #14527 from ↵Donald Sharp
opensourcerouting/fix/guard_debug_messages_for_ttl bgpd: Add guards for zlog_debug when setting GTSM for the peer
2023-10-04pimd: Indicating the rp in the msdp sa messageAdriano Marto Reis
Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA message The RFC-3618, section 12.2.1, describes the fields included in the MSDP SA message. The "RP address" field is "the address of the RP in the domain the source has become active in". In the most common case, we will establish an MSDP connection from RP to RP. However, there are cases where we want to establish a MSDP connection from an interface/address that is not the RP. Section 3 of RFC-3618 describes that scenario as "intermediate MSDP peer". Moreover, the RP could be another router in the PIM domain - not the one establishing the MSDP connection. The current implementation could be problematic even with a single router per PIM domain. Consider the following scenario: * There are two PIM domains, each one with a single router. * The two routers are connected via two independent networks. Let's say that is to provide redundancy. * The routers are configured to establish two MSDP connections, one on each network (redundancy again). * A multicast source becomes active on the router 1. It will be communicated to router 2 via two independent MSDP SA messages, one per MSDP connection. * Without these changes, each MSDP SA message will indicate a different RP. * Both RP addresses will pass the RPF check, and both MSDP sources will be accepted. * If the router has clients interested in that multicast group, it will send PIM Join messages to both RPs and start receiving the multicast traffic from both. With the changes included in this commit, the multicast source available in router 1 would still be communicated to router 2 twice. But both MSDP SA messages would indicate the same RP, and one of them would be discarded due to failure in the RPF-check failure. Also, the changes allow us to define the RP that will be included in the MSDP SA message, and it could be one of the interfaces used to establish the MSDP connection, some other interface on the router, a loopback interface, or another router in the PIM domain. These changes should not create compatibility issues. As I mentioned, we usually establish MSDP connections from RP to RP. In this case, the result will be the same. We would still indicate the address used to establish the MSDP connection if the RP is not set - I wonder if that should even be a valid configuration. Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
2023-10-03bgpd: Add guards for zlog_debug when setting GTSM for the peerDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-10-03Merge pull request #14511 from ↵Russ White
opensourcerouting/fix/bgpd_software_version_capability bgpd: Validate maximum length of software version when handling via dynamic caps
2023-10-03Merge pull request #14472 from opensourcerouting/plist-dupRuss White
lib: fix route map duplicated prefix removal evaluation
2023-10-03Merge pull request #13814 from pguibert6WIND/comm_list_expanded_match_no_exactRuss White
bgpd: add match community "any" to match any incoming community
2023-10-03Merge pull request #14508 from LabNConsulting/chopps/darr-use-frrmemfuncDonatas Abraitis
lib: use XREALLOC over realloc avoid coverity warning
2023-10-03ospfd: a possible fix for TAINTED_SCALAR coverity issuesMahdi Varasteh
Signed-off-by: Mahdi Varasteh <varasteh@amnesh.ir>
2023-10-02Merge pull request #14519 from anlancs/fix/doc-zebra-valuesDonald Sharp
2023-10-02topotests: add bgp_large_comm_list_match testPhilippe Guibert
Add a topotest to check for proper functioning of the bgp large community list match operation under a route-map. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-10-02bgpd: add 'match community-list any' functionPhilippe Guibert
There is no match mechanism to match one community from the incoming community-list. Add the 'any' keyword to the 'match route-map' command of communit-list and large-community-list. > match community-list AAA any > match large-community-list AAA any Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-10-01doc: adjust protocol command values for zebraanlan_cs
Adjust protocol command values for zebra based on latest code. Also, expand the field width to fit the length. Signed-off-by: anlan_cs <anlan_cs@tom.com>
2023-09-29zebra: be more careful removing 'installed' flag from nhgsMark Stapp
When interface addresses change, we examine nhgs associated with the interface in case they need to be reinstalled. As part of that, we may need to reinstall ecmp nhgs that use the interface being examined - but not always. Signed-off-by: Mark Stapp <mjs@labn.net>
2023-09-29Merge pull request #14510 from opensourcerouting/fix/coccinelle_issuesDonald Sharp
A couple minor fixes
2023-09-29Merge pull request #12409 from FRIDM636/masterDonatas Abraitis
zebra: delete label chunk upon release
2023-09-29tests: Make sure we have a valid FRRouting software version stringDonatas Abraitis
It can't begin with anything else, otherwise something is broken on the wire. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-29bgpd: Validate maximum length of software version when handling via dynamic capsDonatas Abraitis
We should not allow exceeding the stream's length, and also software version can't be larger than 64 bytes. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-29*: Do not cast to the same type as the destination isDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-29zebra: delete label chunk upon releasefmihoub6WIND
In zebra/label_manager.c the releasing of the label chunk is done by disowning the chunk to the system. The presence of this system label chunk will cause label assignment to fail for this use case example: label chunk ospf: 300-320 label chunk system: 510-520 label chunk isis: 1200-1300 Then we try to allocate the chunk 500-530, we get this error: "Allocation of mpls label chunk [500/530] failed" The error is raised when the below condition is true: /* if chunk is used, cannot honor request */ if (lmc->proto != NO_PROTO) return NULL; Delete the label chunk instead of disowning it when the label releasing is done. Signed-off-by: Farid MIHOUB <farid.mihoub@6wind.com>
2023-09-29zebra: dump label table informationfmihoub6WIND
Add the new command "show debugging labeltable" to show allocated label chunks in the label table managed with label_manager.c Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2023-09-29zebra: Drop new lines from zlog_debug for dpdk debug messagesDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-09-29Merge pull request #14507 from qlyoung/fix-doc-more-doc-moreDonatas Abraitis
More developer doc fixes
2023-09-29Merge pull request #14506 from louis-6wind/fix-bgp-link-stateDonatas Abraitis
bgpd: fix link state coverity scan issues
2023-09-29lib: use XREALLOC over realloc avoid coverity warningChristian Hopps
I believe coverity is complaining that the current code does not handle the realloc fail case, in which case the original pointer is not freed, but NULL is returned. The code assert()s it's not failed but that is not strong enough it needs to abort which XREALLOC does and is a better integration into FRR-inrfa anyway. Signed-off-by: Christian Hopps <chopps@labn.net>
2023-09-29Merge pull request #14505 from qlyoung/fix-rtd-build-sphinx-versionmobash-rasool
doc: unpin sphinx from 4.0.2
2023-09-28Merge pull request #14503 from ↵Donald Sharp
opensourcerouting/fix/add_bgp_neighbor_capability_dynamic doc: Add `neighbor capability dynamic` command