While this wasn't a problematic use of a format string, make it a
literal constant so the compiler is happy.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Passing a pre-formatted buffer in these places needs a `"%s"` in front
so it doesn't get formatted twice.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We do use non-constant/literal format strings in a few places for more
or less valid reasons; put `ignored "-Wformat-nonliteral"` around those
so we can have the warning enabled for everywhere else.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
wheel_stop and wheel_start have never been used. Let's just remove
them. After close to 7 years, if needed someone else can add back in.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Locking around the list of providers/plugins is not
helpful - these only change at init time. Clear some SA
warnings by removing the locking.
Signed-off-by: Mark Stapp <mjs@labn.net>
Mostly useful duging the freeze period to warn the maintainers from merging
unwanted PRs.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
1. Renamed "gates" to "nexthops"
2. Displaying afi of the nexthops being dispalyed in place of
"nexthops" JSON object in the old JSON output
3. Calling show_route_nexthop_helper() and show_nexthop_json_helper()
instead of print_nh() inorder to keeps the fields in "nexthops"
JSON object in sync with "nexthops" JSON object of
"show nexthop-group rib json".
Updated vtysh:
r1# show ip nht
192.168.0.2
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
192.168.0.4
resolved via connected
is directly connected, r1-eth0 (vrf default)
Client list: static(fd 28)
Updated JSON:
r1# show ip nht json
{
"default":{
"ipv4":{
"192.168.0.2":{
"nhtConnected":false,
"clientList":[
{
"protocol":"static",
"socket":28,
"protocolFiltered":"none"
}
],
"nexthops":[
{
"flags":3,
"fib":true,
"directlyConnected":true,
"interfaceIndex":2,
"interfaceName":"r1-eth0",
"vrf":"default",
"active":true
}
],
"resolvedProtocol":"connected"
}
}
}
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
The tar.xz dist tarball doesn't exist for new releases.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 5a1130213c)
Github changed the HTML for their releases tab, making download links a
javascript thing. Which does not jive with uscan... at all...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 3c185cf70c)
Apparently now the binary filename is after the item...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit f032ce0a66)
Already done for existing python scripts in the install, just need to
add new .py files.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 03cef39003)
The debian/watchfrr.rc file was not install, so we just remove the cruft.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
(cherry picked from commit 5632ff61df)
These two build-deps are for compile-time tools and thus need to be
marked :native.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit e9f0af06c9)
This allows e.g. "sbuild --host=arm64" to build packages for other
architectures on, say, fat amd64 servers. As a side effect, the Debian
build uses a separate builddir, which helps noting issues on that front.
Signed-off-by: David Lamparter <equinox@diac24.net>
(cherry-picked from commit d1312e009b)
Parallel build may be executing another copy of embedmodel.py at the
same time, with both getting "False" on the isdir check, and then both
trying to mkdir - one of which will error out.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When running the build in a separate build directory, redirecting output
into a file can error out if the directory does not exist yet. Some
places already had `mkdir -p` calls, but not all.
Make all occurences of this consistently use `@$(MKDIR_P)`.
(Extension of PR #12575 to catch more places.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Daemons like staticd already implement nexthop zapi (un)registration.
b7ca809d1c ("lib: BFD automatic source selection") has implemented a
concurrent nexthop (un)registration. Some nexthop could be unregistred
by the bfd whereas they were still needed by the daemon.
Let the deamons deal with nexthop zapi (un)registration.
Fixes: b7ca809d1c ("lib: BFD automatic source selection")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
b7ca809d1c ("lib: BFD automatic source selection") has added a dedicated
zclient socket for nht tracking. Since the bfd lib is used by daemons
that already has a zclient socket, those daemons has now a second
zclient socket. However, zebra does not distinguish the two zclient
sessions. For example, the interfaces are asked a second via
zebra_message_send(zclient, ZEBRA_INTERFACE_ADD, VRF_DEFAULT) in
zclient_start(). As a result, callbacks functions like bgp_ifp_create()
are called a second time, which causes some processing overhead and
might cause bugs.
Re-use the existing zclient socket for nht tracking.
Note that BFD automatic source selection is only currently implemented
in staticd. Other daemons will require to add the following in their
ZEBRA_NEXTHOP_UPDATE callback function:
> if (zclient->bfd_integration)
> bfd_nht_update(&matched, &nhr);
Fixes: b7ca809d1c ("lib: BFD automatic source selection")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix the following issues:
- two tests are done in one function. Dispatch the tests in two
functions to help the test debug.
- the first test passes even if a third prefix is not filtered. Match
the exact to avoid false positive.
- the expected values contains variable like version. Do no check
variable values.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This fix updates the nexthop length of a bgp update to be
transmitted to a remote peer. Before the previous commit,
the ipv6 nexthop length was internally set to 32 bytes which
was not correct, as it should be 48 bytes which is conform
to the vpnv6 encoding format.
However, without the previous match, even if internally, the
nexthop length was set to 32, the real nexthop length was set
to 48 bytes, and everything was operating ok.
Now, if we use the following route-map, and attach it to
outgoing for vpnv6 address family, then we have a malformed
packet detected, and the peering breaks.
> route-map rmap permit 1
> set ipv6 next-hop global 5:5::3:6
> set ipv6 next-hop local fe80:55::333:222
Maintain the mp_nexthop_len to 48 bytes if it was already set
to 48 previously.
Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For BGP evpn route table detail json to use
non pretty form of display.
Problem:
In scaled evpn route table detail json dump
occupies high resources (CPU + memory) of the system.
In high scale evpn route dump using pretty form
hogs CPU for a while which can trigger watchfrr
to kill bgpd.
Solution:
Avoid pretty JSON print for detail version dump
Signed-off-by: Chirag Shah <chirag@nvidia.com>
