Donald Sharp [Wed, 17 Aug 2022 22:43:09 +0000 (18:43 -0400)]
pimd: Intentionally downcast to a uint32_t value
When calling time(NULL), FRR is intentionally throwing
away the upper 32 bits of value returned. Let's explicitly
call it out so that coverity understands this is intentional
and ok.
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 routes
(seg6 and seg6local routes) are handled: when the user executes the CLI
command `sharp install seg6-routes` or `sharp install seg6local-routes`
to create a seg6 or seg6local route, sharpd calls
`nexthop_add_srv6_seg6` or `nexthop_add_srv6_seg6local` to create an
SRv6 nexthop. A pointer to the SRv6 nexthop is stored in the global data
structure `sg.r.nhop`. If you call `sharp install routes`,
`sharp install seg6-routes` or `sharp install seg6local-routes` to create
more routes, `sg.r.nhop` is set to zero and the
pointer to the SRv6 nexthop contained in `sg.r.nhop` is definitely lost
and the allocated memory is never freed.
This patch adds calls to `nexthop_del_srv6_seg6()` and
`nexthop_del_srv6_seg6local()` to free the memory allocated for the SRv6
nexthop before clearing the `sg.r.nhop` data structure.
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, the `list_delete()` function is called to delete the
chunks list (`loc->chunks`), but the memory allocated for the chunks is
not freed.
This patch defines a new callback `sharp_srv6_locator_chunk_free()`.
This callback takes care of freeing the memory allocated for a given
chunk. When `list_delete()` is called to remove the chunk list
`loc->chunks`, it automatically calls `sharp_srv6_locator_chunk_free()`
on each element of the list to free the allocated memory before
deleting the list.
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, all the chunks are removed from the list `loc->chunks`.
Also, the locator is removed from the SRv6 locators list
`sg.srv6_locators`, but the memory allocated for the locator is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when all the chunks of an SRv6 locator are removed and the
locator is removed as well.
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 SRv6 locators are removed/unset in bgpd: when
an SRv6 locator is deleted or unset, the memory allocated for the
locator prefix (`tovpn_sid_locator`) is not freed.
This patch adds a `for` loop that iterates over the list of BGP
instances. For each BGP instance using the SRv6 locator to be
removed/unset, we use `XFREE()` to properly free the memory allocated
for `tovpn_sid_locator` after the SRv6 locator is removed or unset.
The memory allocated for `tovpn_sid_locator` cannot be freed before
calling `vpn_leak_postchange_all()`. This is because
after deleting an SRv6 locator, we call `vpn_leak_postchange_all()`
to handle the SRv6 locator deletion and send a BGP Prefix SID withdraw
message. `tovpn_sid_locator` is required to properly build the BGP
Prefix SID withdraw message. After calling `vpn_leak_postchange_all()`
we can safely remove the `tovpn_sid_locator` and free the allocated
memory.
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 SRv6 SIDs are removed in bgpd: when
an SRv6 locator is deleted/unset, all the SIDs allocated from that
locator are removed from the SRv6 functions list
(`bgp->srv6_functions`),but the memory allocated for the SIDs is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when an SRv6 SID is removed.
bgpd: Fix memory leak in SRv6 locator delete/unset
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 SRv6 locators are deleted/unset in bgpd: when
an SRv6 locator is deleted/unset, all the chunks of the locator are
removed from the SRv6 locator chunks list (`bgp->srv6_locator_chunks`).
However, the memory allocated for the chunks is not freed.
This patch adds a call to the `srv6_locator_chunk_free()` function to
properly free the allocated memory when an SRv6 locator is removed or
unset.
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.
Running `srv6_locator` topotest with `--valgrind-memleaks` gives several
memory leak errors. This is due to the way SRv6 locators are deleted:
when an SRv6 locator is deleted, it is removed from the SRv6 locators
list (`srv6->locators`), but the memory allocated for the SRv6 locator
is not freed.
This patch adds a call to the `srv6_locator_free()` function to properly
free the allocated memory when an SRv6 locator is removed.
rgirada [Mon, 22 Aug 2022 18:15:56 +0000 (11:15 -0700)]
ospfd: Adding per neighbour json details to GR helper detail command
Description:
Per neighbor GR enabled information is missing from json
output in "show ip ospf gr helper details json" command.
Example config:
frr(config-router)# graceful-restart helper enable 2.2.2.2
frr(config-router)#
frr(config-router)# do show ip ospf graceful-restart helper detail
OSPF Router with ID (10.112.156.220)
Graceful restart helper support disabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Enable Router list:
2.2.2.2,
frr(config-router)# do show ip ospf graceful-restart helper detail json
{
"routerId":"10.112.156.220",
"helperSupport":"Disabled",
"strictLsaCheck":"Enabled",
"restartSupoort":"Planned and Unplanned Restarts",
"supportedGracePeriod":1800,
}
frr(config-router)#
pim6d: mroute stuck in register state, multicast traffic getting drops
IPv4 and IPv6 behaves a little bit differently with the socket
options.
IPPROTO_RAW socket option is only for IPv4.
Therefore the register packet was not properly getting encapculated
for PIMv6 and was working fine for PIMv4.
Xiaodong Xu [Sat, 20 Aug 2022 00:25:41 +0000 (17:25 -0700)]
ospf6d: Don't remove summary route if it is a range
Fix issue #11839.
When the user defines a range in an area other than the backbone area, the
summary route will be announced to the backbone area as an inter-area LSA.
However, if the prefix defined in the range is the same prefix as a connected
route in that area, the LSA won't be announced to the backbone area.
This is because when ospf6d is originating the summary route for the
intra-area route, it finds the range configured by the user and tries to
suppress the route by deleting the existing summary route, which happens to be
the one created by the range.
Although the range definition is not necessary in this case, it should not
fail this use case. So let's just keep the summary route there if it is
created from the user defined range.
Eugene Crosser [Fri, 19 Aug 2022 13:56:57 +0000 (15:56 +0200)]
debian: add lua _binary_ to build dependencies
FRR only needs lua library (package libluaX.Y-dev) to be compiled and
linked, but its `configure` script makes use of lua interpreter to
perform its checks. Therefore, `luaX.Y` package is a requisite
build-dependency for debian packaging.
This commit adds the debian package with the lua interpreter to the
build dependencies.
Donald Sharp [Wed, 10 Aug 2022 00:09:03 +0000 (20:09 -0400)]
zebra: No need for a rib_delete before a rib_add
In kernel_socket.c, the code is deleting and then adding
the route back in on a change operation. This just translates
too two re's, one for deletion and one for addition. The deletion
will just be ignored. Let's not do the extra deletion.
Donald Sharp [Tue, 2 Aug 2022 17:57:18 +0000 (13:57 -0400)]
zebra: Introduce early route processing on the MetaQ
Currently if an operator does this operation:
sharpd@eva ~/frr8> sudo ip nexthop add id 5000 via 192.168.119.44 dev enp39s0 ; sudo ip route add 10.0.0.1 nhid 5000
2022/06/30 08:52:40 ZEBRA: [ZHQK5-J9M1R] proto2zebra: Please add this protocol(0) to proper rt_netlink.c handling
2022/06/30 08:52:40 ZEBRA: [PS16P-365FK][EC 4043309076] Zebra failed to find the nexthop hash entry for id=5000 in a route entry
sharpd@eva ~/frr8> vtysh -c "show ip route 10.0.0.1"
Routing entry for 0.0.0.0/0
Known via "kernel", distance 0, metric 100, best
Last update 00:01:58 ago
* 192.168.119.1, via enp39s0
The route is dropped by zebra with no warnings. This is not good,
but unlikely to happen at this point in time. In order to fix
this issue route processing from inputs needs to happen after nexthop
group processing from inputs. This was not possible because
nexthop groups are placed on the metaQ. As such the above
nexthop group creation is placed on the metaQ for processing
in META_QUEUE_NHG. Then the route is read in and processed
immediately. The nexthop group is not found ( not processed yet!)
and the route is dropped in zebra.
Modify the code to have early route processing of validity
on the MetaQ. This preserves the order of operations.
Donald Sharp [Tue, 9 Aug 2022 20:00:24 +0000 (16:00 -0400)]
zebra: Convert label processing to Meta-Q
Convert label processing that comes from zapi messages
into being handled by the meta-Q. This is because early
route processing is going to be moved to the meta-Q as
well and we will have a chicken and egg problem without
moving this code to be processed by the meta-Q.
Ordering of messages from ospf as an example:
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:62] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:43] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:61] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:66] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
The ZEBRA_MPLS_LABELS_REPLACE immediately turn around and attempt to replace nexthop labels on routes that
were added. If the route add is placed on the metaQ, it will not exist yet and as such the label replace
will fail.
Modify the zebra code to take the label operations and place them on the metaQ as well.
projects / matthieu / frr.git / log