The '... json detail' output is missing some data that's shown
via the 'route_vty_out_detail_header' function. Integrate the
json version of that function in the 'json detail' path.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
When a regular access-list is updated, we should update references to
regular access-lists, not as-path access-lists.
Fixes#9707.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem Statement:
Multiple struct compare using memcmp, which might result in issue due to
structure padding/alignment.
Fix:
The code changes involve structure member by member comparison to
remove any issues related to padding/alignment.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
(cherry picked from commit 67db821a1d6d68b19862d50b68ed19278c5f2422)
There's a helper function to check whether the interface is loopback or
VRF - if_is_loopback_or_vrf. Let's use it whenever we need to check that.
There's no functional change in this commit.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Since there's very few locations where the `frr-format` actually prints
false positive warnings, consensus seems to be to just work around the
false positives even if the code is correct.
In fact, there is only one pattern of false positives currently, in
`bfdd/dplane.c` which does `vty_out("%"PRIu64, (uint64_t)be64toh(...))`.
The workaround/fix for this is a replacement `be64toh` whose type is
always `uint64_t` regardless of what OS we're on, making the cast
unnecessary.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Deleting a mesh-group member no longer deletes the mesh-group.
Complete bug description at:
https://github.com/FRRouting/frr/issues/9664
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
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>
PIM is going to need to be able to send down the address it is
trying to resolve in the multicast rib. We need a way to signal
this to the end developer. Start the conversion by adding the
ability to have a safi. But only allow SAFI_UNICAST at the moment.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The entirety of the import checking no longer needs to be
in zebra as that no-one is calling it. Remove the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
OSPFv3 recently introduced the usage of import route. Switch it
back to using the normal ZEBRA_NEXTHOP_REGISTER command.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Allow bgp to figure out if it cares about address resolution instead
of having zebra care about it. This will allow the removal of the
zapi type for import checking and just use nexthop resolution.
Effectively we just look up the route being returned and
if it is in either table we just handle it instead of
looking for clues from the zapi message type.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This `XFREE()` call is in plainly in the wrong spot. `rp_all` (the
224.0.0.0/4 entry) isn't supposed to be free'd ever, and the
conditional above makes quite clear that it remains in use.
It may be possible to exploit this as a heap corruption bug, maybe even
as RCE. I haven't tried; I randomly noticed this while working on the
BSM code. Luckily this code is only run by the CLI for the clear
command, so the surface is very small.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The paf data structure is stored based upon an internal
bgp enum. The code is looking over all AFI/SAFI's and
doing a paf_af_find which then calls afindex to find
the right paf structure. Let's just loop over the
peer->peer_af_array[] and cut straight to the chase.
Under some loads the paf_af_find was taking up 6%
of the run time. This removes it entirely.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
