Do not return pointer to the newly created thread from various thread_add
functions. This should prevent developers from storing a thread pointer
into some variable without letting the lib know that the pointer is
stored. When the lib doesn't know that the pointer is stored, it doesn't
prevent rescheduling and it can lead to hard to find bugs. If someone
wants to store the pointer, they should pass a double pointer as the last
argument.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The function thread_is_scheduled allows us to know if
the particular thread is scheduled for execution or not.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
*_anywhere(item) returns whether an item is on _any_ container. Only
available for unsorted containers for now.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Using a non-NULL sentinel allows distinguishing between "end of list"
and "item not on any list". It's a compare either way, just the value
is different.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This provides a "is this item on this list" check, which may or may not
be faster than using *_find() for the same purpose. (If the container
has no faster way of doing it, it falls back to using *_find().)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some of the typesafe containers didn't null out their innards of items
after an item was deleted or popped off the container. This is both a
bit unsafe as well as hinders the upcoming _member() from working
efficiently.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
When something is used only from zebra and part of its description is
"should be called from zebra only" then it belongs to zebra, not lib.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
... to speed up vector_empty_slot() among other things.
Behavior should be 100% identical to previous.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This function doesn't work correctly with netns VRF backend as the same
ifname may be used in multiple netns simultaneously. So let's hide it
from the public API to reduce temptation to use it instead of writing
the correct code.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The fact that the interface name is used in some nexthop config doesn't
mean that the interface is configured.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
```
exit1-debian-9# show ip route 172.16.16.1/32
Routing entry for 172.16.16.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:00:28 ago
* 192.168.0.2, via eth1, weight 1
AS-Path : 65003
Communities : first 65001:2 65001:3
Large-Communities: 65001:1:1 65001:1:2 65001:1:3
Selection reason : First path received
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
To ensure this, add a const modifier to functions' arguments. Would be
great do this initially and avoid this large code change, but better
late than never.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The switch statement over `enum zebra_link_type` had a default
and FRR was missing a few of the pre-defined types we cared about.
Remove the default statement and add the missing values.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There's no more difference between number-named and word-named access-lists.
This commit removes separate arguments for number-named ACLs from CLI.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
We should never pass pointers to local variables to thread_add_* family.
When an event is executed, the library writes into this pointer, which
means it writes into some random memory on a stack.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The current code passes an address of a local variable to `thread_add_read`
which stores it into `thread->ref` by the lib. The next time the thread
callback is executed, the lib stores NULL into the `thread->ref` which
means it writes into some random memory on the stack.
To fix this, we should pass a pointer to the vector entry to the lib.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
`yang_dnode_get` will `assert` if no YANG node/model exist, so lets test for
its existence first before trying to access it.
This `assert` is only acceptable for internal FRR usage otherwise we
might miss typos or unmatching YANG models nodes/leaves. For gRPC usage
we should let users attempt to use non existing models without
`assert`ing.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
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>
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>
After `<daemon_name> is not running` message vtysh does not return
error. For example if you disable ospf in `/etc/frr/daemons` and run
`vtysh -c configure -c "router ospf"` it prints the message to stderr,
but returns 0.
This commit will make vtysh return error when not in interractive mode.
But if you run commands from vtysh, you will still be able to enter
views and exit them if daemon is not running.
Signed-off-by: Yaroslav Fedoriachenko <yar.fed99@gmail.com>
Instead of sorting each command one-by-one using listnode_add_sort, add
them to the list without sorting and then sort the list only once.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
frrmod_load() attempts to dlopen() several possible paths
(constructed from its basename argument) until one succeeds.
Each dlopen() attempt may fail for a different reason, and
the important one might not be the last one. Example:
dlopen(a/foo): file not found
dlopen(b/foo): symbol "bar" missing
dlopen(c/foo): file not found
Previous code reported only the most recent error. Now frrmod_load()
describes each dlopen() failure.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Sometimes it's needed to match by fields of one object but set fields of
another object. The following commit is an example.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
vrf_name_to_id() returned VRF_DEFAULT when the vrf name was
unknown, hiding errors. Per community recommendation, vrf_name_to_id()
is now removed and the few callers now use vrf_lookup_by_name()
directly.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Description:
Change is intended for fixing the following issues related to vrf route leaking:
Routes with special nexthops i.e. blackhole/sink routes when imported,
are not programmed into the FIB and corresponding nexthop is set as 'inactive',
nexthop interface as 'unknown'.
While importing/leaking routes between VRFs, in case of special nexthop(ipv4/ipv6)
once bgp announces route(s) to zebra, nexthop type is incorrectly set as
NEXTHOP_TYPE_IPV6_IFINDEX/NEXTHOP_TYPE_IFINDEX
i.e. directly connected even though we are not able to resolve through an interface.
This leads to nexthop_active_check marking nexthop !NEXTHOP_FLAG_ACTIVE.
Unable to find the active nexthop(s), route is not programmed into the FIB.
Whenever BGP leaks routes, set the correct nexthop type, so that route gets resolved
and correctly programmed into the FIB, in the imported vrf.
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Without this, the hook code creates functions with empty parameter lists
like "void hook_something()", which is not a proper C prototype. It
needs to be "void hook_something(void)". Add some macro shenanigans to
handle that.
... and make the plumbing functions "inline" too.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This fixes some spurious warnings on *BSD, where `elffile_add_dynreloc`
isn't used since `elf_getdata_rawchunk` is not available.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Commit: 4b983eef2c
Modified the zapi send receive of the c-bit to only
be under the HAVE_BFDD. If you are using ptm-bfd
then the decoder function still expects this to be
sent down. This commit puts this behavior back
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This allows defining a CLI command like this:
`[no] some setting ![VALUE]`
with VALUE being optional for the "no" form, but required for the
positive form. It's just a `[...]` where the empty branch can only be
taken for commands starting with `no`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Instead of adding a separate case clause for every node, just find the
node structure in the global list and get its parent node from there.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Insist on the fact that zclient neighbor state flags are
mapped over netlink state flags. List all the defines
currently known on kernel, and create a netlink API to
convert netlink values to zclient values. The function is
simplified as it is a 1-1 match.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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: d603c0774e ("nhrp, zebra, lib: enforce usage of zapi_neigh_ip structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
"[no] netns NAME" commands are part of the lib, but they are actually
zebra-only:
- they are using vrf_netns_handler_create and its description clearly
says that it "should be called from zebra only"
- vtysh sends these commands only to zebra
- only zebra outputs the netns related config
- zebra notifies other daemons about netns attachment
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There is a possibility that the same line can be matched as a command in
some node and its parent node. In this case, when reading the config,
this line is always executed as a command of the child node.
For example, with the following config:
```
router ospf
network 193.168.0.0/16 area 0
!
mpls ldp
discovery hello interval 111
!
```
Line `mpls ldp` is processed as command `mpls ldp-sync` inside the
`router ospf` node. This leads to a complete loss of `mpls ldp` node
configuration.
To eliminate this issue and all possible similar issues, let's print an
explicit "exit" at the end of every node config.
This commit also changes indentation for a couple of existing exit
commands so that all existing commands are on the same level as their
corresponding node-entering commands.
Fixes#9206.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There were paths where the zmq wrapper lib could call user
callbacks that would free the internal context struct, but the
context was then used in the lib code. Use a boolean to avoid
freeing the context within an application callback.
Restore logic that frees the context within the 'cancel' api.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
The zeromq lib wrapper uses an internal context struct to help
interact with the libfrr event mechanism. When freeing that
context struct, ensure the caller's pointer is also cleared.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
While defaults are good picks for "reasonable" guesses, min and max
range values really aren't. Operators and experimenters often like to
configure "unreasonable" values to stress test, tests boundary
conditions and explore innovations.
With that in mind, change all ranges to 1..max (of type).
While we're here add optional ignored values in the "no" CLI forms.
Signed-off-by: Christian Hopps <chopps@labn.net>
When using "match evpn default-route" rule, match_arg is NULL and strcmp
is not happy with that. There's already a special function named rulecmp
that handles such situations.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, when we check the new prefix-list entry for duplication, we
only take filled in fields into account and ignore optional fields.
For example, if we already have `ip prefix-list A 0.0.0.0/0 le 32` and
we try to add `ip prefix-list A 0.0.0.0/0`, it is treated as duplicate.
We should always compare all prefix-list fields when doing the check.
Fixes#9355.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Previous:
- frrscript_load: push Lua function onto stack
- frrscript_call: calls Lua function
Now:
- frrscript_load: checks Lua function
- frrscript_call: pushes and calls Lua function (first clear the stack)
So now we just need one frrscript_load for consecutive frrscript_call.
frrscript_call does not recompile or reload the script file, it just
keys it from the global Lua table (where it should already be).
Signed-off-by: Donald Lee <dlqs@gmx.com>
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>
The only difference in daemons' interface node definition is the config
write function. No need to define the node in every daemon, just pass
the callback as an argument to a library function and define the node
there.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When running `make check` against a build that zeromq enabled
the test_zmq unit test was crashing. The commit:
e08165def1
Introduced this crash. Removing the part of the commit
that was causing the crash in the test. This is mainly
to get `make check` working again for those people using
zeromq in their builds.
Fixes: #9176
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
like the other automake variables, setting `xyz_LDFLAGS` causes
`AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind
that automake doesn't do this for LDFLAGS, but... it does. (Which is
consistent with `_CFLAGS` and co.)
So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which
includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and
`MODULE_LDFLAGS` to handle all of this correctly (and move these bits to
a central location.)
Fixes: #9034
Fixes: 0c4285d77e ("build: properly split CFLAGS from AC_CFLAGS")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When exiting from link-params node, we must not decrement xpath_index
because it is not incremented when entering the node.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Will be handy to filter BGP prefixes by using BGP community alias
instead of numerical community values.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
frrscript_load now loads a function instead of a file, so frrscript_unload
should be renamed since it does not unload a function.
Signed-off-by: Donald Lee <dlqs@gmx.com>
There is some rather heavy error checking logic in frrscript_call. Normally
I'd put this in the _frrscript_call function, but the error checking needs
to happen before the encoders/decoders in the macro are called.
The error checking looks messy but its really just nested ternary
expressions insite a larger statement expression.
Signed-off-by: Donald Lee <dlqs@gmx.com>
Instead of 1 frrscript : 1 lua state, it is changed to 1 : N.
The states are hashed with their function names.
Signed-off-by: Donald Lee <dlqs@gmx.com>
Move `is_default_prefix` variations to `lib/prefix.h` and make the code
use the library version instead of implementing it again.
NOTE
----
The function was split into per family versions to cover all types.
Using `union prefixconstptr` is not possible due to static analyzer
warnings which cause CI to fail.
The specific cases that would cause this failure were:
- Caller used `struct prefix_ipv4` and called the generic function.
- `is_default_prefix` with signature using `const struct prefix *` or
`union prefixconstptr`.
The compiler would complain about reading bytes outside of the memory
bounds even though it did not take into account the `prefix->family`
part.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
There's nothing that can be done here with an error. Try to make
Coverity understand that this is intentional.
(I don't know if the `(void)` will actually fix the coverity warning,
but I don't really have a better way to figure it out beyond just
getting this merged and waiting for a result...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
While we do have `show ip prefix-list NAME A.B.C.D/M`, that doesn't
actually run the prefix list matching code. While the result would
hopefully be the same anyway, let's have a way to call the actual prefix
list match code and get a result.
(As an aside, this might be useful for scripting to do a quick "is this
prefix in that prefix list" check.)
Signed-off-by: David Lamparter <equinox@diac24.net>
... the PIM code is kinda misusing prefix lists to match addresses.
Considering the weird semantics of access-lists, I can't fault it.
However, prefix lists aren't great at matching addresses by default,
since they try to match the prefix length too. So, here's an "address
match mode" for prefix lists to get that to work more reasonably.
Fixes: #8492
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
RFC 3623 specifies the Graceful Restart enhancement to the OSPF
routing protocol. This PR implements support for the restarting mode,
whereas the helper mode was implemented by #6811.
This work is based on #6782, which implemented the pre-restart part
and settled the foundations for the post-restart part (behavioral
changes, GR exit conditions, and on-exit actions).
Here's a quick summary of how the GR restarting mode works:
* GR can be enabled on a per-instance basis using the `graceful-restart
[grace-period (1-1800)]` command;
* To perform a graceful shutdown, the `graceful-restart prepare ospf`
EXEC-level command needs to be issued before restarting the ospfd
daemon (there's no specific requirement on how the daemon should
be restarted);
* `graceful-restart prepare ospf` will initiate the graceful restart
for all GR-enabled instances by taking the following actions:
o Flooding Grace-LSAs over all interfaces
o Freezing the OSPF routes in the RIB
o Saving the end of the grace period in non-volatile memory (a JSON
file stored in `$frr_statedir`)
* Once ospfd is started again, it will follow the procedures
described in RFC 3623 until it detects it's time to exit the graceful
restart (either successfully or unsuccessfully).
Testing done:
* New topotest featuring a multi-area OSPF topology (including stub
and NSSA areas);
* Successful interop tests against IOS-XR routers acting as helpers.
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This replaces the external libsystemd dependency with... pretty much the
same amount of built-in code. But with one fewer dependency and build
switch needed.
Also check `JOURNAL_STREAM` for future logging integration.
Signed-off-by: David Lamparter <equinox@diac24.net>
There are a few places in the code where we use PREFIX_COPY(_IPV4/IPV6)
macro to copy a prefix. Let's always use prefix_copy function for this.
This should fix CID 1482142 and 1504610.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Adding defensive code to the interface_link_params zebra callback
to check if the link params changed before taking action.
Signed-off-by: Karen Schoener <karen@voltanet.io>
Adding the "clear ipv6 ospf6 command" . It resets
the ospfv3 datastructures and clears the database
as well as route tables. It resets the neighborship
by restarting the interface state machine.
If the user wants to change the router-id, this
command updates the router-id to the latest static
router-id and starts the neighbor formation with
the new router-id.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
Adding a `\n' should now produce a warning. Controlled by `-Werror` so
if you're doing a dev build and it's warning about some `prefix2str`
that should be converted to `%pFX`, you can turn off `-Werror` to fix it
later like with all other warnings.
Signed-off-by: David Lamparter <equinox@diac24.net>
This might be faster if at some point in the future the Linux vDSO
supports CLOCK_THREAD_CPUTIME_ID without making a syscall. (Same
applies for other OSes.)
Signed-off-by: David Lamparter <equinox@diac24.net>
...really no reason to force this into a compile time decision. The
only point is avoiding the getrusage() syscall, which can easily be a
runtime decision.
[v2: also split cputime & walltime limits]
Signed-off-by: David Lamparter <equinox@diac24.net>
Use this noop decoder for const values (since we can't mutate a const
value passed into frrscript_call anyways) or values we don't want to
write a decoder for.
Signed-off-by: Donald Lee <dlqs@gmx.com>
This is an example of creating encoders and decoders for user defined
structs and registering them in the ENCODE_ARGS DECODE_ARGS macro
in frrscript.
Signed-off-by: Donald Lee <dlqs@gmx.com>
Split existing lua_to* functions into two functions:
- lua_decode_*: unmarshall Lua values into an existing C data structure
- lua_to*: allocate *and* unmarshall Lua values into C data structure
This allows us to mutate C data structures passed into frrscript_call,
without allocation
Signed-off-by: Donald Lee <dlqs@gmx.com>
If we have the following configuration:
```
vrf red
smth
exit-vrf
!
interface red vrf red
smth
```
And we delete the VRF using "no vrf red" command, we end up with:
```
interface red
smth
```
Interface config is preserved but moved to the default VRF.
This is not an expected behavior. We should remove the interface config
when the VRF is deleted.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
glibc removed its pid cache a while back, and grabbing this from TLS is
faster than repeatedly calling the kernel...
Also use `intmax_t` which is more appropriate for both PID & TID.
Signed-off-by: David Lamparter <equinox@diac24.net>
Since the file targets append one anyway, save them some extra work.
syslog can use `%.*s` since it's "forced" printf by API anyway.
Signed-off-by: David Lamparter <equinox@diac24.net>
printfrr() recently acquired the capability to record start/end of
formatting outputs. Make use of this in the zlog code so logging
targets have access to this information.
(This also records how long the `[XXXXX-XXXXX][EC 9999999]` prefix was
so log targets can choose to skip over it.)
Signed-off-by: David Lamparter <equinox@diac24.net>
`log-filter WORD` was giving me a serious headache since it also matches
`log WORD` due to the way the CLI token handling works. This meant that
a mistyped `log something` command would silently be interpreted as a
filter string, causing me serious headscratching and WTFs until I
figured what was going on.
Remove this UX pitfall so noone else falls into it. (Since the command
was never saved to config, renaming it shouldn't cause trouble.)
[Also I apparently forgot to update the docs when I transferred this
over to the new zlog bits...]
TODO for a rainy day: since we collect all the CLI commands anyway, we
should warn somewhere for "2nd level ambiguous" commands like this.
Signed-off-by: David Lamparter <equinox@diac24.net>
Almost all functions currently marked with pure attribute acquire a
route_node lock. By marking them pure we allow compiler to optimize the
code and not call them when it already knows the return value. This is
completely incorrect.
Only two of eleven functions can be marked as pure. And they still won't
be optimized because they are never called from the same function twice.
Let's remove the ext_pure macro completely to reduce the chance of
repeating this mistake in the future.
Fixes#8866, #8809, #8595, #6992.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This commit fixes the following problem:
- enter the interface node
- move the interface to another VRF
- try to continue configuring the interface
It is not possible to continue configuration because the XPath stored in
the vty doesn't correspond with the actual state of the system anymore.
For example:
```
nfware# conf
nfware(config)# interface enp2s0
<-- move the enp2s0 to a different VRF -->
nfware(config-if)# ip router isis 1
% Failed to get iface dnode in candidate DB
```
To fix the issue, go through all connected vty shells and update the
stored XPath.
Suggested-by: Renato Westphal <renato@opensourcerouting.org>
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Always terminate default VRF last during FRR shutdown.
On shutdown we were simply looping over the RB tree and terminating
VRFs from the ROOT. This is not guaranteed to be the default last ever.
Instead switch to RB_SAFE and skip the default VRF till the very end.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
The %p printf format specifier does already print the pointer address
with a leading "0x" prefix (indicating a hexadecimal number). There's
no need to add that prefix manually.
While here, replace explicit function names in log messages by
__func__.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
- Add following set clause for route-maps
"set evpn gateway-ip <ipv4|ipv6 >A.B.C.D|X:X::X:X"
- When this route-map is applied as outboubd policy in BGP, it will set the
gateway-ip in BGP attribute For EVPN type-5 routes.
Example configuration:
route-map RMAP-EVPN_GWIP permit 5
set evpn gateway-ip ipv4 50.0.2.12
set evpn gateway-ip ipv6 50:0:2::12
router bgp 101
bgp router-id 10.100.0.1
neighbor 10.0.1.2 remote-as 102
!
address-family l2vpn evpn
neighbor 10.0.1.2 activate
neighbor 10.0.1.2 route-map RMAP-EVPN_GWIP out
advertise-all-vni
exit-address-family
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Fix the following address sanitizer crash when running the command `find`:
ERROR: AddressSanitizer: dynamic-stack-buffer-overflow
WRITE of size 1 at 0x7fff4840fc1d thread T0
0 in print_cmd ../lib/command.c:1541
1 in cmd_find_cmds ../lib/command.c:2364
2 in find ../vtysh/vtysh.c:3732
3 in cmd_execute_command_real ../lib/command.c:995
4 in cmd_execute_command ../lib/command.c:1055
5 in cmd_execute ../lib/command.c:1219
6 in vtysh_execute_func ../vtysh/vtysh.c:486
7 in vtysh_execute ../vtysh/vtysh.c:671
8 in main ../vtysh/vtysh_main.c:721
9 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
10 in _start (/usr/bin/vtysh+0x21f64d)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Test uses staticd which required some C++ header protections.
Additionally, the test also runs in the ubuntu20 docker container as
grpc is supported there by the packaging system.
Signed-off-by: Christian Hopps <chopps@labn.net>
When the VRF node is exited using "exit" or "quit", there's still a VRF
pointer stored in the vty context. If you try to configure some router
related command, it will be applied to the previous VRF instead of the
default VRF. For example:
```
(config)# vrf test
(config-vrf)# ip router-id 1.1.1.1
(config-vrf)# do show run
...
!
vrf test
ip router-id 1.1.1.1
exit-vrf
!
...
(config-vrf)# exit
(config)# ip router-id 2.2.2.2
(config)# do show run
...
!
vrf test
ip router-id 2.2.2.2
exit-vrf
!
...
```
`vrf-exit` works correctly, because it stores a pointer to the default
VRF into the vty context (but weirdly keeping the VRF_NODE instead of
changing it to CONFIG_NODE).
Instead of relying on the behavior of exit function, always use the
default VRF when in CONFIG_NODE.
Another problem is missing `VTY_CHECK_CONTEXT`. If someone deletes the
VRF in which node the user enters the command, then zebra applies the
command to the default VRF instead of throwing an error.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, we output the command exactly how it is defined in DEFUN.
We shouldn't output varnames and excessive whitespace.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
https://github.com/FRRouting/frr/pull/5865#discussion_r597670225
As this comment says. ZEBRA_FLAG_XXX should not have been used.
To communicate SRv6 Route Information. A simple Nexthop Flag would
have been sufficient for SRv6 information. And I fixed the whole
thing that way.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
I agree with the PR review from mstap and merged
the following two functions into one.
- zapi_nexthop_seg6_cmp
- zapi_nexthop_seg6local_cmp
[note]
If both of them have more complex extensions in the future,
I think it will be less confusing to remove the integration
of these functions and make them as separate functions as
before.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit add usuful function to configure SRv6 localsid
which is represented with seg6local lwt route.
Now, it can support only NEXTHOP_TYPE_IFINDEX route.
Actual configurationof SRv6 localsid is performed with
ZEBRA_ROUTE_ADD. So this is just a wrapper function
for route-install.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit add new nexthop's addional object for SRv6
routing about seg6 route. Before this commit,
we can add MPLS info as additional object on nexthop.
This commit make it add more support about seg6 routes.
seg6 routes are ones of the LWT routing mechanism,
so configuration of seg6local routes is performed by
ZEBRA_ROUTE_SEND, it's same as MPLS configuration.
Real configuration implementation isn't implemented at
this commit. later commit add that. This commit add
only nexthop additional object and some misc functions.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 works that add new structures for
SRv6-locator. This structure will be used by zebra and another
routing daemon and its ZAPI messaging to manage SRv6-locator.
Encoder/decoder for ZAPI stream is also added by this commit.
Real configuration mechanism isn't implemented at this commit.
later commit add real configure implementation. This commit add only
SRv6-locator's structures and misc functions.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 that add new cmd-node for SRv6 configuration.
This commit just add cmd-node and moving node cli only, acutual SRv6 config
command isn't added. (that is added later commit. of this branch)
new cli nodes:
* SRv6
* SRv6-locators
* SRv6-locator
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
This commit is a part of #5853 works that add new nexthop's addional
object for SRv6 routing about seg6local route. Before this commit,
we can add MPLS info as additional object on nexthop.
This commit make it add more support about seg6local routes.
seg6local routes are ones of the LWT routing mechanism,
so configuration of seg6local routes is performed by
ZEBRA_ROUTE_SEND, it's same as MPLS configuration.
Real configuration implementation isn't implemented at this commit.
later commit add that. This commit add only nexthop additional object
and some misc functions.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
Make seg6local_context2str function's prototype better.
This function is added on commit e496b4203, and function
interface's considering wasn't enough.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
The backoff code assumed that yang operations always completed quickly.
It checked for > 100 YANG modeled commands happening in under 1 second
to enable batching. If 100 yang modeled commands always take longer than
1 second batching is never enabled. This is the exact opposite of what
we want to happen since batching speeds the operations up.
Here are the results for libyang2 code without and with batching.
| action | 1K rts | 2K rts | 1K rts | 2K rts | 20k rts |
| | nobatch | nobatch | batch | batch | batch |
| Add IPv4 | .881 | 1.28 | .703 | 1.04 | 8.16 |
| Add Same IPv4 | 28.7 | 113 | .590 | .860 | 6.09 |
| Rem 1/2 IPv4 | .376 | .442 | .379 | .435 | 1.44 |
| Add Same IPv4 | 28.7 | 113 | .576 | .841 | 6.02 |
| Rem All IPv4 | 17.4 | 71.8 | .559 | .813 | 5.57 |
(IPv6 numbers are basically the same as iPv4, a couple percent slower)
Clearly we need this. Please note the growth (1K to 2K) w/o batching is
non-linear and 100 times slower than batched.
Notes on code: The use of the new `nb_cli_apply_changes_clear_pending`
is to commit any pending changes (including the current one). This is
done when the code would not correctly handle a single diff that
included the current changes with possible following changes. For
example, a "no" command followed by a new value to replace it would be
merged into a change, and the code would not deal well with that. A good
example of this is BGP neighbor peer-group changing. The other use is
after entering a router level (e.g., "router bgp") where the follow-on
command handlers expect that router object to now exists. The code
eventually needs to be cleaned up to not fail in these cases, but that
is for future NB cleanup.
Signed-off-by: Christian Hopps <chopps@labn.net>
The code that actually calls FRR northbound functions needs to be running in the
master thread. The previous code was running on a GRPC pthread. While fixing
moved to more functional vs OOP to make this easier to see.
Also fix ly merge to merge siblings not throw the originals away.
Signed-off-by: Christian Hopps <chopps@labn.net>
Never send an interface name/index for multihop sessions. It breaks
"neighbor A.B.C.D update-source" config in BGP.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There are two possible use-cases for the `vrf_bind` function:
- bind socket to an interface in a vrf
- bind socket to a vrf device
For the former case, there's one problem - success is returned when the
interface is not found. In that case, the socket is left unbound without
throwing an error.
For the latter case, there are multiple possible problems:
- If the name is not set, then the socket is left unbound (zebra, vrrp).
- If the name is "default" and there's an interface with that name in the
default VRF, then the socket is bound to that interface.
- In most daemons, if the router is configured before the VRF is actually
created, we're trying to open and bind the socket right after the
daemon receives a VRF registration from zebra. We may not receive the
VRF-interface registration from zebra yet at that point. Therefore,
`if_lookup_by_name` fails, and the socket is left unbound.
This commit fixes all the issues and updates the function description.
Suggested-by: Pat Ruddy <pat@voltanet.io>
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Prior to this commit, updating a prefix-list that is referenced by a
route-map clause will unconditionally delete the root node of that
route-map's prefix-tree (used with route-map optimization).
This is problematic because routes not matching a more specific node
in the tree (i.e. other prefix-list sequences) will not fall-back to
the default node, thus they will not hit any route-map sequences.
This commit ensures that an update to a prefix-list will only delete
the default node while adding the first/only seq to the list.
Example config:
========
ip prefix-list peer475-out-pfxlist seq 45 permit 2.138.0.0/16
ip prefix-list peer475-out-pfxlist seq 50 permit 0.0.0.0/0
!
route-map peer475-out permit 5
match ip address prefix-list peer475-out-pfxlist
Before:
========
ub20# do show route-map peer475-out prefix-table
ZEBRA:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
BGP:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
ub20# conf t
ub20(config)# ip prefix-list peer475-out-pfxlist seq 45 permit 2.138.0.0/16 le 32
ub20(config)# do show route-map peer475-out prefix-table
ZEBRA:
IPv4 Prefix Route-map Index List
_______________ ____________________
2.138.0.0/16 (2)
(P)
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
BGP:
IPv4 Prefix Route-map Index List
_______________ ____________________
2.138.0.0/16 (2)
(P)
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
ub20(config)#
After:
========
ub20(config)# do show route-map peer475-out prefix-table
ZEBRA:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
BGP:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
ub20(config)# ip prefix-list peer475-out-pfxlist seq 45 permit 2.138.0.0/16 le 32
ub20(config)# do show route-map peer475-out prefix-table
ZEBRA:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
BGP:
IPv4 Prefix Route-map Index List
_______________ ____________________
0.0.0.0/0 (2)
(P)
peer475-out seq 5
2.138.0.0/16 (2)
(P) 0.0.0.0/0
peer475-out seq 5
IPv6 Prefix Route-map Index List
_______________ ____________________
ub20(config)#
Fixes: 8410
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
lyd_merge_tree replaces dest siblings with source siblings, not what we
want. Instead lyd_merge_siblings to keep both. Instead lyd_merge_siblings
to keep both.
Signed-off-by: Christian Hopps <chopps@labn.net>
This includes community and large-community data.
```
exit1-debian-9# show ip route 172.16.16.1/32
Routing entry for 172.16.16.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:00:23 ago
* 192.168.0.2, via eth1, weight 1
AS-Path : 65030
Communities : 65001:1 65001:2 65001:3 65001:4 65001:5 65001:6
Large-Communities: 65001:123:1 65001:123:2
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
Track 'down' state of connected addresses with a new flag. We
may have multiple addresses on an interface that share a prefix;
in those cases, we need to determine when the first address
is valid, to install a connected route, and similarly detect
when the last address goes 'down', to remove the connected
route.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When specifying only an "le" for an existing ip prefix-list qualified with
both an "le" and "ge" make sure to remove the "ge" property so it does
not stay in the tree.
E.g. Saying these two things in order:
ip prefix-list test seq 1 permit 1.1.0.0/16 ge 18 le 24
ip prefix-list test seq 1 permit 1.1.0.0/16 ge 18
... should result in the second statement "overwriting" the first like
this:
vxdev-arch# do show ip prefix-list
ZEBRA: ip prefix-list foobar: 3 entries
seq 1 permit 15.0.0.0/16 ge 18
Previously this did not happen and "le" would stick around since it was
never given NB_OP_DESTROY and purged from the data tree.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Show alias name instead of numerical value in `show bgp <prefix>. E.g.:
```
root@exit1-debian-9:~/frr# vtysh -c 'sh run' | grep 'bgp community alias'
bgp community alias 65001:123 community-1
bgp community alias 65001:123:1 lcommunity-1
root@exit1-debian-9:~/frr#
```
```
exit1-debian-9# sh ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 21
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Community: 65001:12 65001:13 community-1 65001:65534
Large Community: lcommunity-1 65001:123:2
Last update: Fri Apr 16 12:51:27 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The distribute_list_init command is not used and is setup
code that will never be used because it makes assumptions about
how distribute-lists work that are fundamentally incorrect.
Remove the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Abstract the parsing of distribute lists so that we
don't have as much cut-n-paste code.
This is a setup commit for future work. In effect
current distribute-list handling is all kinds of messed up
a) eigrp and babel both attempt to use distribute-lists, they just plain
don't work.
b) `distribute-list` is only sent to rip. `ipv6 distribute-list`
is sent to ripngd. If you use `distribute-list` under `router ripng`
it sends the command to rip but ripd is in the wrong mode and it
never works.
c) Should ripngd care about v4 and v6 specific distribute-lists?
This dichotomy was added for babel but babel has been broke
about this since day 1( see a ).
All in all we need to unwind this whole mess. Make distribute-list
commands specific to the daemons( so that we can be in the right
sub-mode ). But the parsing is going to be the same across all
daemons. So let's provide that functionality in `lib/distribute.c`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a simpler, more limited nexthop comparison function. This
compares a few key attributes, such as vrf, gateway, labels.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Problem Statement:
=================
In scale setup BGP sessions start flapping.
RCA:
====
In virtualized environment there are multiple places where
MTU need to be set. If there are some places were MTU is not set
properly then there is chances that BGP packets get fragmented,
in scale setup this will lead to BGP session flap.
Fix:
====
A new tcp option is provided as part of this implementation,
which can be configured per neighbor and helps to set the TCP
max segment size. User need to derive the path MTU between the BGP
neighbors and set that value as part of tcp-mss setting.
1. CLI Configuration:
[no] neighbor <A.B.C.D|X:X::X:X|WORD> tcp-mss (1-65535)
2. Running config
frr# show running-config
router bgp 100
neighbor 198.51.100.2 tcp-mss 150 => new entry
neighbor 2001:DB8::2 tcp-mss 400 => new entry
3. Show command
frr# show bgp neighbors 198.51.100.2
BGP neighbor is 198.51.100.2, remote AS 100, local AS 100, internal link
Hostname: frr
Configured tcp-mss is 150, synced tcp-mss is 138 => new display
4. Show command json output
frr# show bgp neighbors 2001:DB8::2 json
{
"2001:DB8::2":{
"remoteAs":100,
"bgpTimerKeepAliveIntervalMsecs":60000,
"bgpTcpMssConfigured":400, => new entry
"bgpTcpMssSynced":388, => new entry
Risk:
=====
Low - This is a config driven feature and it sets the max segment
size for the TCP session between BGP peers.
Tests Executed:
===============
Have done manual testing with three router topology.
1. Executed basic config and un config scenarios
2. Verified if the config is updated in running config
during config and no config operation
3. Verified the show command output in both CLI format and
JSON format.
4. Verified if TCP SYN messages carry the max segment size
in their initial packets.
5. Verified the behaviour during clear bgp session.
6. done packet capture to see if the new segment size
takes effect.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
pimd was the only user of this function, and that has gone away now.
So just kill the function.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These hoops to get warnings for mis-printing `uint64_t` are apparently
breaking some C++ bits...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The previous method, using zassert.h and hoping nothing includes
assert.h (which, on glibc at least, just does "#undef assert" and puts
its own definition in...) was fragile - and actually broke undetected.
Just provide our own assert.h and control overriding by putting it in a
separate directory to add to the include path (or not.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When an operator encounters a situation where the number
of FD's open is greater than what we have been configured
to legitimately handle via uname or the `--limit-fds` command
line, abort with a message that they should be able to
debug and figure out what is going on.
Fixes: #8596
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
flush netlink related dependencies with gre information.
Add some linux headers required to compile with it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
3 new gre commands are available:
- GRE_GET to permit a daemon to retrieve gre information.
- GRE_UPDATe is the reply message from zebra to the daemon. as it is a
syncronous request, the GRE_GET expected will have to match the vrf id
where the gre information is wished. this has an impact on label
manager with change in APIs.
- SET_GRE_SOURCE. this command will be stubbed for now, assuming that
the gre interface is set accordingly by external script.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Description:
This looks broken after NB changes in routemap. When routemap
action modified from permit to deny, it is expected to apply
the new action on the filtered routes before the action in the
routemap data structure has been changed. But currently this is
not handled by the corresponding northbound API.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Use unsigned value for all RA requests to Zebra
- encoding signed int as unsigned is bad practice
- RA interval is never, and should never be, negative
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
`config.h` has all the defines from autoconf, which may include things
that switch behavior of other included headers (e.g. _GNU_SOURCE
enabling prototypes for additional functions.)
So, the first include in any `.c` file must be either `config.h` (with
the appropriate guard) or `zebra.h` (which includes `config.h` first
thing.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Don't uninstall sessions if the address, interface, VRF or TTL didn't change.
Update the library documentation to make it clear to other developers.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Currently this flag is only helpful in an extremely rare situation when
the BFD session registration was unsuccessful and after that zebra is
restarted. Let's remove this flag to simplify the API. If we ever want
to solve the problem of unsuccessful registration/deregistration, this
can be done using internal flags, without API modification.
Also add the error log to help user understand why the BFD session is
not working.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Creating any threads before we fork() into the background (if `-d` is
given) is an extremely dangerous footgun; the threads are created in
the parent and terminated when that exits.
This is extra dangerous because while testing, you'd often run the
daemon in foreground without `-d`, and everything works as expected.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... for any initialization that needs to run after forking, but that
would be racy if it were just scheduled on the thread_master (since the
config load is also just a thread callback, ordering would be undefined
for another scheduled thread callback.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
very_late_init doesn't really say what this does, config_post is much
more descriptive. (A config_pre is coming in a jiffy.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The (legacy) code for reading split configs tries to execute config
commands in parent nodes, but doesn't call the node_exit function when
it goes up to a parent node. This breaks BGP RPKI setup (and extended
syslog, which is in the next commit.)
Doing this correctly is a slight bit involved since the node_exit
callbacks should only be called if the command is actually executed on a
parent node.
Signed-off-by: David Lamparter <equinox@diac24.net>
