When displaying the running configuration, we should use a single
space to indent commands when necessary (and not two spaces).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This patch adds support to nexthops of type NEXTHOP_TYPE_IFINDEX to
nexthop-groups. This should be especially useful when dealing with
p2p interfaces like tunnels that don't have IP addresses assigned
to them.
NOTE: nh->addr can be NULL now, so we should always perform a null
check before dereferencing this pointer.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Use a pointer to a sockunion instead of a full sockunion in the
nexthop_hold structure. This prepares the ground for the next commit,
which will make nexthop addresses optional (in this commit we assume
nh->addr will never be NULL, but this will change).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* command_graph.h: stop using "new" as a parameter name as that's a
reserved C++ keyword.
* module.h: avoid using C99 designated initializers since C++ doesn't
support them. This change hurts code readability quite considerably,
so we should try to find a better solution later.
* pw.h: remove unneeded empty structure to silence a C++ warning.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
C++ doesn't support implicit casts from void pointers like C
does. And the libfrr headers have some bits of code that rely on
implicit casts in order to work. To solve this problem, add a new
"static_cast" macro that performs explicit static casts when a C++
compiler is being used, or do nothing otherwise.
NOTE: since macros are only evaluated when they are used, there
might be other macros from libfrr that will need to use "static_cast"
as well. If a header is successfully compiled using a C++ compiler,
there's no guarantee that its macros are compatible with C++. We'll
only know about such macros when they are used by C++ code, then
we'll need to adapt them one by one in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Two different definitions of "enum filter_type" exist in libfrr:
one in lib/filter.h and other in lib/command_match.h. Rename one
of them to resolve a conflict that happens when both headers are
included by the same file.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These are necessary to use functions defined in these headers from C++.
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
C++ doesn't have ISO C11 stdatomic.h or "_Atomic inttype", so use
std::atomic instead to get the headers compatible.
Signed-off-by: David Lamparter <equinox@diac24.net>
Add a no-op conversion constructor to tell C++ that union prefixptr
accepts any of its member types.
Signed-off-by: David Lamparter <equinox@diac24.net>
Change the northbound lib operation from DELETE to DESTROY;
make the required changes in the users of the northbound, in
the cli, rip, ripng, and isis.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Some misc changes to resolve some c++ compilation errors.
The goal is only to permit an external module - a plugin,
for example - to see frr headers, not to support or encourage
contributions in c++. The changes include: avoiding use
of keywords like 'new', 'delete'; cleaning up implicit
type-casting from 'void *' in several places.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
on interface search algorithm, at initialisation, when reading config
file, the vrf backend may not be yet known ( because zebra did not sync
yet with daemon). For that, avoid searching interface name in a separate
vrf. This change of behaviour is induced because the assumption is done
that at config startup, the user is not wrong with the interface
configuration to use. Every usage of vrf_get_backend() should then be
wisely adapted in order to handle that init state.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
other daemons need to sync with zebra to get to know which vrf backend
is available. in that time, there may be interface configuration
available. in that specific case, the vrf backend returned is not known.
A specific return value is sent back. This will be useful to know which
specific algorithm to apply.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Collapse the old static free function into the actual public
function that was using it (and the only user of it.)
Signed-off-by: Mark Stapp <mjs@voltanet.io>
This change is used to send configue changes for
advertise svi address as macip (type-2) route.
Ticket:CM-23782
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Ask for all interface information after we have connected
to zebra and sent the initial hello.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Made the following changes.
1.Defined two apis in routemap-lib, one for increment and another for
decrement the applied counter.
2.Added a new configuration “show route-map-unused” to track all unused
routemaps.
3.called the corresponding route map update api when a route map attached
or detached from any redistribution list.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
Apparently 'f' means both OpenFabric and a Failed kernel
route installation.
Let's switch the 'f' for the failed kernel route installation
to 'r - rejected route'.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The onlink attribute was being passed from upper level protocols
as an attribute of the route *not* the individual nexthop. When
we pass this data to the kernel, we treat the onlink as a attribute
of the nexthop. This commit modifies the code base to allow
us to pass the ONLINK attribute as an attribute of the nexthop.
This commit also fixes static routes that have multiple nexthops
some onlink and some not.
ip route 4.5.6.7/32 192.168.41.1 eveth1 onlink
ip route 4.5.6.7/32 192.168.42.2
S>* 4.5.6.7/32 [1/0] via 192.168.41.1, eveth1 onlink, 00:03:04
* via 192.168.42.2, eveth2, 00:03:04
sharpd@robot ~/frr2> sudo ip netns exec EVA ip route show
4.5.6.7 proto 196 metric 20
nexthop via 192.168.41.1 dev eveth1 weight 1 onlink
nexthop via 192.168.42.2 dev eveth2 weight 1
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are selecting nexthops for disply, abstract the notion
of what character we display to the end user about the status
of the nexthop.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
MACVLAN devices are typically used for applications such as VRR/VRRP that
require a second MAC address (virtual). These devices have a corresponding
SVI/VLAN device -
root@TORC11:~# ip addr show vlan1002
39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff
inet6 2001:aa:1::2/64 scope global
valid_lft forever preferred_lft forever
root@TORC11:~# ip addr show vlan1002-v0
40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff
inet6 2001:aa:1::a/64 metric 1024 scope global
valid_lft forever preferred_lft forever
root@TORC11:~#
The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via
the SVI. To acheive that functionality the macvlan network's metric
is set to a higher value.
Zebra currently ignores the devaddr metric sent by the kernel and hardcodes
it to 0. This commit eliminates that hardcoding. If the devaddr metric
is available (METRIC_MAX) it is used for setting up the connected route
otherwise we fallback to the dev/interface metric.
Setting the macvlan metric to a higher value ensures that zebra will always
select the connected route on the SVI (and subsequently use it for next hop
resolution etc.) -
root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64"
Routing entry for 2001:aa:1::/64
Known via "connected", distance 0, metric 1024, vrf vrf1
Last update 11:30:56 ago
* directly connected, vlan1002-v0
Routing entry for 2001:aa:1::/64
Known via "connected", distance 0, metric 0, vrf vrf1, best
Last update 11:30:56 ago
* directly connected, vlan1002
root@TORC11:~#
Ticket: CM-23511
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When a local neigh is added with a MAC that is remote or absent the
neigh is kept in zebra as local/in-active. But not propagated to bgpd.
Similarly when an inactive neigh is deleted the del-msg is not propagated
to bgpd.
Without this change bgp and zebra would fall out of sync as that
bgp would not know to rerun bestpath and for it to reinstall a
known remote path for the mac-ip in question. To fix this we
now propagate inactive neigh deletes to bgpd.
Ticket: CM-23018
Testing Done:
1. evpn-min
2. manually triggered the out-of-sync state and verified the fix
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
FRR log targets are independent, so "log syslog" must not disable
"log file" output.
Fixes: #3551
Fixes: 0204baa876
Signed-off-by: David Lamparter <equinox@diac24.net>
Starting with libyang 0.16.74, we can load internally embedded yang
extensions instead of going through the file system/dlopen. Detect
support for this at build time and use if available.
NB: the fallback mechanism will go away in a short while.
Signed-off-by: David Lamparter <equinox@diac24.net>
CC lib/frr_pthread.lo
lib/frr_pthread.c:128:40: error: too many arguments to function call, expected 1, have 3
ret = pthread_setname_np(fpt->thread, fpt->os_name, NULL);
~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/pthread.h:512:1: note: 'pthread_setname_np' declared here
__API_AVAILABLE(macos(10.6), ios(3.2))
Mac OS does have pthread_setname_np, but we can't use it here since it
only accepts a single argument, the thread name, and thus only works for
the current thread.
Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
Now that all daemons receive the VRF backend from zebra, we can get
rid of vrf_is_mapped_on_netns() in favor of using the more convenient
vrf_is_backend_netns() function, which doesn't require any argument.
This commit also fixes the following problem:
debian(config)# ip route 50.0.0.0/8 blackhole vrf FAKE table 2
% table param only available when running on netns-based vrfs
Even when zebra was started with the --vrfwnetns, the error
above would be displayed since the VRF FAKE didn't exist, which
would make vrf_is_mapped_on_netns() return 0 incorrectly. Using
vrf_is_backend_netns() this problem doesn't happen anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a new field in the ZEBRA_CAPABILITIES zapi message specifying
the VRF backend in use.
For simplicity, make the zclient code call vrf_configure_backend()
to apply the received value automatically instead of requiring
the daemons to do that themselves in their zebra_capabilities()
callbacks.
Additionally, call zebra_vrf_update_all() only after sending the
capabilities message to the client, so that it will know which VRF
backend is in use when processing the VRF messages.
This commit fixes a couple of bugs in the "interface" CLI command and
associated northbound callbacks, which behave differently depending
on the VRF backend in use. Before this commit, the vrf_backend
variable would always be set to VRF_BACKEND_NETNS in the client
daemons, even when zebra was started without the --vrfwnetns option.
This could lead to inconsistent behavior and subtle bugs under
specific circumstances.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We can make use of the vty->config variable to know when the CLI
user is in the configuration mode or not. This is much simpler
than obtaining this information from the vty node, and also a more
robust solution (the three switch statements below, for example,
were out of sync).
Also, fix a bug where vty->config wasn't being unset in the
vty_config_exit() function (bug introduced by commit f344c66ea3).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The CLI code uses the vty->xpath[] array and the vty->xpath_index
variables to keep track of where the user is in the configuration
hierarchy. As such, we were resetting vty->xpath_index to zero
whenever the user exited from the configuration mode in order to
keep the index valid. We weren't doing this in the vty_stop_input()
function however, which is called when the user types ^C in the
terminal. This was leading to bugs like this:
zebra> en
zebra# conf t
zebra(config)# interface eth0
zebra(config-if)# ^C
zebra# conf t
zebra(config)# interface eth0
% Configuration failed.
Schema node not found.
YANG path: /frr-interface:lib/interface[name='eth0'][vrf='default']/frr-interface:lib
To fix this, do something more clever: instead of resetting the
XPath index whenever the user exits from the configuration mode,
do that when the user enters in the configuration mode. This way
the XPath index needs to be reset in a single place only, not to
mention it's a more robust solution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When lyd_validate() is used with the LYD_OPT_DATA option, full YANG
validation is performed. As a side-effect to this, default nodes are
created, which is not desirable when displaying operational data
since configuration nodes can also be created. Use LYD_OPT_GET
option to resolve this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
One use case for the new yang_data_list_find() function is to find
input parameters in RPC northbound callbacks easily, without the
need to iterate over the input parameters manually.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Parameters should be const whenever possible to improve code
readability and remove the need to cast away the constness of
const arguments.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In these two functions, we were using VRF_DEFAULT instead of the
VRF ID passed as a parameter when checking if the given client
subscribed to receive default routes or not. This prevented the
"default-originate" command from ospfd/isisd from working correctly
under specific circumstances.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Since commit 3a11599c, the FRR YANG modules are embedded inside the
binaries and no longer need to be loaded from the file system. This
way, it's impossible for the FRR binaries and YANG modules to be out
of sync anymore. As such, update the suggestions of the northbound
error codes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Instead of aborting when an incomplete xpath is given to the
nb_oper_data_iterate() function, just return an error so that the
callers have a chance to treat this error. Aborting based on invalid
user input is never the right thing to do.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When FRR is built without the --enable-config-rollbacks option,
the nb_db_transaction_save() function does nothing and the
"transaction_id" output parameter is left uninitialized. For
this reason, all northbound clients should initialize the
"transaction_id" argument before calling nb_candidate_commit() or
nb_candidate_commit_apply() (except when a NULL pointer is given,
which is the case of the confd and sysrepo plugins).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We are already handling all possible four cases from the "nb_event"
enumeration, so this problem can't happen in practice. Initialize the
"ref" variable to zero to silence the warning.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Some daemons like ospfd and isisd have the ability to advertise a
default route to their peers only if one exists in the RIB. This
is what the "default-information originate" commands do when used
without the "always" parameter.
For that to work, these daemons use the ZEBRA_REDISTRIBUTE_DEFAULT_ADD
message to request default route information to zebra. The problem
is that this message didn't have an AFI parameter, so a default route
from any address-family would satisfy the requests from both daemons
(e.g. ::/0 would trigger ospfd to advertise a default route to its
peers, and 0.0.0.0/0 would trigger isisd to advertise a default route
to its IPv6 peers).
Fix this by adding an AFI parameter to the
ZEBRA_REDISTRIBUTE_DEFAULT_{ADD,DELETE} messages and making the
corresponding code changes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
It would be nice to have the ability to access the prefix data structure
address as a block of 4 uint32_t's. This will allow me to easily/quickly
update the v6 address by 1. This will be used in subsuquent commits.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The current invocation of frr_pthread_set_name was causing it reset the os_name.
There is no need for this, we now always create the pthread appropriately
to have both name and os_name. So convert this function to a simple
call through of the pthread call now.
Before(any of these changes):
sharpd@robot ~/frr1> ps -L -p 16895
PID LWP TTY TIME CMD
16895 16895 ? 00:01:39 bgpd
16895 16896 ? 00:00:54
16895 16897 ? 00:00:07 bgpd_ka
After:
sharpd@donna ~/frr1> ps -L -p 1752
PID LWP TTY TIME CMD
1752 1752 ? 00:00:00 bgpd
1752 1753 ? 00:00:00 bgpd_io
1752 1754 ? 00:00:00 bgpd_ka
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we start a thread we always call fpt_run and since
the last commit we know os_name is filled with something,
therefore we can just set the name on startup.
This creates this output now for zebra:
sharpd@donna ~/frr2> ps -L -p 25643
PID LWP TTY TIME CMD
25643 25643 ? 00:00:00 zebra
25643 25644 ? 00:00:00 Zebra dplane
25643 25684 ? 00:00:00 zebra_apic
sharpd@donna ~/frr2>
I removed the abstraction to frr_pthread_set_name because
it was snprintf'ing into the same buffer which was the
real bug here( the first character of os_name became null).
In the next commit I'll remove that api because
it is unneeded and was a horrible hack to get
this to work for the one place it was wanted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On call of frr_pthread_new, save the os_name if given,
if not given use the name passed in( shortening to fit
in available space ) and finally if the name was not
passed in use the default value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When using getrusage, we have multiple choices about what
to call for data gathering about this particular thread of execution.
RUSAGE_SELF -> This means gather all cpu run time for all pthreads associated
with this process.
RUSAGE_THREAD -> This means gather all cpu run time for this particular
pthread.
Clearly with data gathering for slow thread as well as `show thread cpu`
it would be preferable to gather only data about the current running
pthread. This probably was the original behavior of using RUSAGE_SELF
when we didn't have multiple pthreads. So it didn't matter so much.
Prior to this change, 10 iterations of 1 million routes install/remove
from zebra would give us this cpu time for the dataplane pthread:
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread
0 280902.149 326541 860 2609982 550 2468910 E dplane_thread_loop
After this change we are seeing this:
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread
0 58045.560 334944 173 277226 539 2502268 E dplane_thread_loop
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is the start of a series of commits that will allow FRR to
be integrated into mlag.
Zebra and Pim will both need mlag state for the router. As such we will
need to provide a abstract about this state through the zapi.
This is the start of the common header that both Pim and Zebra will
be using.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
FreeBSD's libc segfaults when vsnprintf() is called with a null
format string. Add a null check before calling vsnprintf() to
resolve this problem.
Fixes#3537
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Unlike the other interface zapi messages, ZEBRA_INTERFACE_VRF_UPDATE
identifies interfaces using ifindexes and not interface names. This
is a problem because zebra always sends ZEBRA_INTERFACE_DOWN
and ZEBRA_INTERFACE_DELETE messages before sending
ZEBRA_INTERFACE_VRF_UPDATE, and the ZEBRA_INTERFACE_DELETE callback
from all daemons set the interface index to IFINDEX_INTERNAL. Hence,
when decoding a ZEBRA_INTERFACE_VRF_UPDATE message, the interface
lookup would always fail since the corresponding interface lost
its ifindex. Example (ospfd):
OSPF: Zebra: Interface[rt1-eth2] state change to down.
OSPF: Zebra: interface delete rt1-eth2 vrf default[0] index 8 flags 11143 metric 0 mtu 1500
OSPF: [EC 100663301] INTERFACE_VRF_UPDATE: Cannot find IF 8 in VRF 0
To fix this problem, use interface names instead of ifindexes to
indentify interfaces like the other interface zapi messages do.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
a distribute_ctx context pointer is returned after initialisation to the
calling daemon. this context pointer will be further used to do
discussion with distribute service. Today, there is no specific problem
with old api, since the pointer is the same in all the memory process.
but the pointer will be different if we have multiple instances. Right
now, this is not the case, but if that happens, that work will be used
for that.
distribute-list initialisation is split in two. the vty initialisation
is done at global level, while the context initialisation is done for
each routing daemon instance.
babel daemon is being equipped with a routing returning the main babel
instance.
also, a delete routine is available when the daemon routing instance is
suppressed.
a list of contexts is used inside distribute_list. This will permit
distribute_list utility to handle in the same daemon to handle more than
one context. This will be very useful in the vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
in order to enforce the vrf_id to return, from a vrf name, a check is
done on the vrf_name_to_id callback.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is the last missing piece to complete BGP LU support in bgpd. To this moment, bgpd (and zebra) supported auto label assignment only for prefixes leaked from VRFs to vpn and for MPLS SR prefixes. This adds auto label assignment to other routes types in bgpd. The following enhancements have been made:
* bgp_route.c:bgp_process_main_one() now sets implicit-null local_label to all local, aggregate and redistributed routes.
* bgp_route.c:bgp_process_main_one() now will request a label from the label pool for any prefix that loses the label for some reason (for example, when the static label assignment config is removed)
* bgp_label.c:bgp_reg_dereg_for_label() now requests labels from label pool for routes which have no associated label index
* zebra_mpls.c:zebra_mpls_fec_register() now expects both label and label_index from the calling function, one of which must be set to MPLS_INVALID_LABEL or MPLS_INVALID_LABEL_INDEX, based on this it will decide how to register the provided FEC.
Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
The same issue with derived enum types that was already fixed
for yang_data_new_enum was still present here, so I simply
applied the same fix.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Just copying th const char* of the xpath means that if we
are enqueing multiple changes from a buffer, the last xpath
addedd will overwrite all of the previous references.
Copying the xpath to a buffer simplifies the API when
retrofitting the commands.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
As suggested by Renato, add error codes that are specific
to the various phases of a northbound callback. These can
be used by the daemons when logging an error. The reasoning
is that validation errors typically mean that there is an
inconsistency in the configuration, a prepare error means
that we are running out of resources, and abort/apply errors
are bugs that need to be reported to the devs.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
I accidentally put MIT headers on these; the intent was ISC. It doesn't
really make a difference, but let's get it consistent.
Signed-off-by: David Lamparter <equinox@diac24.net>
Support an optional timeout/delay for use when a workqueue
determines that it is blocked, instead of retrying immediately.
Also, schedule as an 'event' instead of a 'timer' when using
a zero timeout value.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Reorder the numbering of the Zebra message flags and document
what each flag is supposed to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We never used this information and it was merely stored.
Additionally this is not something that is a flag, it's
a status.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Newer versions of clang are failing on xpath length
not being sufficiently sized to hold all possible data
that could be thrown at it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
YANG allows lists without keys for operational data, in which case
the list elements are uniquely identified using a positional index
(starting from one).
This commit does the following:
* Remove the need to implement the 'get_keys' and 'lookup_entry'
callbacks for keyless lists.
* Extend nb_oper_data_iter_list() so that it special-cases keyless
lists appropriately. Since both the CLI and the sysrepo plugin
use nb_oper_data_iterate() to fetch operational data, both these
northbound clients automatically gain the ability to understand
keyless lists without additional changes.
* Extend the confd plugin to special-case keyless lists as well. This
was a bit painful to implement given ConfD's clumsy API, but
keyless lists should work ok now.
* Update the "test_oper_data" unit test to test keyless YANG lists in
addition to regular lists.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
ConfD and Sysrepo implement configuration transactions using a
two-phase commit protocol (prepare + abort/apply). For network-wide
transactions to work, ConfD and Sysrepo move to the second phase of
the commit protocol only after receiving the results of the first
phase from all devices involved in the transaction. If all devices
succeed in the 'prepare' phase, then all of them move to the 'apply'
phase and the transaction is committed. On the other hand, if any
device fails in the 'prepare' phase, all of them move to 'abort'
phase and the transaction is aborted.
The confd and sysrepo plugins were implementing the full
two-phase commit protocol upon receiving a request to validate
the configuration changes and allocate all resources required to
apply them (first phase). The notifications to abort or apply the
changes (second phase) were being ignored since everything was being
done in the first phase for simplicity. This wasn't a problem for
single-device transactions, but it is for transactions involving
multiple devices. Rework the code a bit to do things properly and
fix this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The "show" command will be available in the configuration mode and
all configuration subnodes. It's used to display the section of
the candidate configuration being edited, instead of displaying
the entire candidate configuration like when "show configuration
candidate" is used. The goal is to add more convenience when editing
huge configurations.
When the transactional CLI mode is not used, the candidate
configuration and the running configuration are identical, hence in
this case we can say that the "show" command displays the section
of the running configuration being edited.
Example:
ripd(config)# show
Configuration:
!
frr version 6.1-dev
frr defaults traditional
!
interface eth0
ip rip split-horizon poisoned-reverse
ip rip authentication mode md5
ip rip authentication string supersecret
!
interface eth1
ip rip receive version 1
ip rip send version 1
!
router rip
allow-ecmp
route 10.0.1.0/24
route 10.0.2.0/24
!
end
ripd(config)#
ripd(config)#
ripd(config)# interface eth0
ripd(config-if)# show
!
interface eth0
ip rip split-horizon poisoned-reverse
ip rip authentication mode md5
ip rip authentication string supersecret
!
ripd(config-if)# exit
ripd(config)#
ripd(config)#
ripd(config)# router rip
ripd(config-router)# show
!
router rip
allow-ecmp
route 10.0.1.0/24
route 10.0.2.0/24
!
ripd(config-router)#
The "show" command only works for daemons converted to the new
northbound model. vtysh support will be implemented at a later
time as it will require some level of coordination between vtysh
and the FRR daemons.
Fixes#3148.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Confirmed commits allow the user to request an automatic rollback to
the previous configuration if the commit operation is not confirmed
within a number of minutes. This is particularly useful when the user
is accessing the CLI through the network (e.g. using SSH) and any
configuration change might cause an unexpected loss of connectivity
between the user and the managed device (e.g. misconfiguration of a
routing protocol). By using a confirmed commit, the user can rest
assured the connectivity will be restored after the given timeout
expires, avoiding the need to access the router physically to fix
the problem.
When "commit confirmed TIMEOUT" is used, a new "commit" command is
expected to confirm the previous commit before the given timeout
expires. If "commit confirmed TIMEOUT" is used while there's already
a confirmed-commit in progress, the confirmed-commit timeout is
reset to the new value.
In the current implementation, if other users perform commits while
there's a confirmed-commit in progress, all commits are rolled back
when the confirmed-commit timeout expires. It's recommended to use
the "configure exclusive" configuration mode to prevent unexpected
outcomes when using confirmed commits.
When an user exits from the configuration mode while there's a
confirmed-commit in progress, the commit is automatically rolled
back and the user is notified about it. In the future we might
want to prompt the user if he or she really wants to exit from the
configuration mode when there's a pending confirmed commit.
Needless to say, confirmed commit only work for configuration
commands converted to the new northbound model. vtysh support will
be implemented at a later time.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
