summaryrefslogtreecommitdiffstats
path: root/lib/zclient.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* lib: fix handle seg6local routes on default vrfPhilippe Guibert2023-04-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An L3VPN network can be configured on the main BGP instance, with an SRv6 SID. By declaring a network, a seg6local route is created but remains invalid. The below BGP VPN configuration the default VRF has been used: > router bgp 1 > address-family ipv6 unicast > sid vpn export auto > rd vpn export 1:30 > rt vpn both 77:77 > import vpn > export vpn > network 2001:7::/64 > exit-address-family The below seg6local route has been added: > # show ipv6 route > [..] > B 2001:db8:2:2:300::/128 [20/0] is directly connected, unknown inactive, seg6local End.DT6 table 254, seg6 ::, weight 1, 00:00:07 > When creating the seg6local route, an interface is used as nexthop. The interface index is obtained from the vrf identifier. This is true when using VRF interfaces, but is wrong when using the lo interface which usually has the '1' ifindex whereas the vrf id for the default VRF is 0. Get the appropriate index from the vrf identifier. The below seg6local route is visible: > # show ipv6 route > [..] > B>* 2001:db8:1:1:300::/128 [20/0] is directly connected, lo, seg6local End.DT6 table 254, seg6 ::, weight 1, 00:00:15 > Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* lib: Ensure the safi is set to a sensible valueDonald Sharp2023-03-291-0/+2
| | | | | | | The safi has no 0 value which it is set to as part of the initialization. Let's just set it to a sensible value. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert event.h to frrevent.hDonald Sharp2023-03-241-1/+1
| | | | | | | We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert `struct event_master` to `struct event_loop`Donald Sharp2023-03-241-1/+1
| | | | | | Let's find a better name for it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert THREAD_XXX macros to EVENT_XXX macrosDonald Sharp2023-03-241-7/+7
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert struct thread_master to struct event_master and it's ilkDonald Sharp2023-03-241-1/+1
| | | | | | | Convert the `struct thread_master` to `struct event_master` across the code base. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert thread_add_XXX functions to event_add_XXXDonald Sharp2023-03-241-11/+11
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename `struct thread` to `struct event`Donald Sharp2023-03-241-3/+3
| | | | | | | | | Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename thread.[ch] to event.[ch]Donald Sharp2023-03-241-1/+1
| | | | | | | | | | | This is a first in a series of commits, whose goal is to rename the thread system in FRR to an event system. There is a continual problem where people are confusing `struct thread` with a true pthread. In reality, our entire thread.c is an event system. In this commit rename the thread.[ch] files to event.[ch]. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12780 from opensourcerouting/spdx-license-idDonald Sharp2023-02-171-16/+1
|\ | | | | *: convert to SPDX License identifiers
| * *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-16/+1
| | | | | | | | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | Merge pull request #12494 from louis-6wind/ext_admin_groupOlivier Dugeon2023-02-151-21/+44
|\ \ | | | | | | lib,zebra,isisd: add support for extended admin group RFC7308
| * | lib,yang,zebra: add extended admin-group supportLouis Scalbert2023-02-101-21/+44
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the support of Extended Admin-Group (RFC7308) to the zebra interface link-params Traffic-Engineering context. Extended admin-groups can be configured with the affinity-map: > affinity-map blue bit-position 221 > int eth-rt1 > link-params > affinity blue > exit-link-params Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* / lib: add label_type as field in zapi_nexthopStephen Worley2023-02-141-0/+3
|/ | | | | | | | | | Add the ability to specify the label type along with the labels you are passing to zebra in zapi_nexthop. This is needed as we abstract the label code to be re-used by evpn as well as mpls. Protocols need to be able to set the type of label they have attached. Signed-off-by: Stephen Worley <sworley@nvidia.com>
* lib: Add missing enum's to switch statementDonald Sharp2023-01-311-2/+6
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: traffic control ZAPISiger Yang2022-11-221-0/+91
| | | | | | | This commit adds ZAPI encoders & decoders for traffic control operations, which include tc_qdisc, tc_class and tc_filter. Signed-off-by: Siger Yang <siger.yang@outlook.com>
* Merge pull request #12219 from cscarpitta/feature/srv6-usid-behavior-supportDonatas Abraitis2022-11-141-0/+2
|\ | | | | bgpd, zebra: Add support for SRv6 uSID Behaviors
| * lib,zebra: Send SRv6 locator flags over the ZAPICarmine Scarpitta2022-10-291-0/+2
| | | | | | | | | | | | | | | | In this commit, we extend the ZAPI to support encoding and decoding the locator flags contained in the messages exchanged between zebra and the routing daemons. Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
* | *: Add ability to encode / decode resilence down zapiDonald Sharp2022-11-041-0/+4
| | | | | | | | | | | | | | | | At this point add abilty for the encode/decode of the resilience down ZAPI to zebra. Just hookup sharpd at this point in time. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | lib: fix coverity scan failure in zebra_interface_link_params_read()Louis Scalbert2022-10-271-2/+3
| | | | | | | | | | | | | | | | | | The code was working but the coverity scan reported a failure. Clarify the code to make the coverity scan happy. Fixes: fe0a129687 ("lib,zebra: link-params are not flushed after no enable") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* | lib,zebra: link-params are not flushed after no enableLouis Scalbert2022-10-171-22/+47
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Daemons like isisd continue to use the previous link-params after they are removed from zebra. For example, >r0# sh run zebra > (...) > interface eth-rt1 > link-params > enable > metric 100 > exit-link-params > r0# conf > r0(config)# interface eth-rt1 > r0(config-if)# link-params > r0(config-link-params)# no enable After "no enable", "sh run zebra" displays no more link-params context. The "no enable" causes the release of the "link_params" pointer within the "interface" structure. The zebra function to update daemons with a ZEBRA_INTERFACE_LINK_PARAMS zapi message is called but the function returns without doing anything because the "link_params" pointer is NULL. Therefore, the "link_params" pointers are kept in daemons. When the zebra "link_params" pointer is NULL: - Send a zapi link param message that contains no link parameters instead of sending no message. - At reception in daemons, the absence of link parameters causes the release of the "link_params" pointer. Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* lib: Fix memory leak in `zclient_send_localsid()`Carmine Scarpitta2022-08-241-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2` topotests with `--valgrind-memleaks` gives several memory leak errors. This is due to the way FRR daemons pass local SIDs to zebra: to send a local SID to zebra, FRR daemons call the `zclient_send_localsid()` function. The `zclient_send_localsid()` function performs the following sequence of operations: * create a temporary `struct nexthop`; * call `nexthop_add_srv6_seg6local()` to fill the `struct nexthop` with the proper local SID information; * create a `struct zapi_route` and call `zapi_nexthop_from_nexthop()` to copy the information from the `struct nexthop` to the `struct zapi_route`; * send the `struct zapi_route` to zebra through the ZAPI. The `nexthop_add_srv6_seg6local()` function uses `XCALLOC()` to allocate memory for the SRv6 nexthop. This memory is never freed. Creating a temporary `struct nexthop` is unnecessary, as the local SID information can be pushed directly to the `struct zapi_route`. This patch simplifies the implementation of `zclient_send_localsid()` by avoiding using the temporary `struct nexthop`. This eliminates the need to use `nexthop_add_srv6_seg6local()` to fill the `struct nexthop` and consequently fixes the memory leak. Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
* lib, zebra, bgpd: Move route EVPN flag to nexthopXiao Liang2022-06-101-2/+5
| | | | | | | Multipath route may have mixed nexthops of EVPN and IP unicast. Move EVPN flag to nexthop to support such cases. Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
* *: use FRR interface name definition everywhereRafael Zalamena2022-05-021-2/+2
| | | | | | | Don't rely on the OS interface name length definition and use the FRR definition instead. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
* *: add SAFI argument to zclient_send_rnhDavid Lamparter2022-03-271-4/+4
| | | | | | Just pushing that SAFI_UNICAST up 1 level to the caller. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: When matching against a nexthop send and process what it matched againstDonald Sharp2022-03-121-1/+18
| | | | | | | | | | | | | | | | | | Currently the nexthop tracking code is only sending to the requestor what it was requested to match against. When the nexthop tracking code was simplified to not need an import check and a nexthop check in b8210849b8ac1abe2d5d9a5ab2459abfde65efa5 for bgpd. It was not noticed that a longer prefix could match but it would be seen as a match because FRR was not sending up both the resolved route prefix and the route FRR was asked to match against. This code change causes the nexthop tracking code to pass back up the matched requested route (so that the calling protocol can figure out which one it is being told about ) as well as the actual prefix that was matched to. Fixes: #10766 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* lib: Fix zclient.c `enum event` to `enum zclient_event`Donald Sharp2022-03-021-3/+3
| | | | | | | zclient.c is using `enum event` let's rename it to a better named data structure `enum zclient_event`. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Change thread->func to return void instead of intDonald Sharp2022-02-241-16/+18
| | | | | | | The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: rework renaming the default VRFIgor Ryzhov2021-12-211-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is possible to rename the default VRF either by passing `-o` option to zebra or by creating a file in `/var/run/netns` and binding it to `/proc/self/ns/net`. In both cases, only zebra knows about the rename and other daemons learn about it only after they connect to zebra. This is a problem, because daemons may read their config before they connect to zebra. To handle this rename after the config is read, we have some special code in every single daemon, which is not very bad but not desirable in my opinion. But things are getting worse when we need to handle this in northbound layer as we have to manually rewrite the config nodes. This approach is already hacky, but still works as every daemon handles its own NB structures. But it is completely incompatible with the central management daemon architecture we are aiming for, as mgmtd doesn't even have a connection with zebra to learn from it. And it shouldn't have it, because operational state changes should never affect configuration. To solve the problem and simplify the code, I propose to expand the `-o` option to all daemons. By using the startup option, we let daemons know about the rename before they read their configs so we don't need any special code to deal with it. There's an easy way to pass the option to all daemons by using `frr_global_options` variable. Unfortunately, the second way of renaming by creating a file in `/var/run/netns` is incompatible with the new mgmtd architecture. Theoretically, we could force daemons to read their configs only after they connect to zebra, but it means adding even more code to handle a very specific use-case. And anyway this won't work for mgmtd as it doesn't have a connection with zebra. So I had to remove this option. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* *: cleanup ifp->vrf_idIgor Ryzhov2021-11-221-8/+7
| | | | | | | Since f60a1188 we store a pointer to the VRF in the interface structure. There's no need anymore to store a separate vrf_id field. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* lib: rename bfd function to reflect real functionalityIgor Ryzhov2021-11-151-1/+1
| | | | Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* Merge pull request #9854 from opensourcerouting/zapi-call-tableRuss White2021-10-261-310/+45
|\ | | | | *: convert zclient callbacks to table
| * *: convert zclient callbacks to tableDavid Lamparter2021-10-201-310/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | This removes a giant `switch { }` block from lib/zclient.c and harmonizes all zclient callback function types to be the same (some had a subset of the args, some had a void return, now they all have ZAPI_CALLBACK_ARGS and int return.) Apart from getting rid of the giant switch, this is a minor security benefit since the function pointers are now in a `const` array, so they can't be overwritten by e.g. heap overflows for code execution anymore. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* | lib: fix srv6 route hardcode with BGPHiroki Shirokura2021-10-261-1/+1
| | | | | | | | | | | | | | | | | | zclient_send_localsid is called by various routing protocol daemons. To set the srv6 endpoint function. Fix a hard-coded error in the initial implementation. Before this PR, the srv6 function will be registered to zebra as a BGP route even if isisd executes zclient_send_localsid. Signed-off-by: Hiroki Shirokura <hiroki.shirokura@linecorp.com>
* | lib: finish fixing spelling in lib filesewlumpkin2021-10-221-10/+10
|/ | | | Signed-off-by: ewlumpkin <ewlumpkin@gmail.com>
* lib: allow to create interfaces in non-existing VRFsIgor Ryzhov2021-10-191-2/+4
| | | | | | | | | | | | | | | | | | | | | It allows FRR to read the interface config even when the necessary VRFs are not yet created and interfaces are in "wrong" VRFs. Currently, such config is rejected. For VRF-lite backend, we don't care at all about the VRF of the inactive interface. When the interface is created in the OS and becomes active, we always use its actual VRF instead of the configured one. So there's no need to reject the config. For netns backend, we may have multiple interfaces with the same name in different VRFs. So we care about the VRF of inactive interfaces. And we must allow to preconfigure the interface in a VRF even before it is moved to the corresponding netns. From now on, we allow to create multiple configs for the same interface name in different VRFs and the necessary config is applied once the OS interface is moved to the corresponding netns. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* lib, zebra: Send safi for rnh resolutionDonald Sharp2021-09-271-0/+2
| | | | | | | | | Pass down the safi for when we need address resolution. At this point in time we are hard coding the safi to SAFI_UNICAST. Future commits will take advantage of this. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Attempt to clarify variable names as they are usedDonald Sharp2021-09-271-2/+2
| | | | | | | Cleanup the poorly implemented variable names so that we can understand what is going on a bit better. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Remove the ZEBRA_IMPORT_ROUTE_XXX zapi messagesDonald Sharp2021-09-271-7/+0
| | | | | | | | | These are no longer really needed. The client just needs to call nexthop resolution instead. So let's remove the zapi types. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Add resolve via default flagDonald Sharp2021-09-271-2/+3
|
* lib: add zapi encode/decode func for srv6 locatorHiroki Shirokura2021-09-071-0/+27
| | | | Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
* nhrp, zebra, lib: pass exact received neighbor state value to nhrpPhilippe Guibert2021-08-261-6/+4
| | | | | | | | | | | | | | | | | | | | | As NHRP expects some notification of neighboring entries on GRE interface, when a new interface notification is encountered, the exact neighbor state flag is found. Previously, the flag passed to the upper layer was forced to NDM_STATE which is REACHABLE, as can be seen on below trace: 2021/08/25 10:58:39 NHRP: [QQ0NK-1H449] Netlink: new-neigh 102.1.1.1 dev gre1 lladdr 10.125.0.2 nud 0x2 cache used 1 type 5 When passing the real value, NHRP received an other value like STALE. 2021/08/25 11:28:44 NHRP: [QQ0NK-1H449] Netlink: new-neigh 102.1.1.1 dev gre1 lladdr 10.125.0.2 nud 0x4 cache used 0 type 5 This flag is important for NHRP, as it permits to monitor the link layer of NHRP entries. Fixes: d603c0774eba ("nhrp, zebra, lib: enforce usage of zapi_neigh_ip structure") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* lib: Blackhole nexthops cannot be used as part of label generationDonald Sharp2021-08-041-0/+16
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* lib: Convert assert to error and record it instead of abortingDonald Sharp2021-08-041-2/+14
| | | | | | | When we get a bad value for the opaque data length, instead of stopping the program, discard the data and move on. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* lib: Allow ZAPI_MESSAGE_OPAQUE_LENGTH length of dataDonald Sharp2021-07-071-1/+1
| | | | | | | | | | We are sending up to ZAPI_MESSAGE_OPAQUE_LENGTH but checking for one less. We know the data will fit in it to that size. Also we have asserts on the write to ensure we don't go over it Fixes: #8995 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #8942 from ton31337/fix/cleanups_2Donald Sharp2021-07-061-2/+2
|\ | | | | Another round of cleanup
| * lib: Avoid using assignments within checksDonatas Abraitis2021-06-291-2/+2
| | | | | | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* | *: Convert numeric 128 into IPV6_MAX_BITLEN for prefixlenDonatas Abraitis2021-07-011-1/+1
| | | | | | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* | *: Replace IPV4_MAX_PREFIXLEN to IPV4_MAX_BITLENDonatas Abraitis2021-07-011-1/+1
| | | | | | | | | | | | Just drop IPV4_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* | *: Replace IPV6_MAX_PREFIXLEN to IPV6_MAX_BITLENDonatas Abraitis2021-07-011-2/+2
| | | | | | | | | | | | Just drop IPV6_MAX_PREFIXLEN at all, no need keeping both. Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 07:18:18 +0100