Renato Westphal [Mon, 6 May 2019 18:57:02 +0000 (15:57 -0300)]
lib, yang: disable libyang custom user types temporarily
libyang 1.0 introduced a few changes in the user types API, and
these changes made FRR incompatible with libyang 1.x. In order to
ease our migration from libyang 0.x to libyang 1.x, let's disable
our libyang custom user types temporarily so that FRR can work
with both libyang 0.x and libyang 1.x. This should be especially
helpful to the CI systems during the transition. Once the migration
to libyang 1.x is complete, this commit will be reverted.
Disabling our libyang custom user types should have only
minimal performance implications when processing configuration
transactions. The user types infrastructure should be more important
in the future to perform canonization of YANG data values when
necessary.
F. Aragon [Wed, 10 Apr 2019 17:08:50 +0000 (19:08 +0200)]
zebra: pseudowire event recovery (DoS fix)
When having a route recovery, because of the route installation
cycling and the next hop label check, it could happen that the PW
never gets recovered. The original code shows the intention of retrying,
but the code was missing. The fix includes the call to the timer programming
the recovery attempt.
Example for reproducing the issue:
|P1| <-> |P2| <-> |P3|
- Being P1, P2, P3 nodes, using IS-IS as IGP, and having a pseudowire
betwen P1 and P3 (P1, P2, P3 having configured LDP daemons).
- After 60 seconds, kill the IS-IS daemon in P2.
- Wait 30 seconds
- Launch again the IS-IS daemon in P2
- The bug/issue is that after P1 <-> P3 recovering connectivity sometimes
the PW is not recovered because the reason explained in the first paragraph.
F. Aragon [Fri, 5 Apr 2019 13:26:14 +0000 (15:26 +0200)]
zebra: label manager race condition fix
This fix covers the case where two or more events are processed but only one
becoming effective. E.g. when mixing a synchronous label request from a LDP
deamon and an asynchronous request from a BGP daemon it could happen to the
BGP having the label chunk, but the LDP stuck waiting for the response.
Donald Sharp [Wed, 28 Nov 2018 23:46:36 +0000 (18:46 -0500)]
bgpd: interface based peers should automatically override it's peer group
When a interface based peer is setup and if it is part of a peer
group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE
no matter what.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 29 Mar 2019 02:08:37 +0000 (22:08 -0400)]
bfdd, nhrpd, pimd: When deleting an interface clean up
When we delete an interface, we need to set the interface
ifindex to an internal value so that we don't end up in
a state where the re-addition of the same ifindex, due to
a rename operation, causes an infinite loop.
Fixes:#4007 Fix-Suggested-by: Saravanan K Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
while labeled_unicast routes should be fetched in the
unicast table, we cannot set the safi to SAFI_UNICAST
else the peer afc checks and subgroup retrieval will fail
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Donald Sharp [Mon, 11 Mar 2019 13:39:19 +0000 (09:39 -0400)]
zebra: System routes sometimes can not be properly selected
System Routes if received over the netlink bus in a
specific pattern that causes an update operation for that
route in zebra can leave the dest->selected_fib pointer NULL,
while having the ZEBRA_FLAG_SELECTED flag set. Specifically
one way to achieve this is to do this:
`ip addr del 4.5.6.7/32 dev swp1 ; ip addr add 4.5.6.7/32 dev swp1 metric 9`
Why is this a big deal?
Because nexthop tracking is looking at ZEBRA_FLAG_SELECTED to
know if we can use a route, while nexthop active checking uses
dest->selected_fib.
So imagine we have bgp registering a nexthop. nexthop tracking in
the above case will be able to choose the 4.5.6.7/32 route
if that is what the nexthop is, due to the ZEBRA_FLAG_SELECTED being
properly set. BGP then allows the peers connection to come up and we
install routes with a 4.5.6.7 nexthop. The rib processing for route
installation will then look at the 4.5.6.7 route see no
dest->selected_fib and then start walking up the tree to resolve
the route. In our case we could easily hit the default route and be
unable to resolve the route. Which then becomes inactive in the
rib so we never attempt to install it.
This commit fixes this problem because when the rib_process decides
that we need to update the fib( ie replace old w/ new ), the
replacement with new was not setting the `dest->selected_fib` pointer
to the new route_entry, when the route was a system route.
Ticket: CM-24203 Signed-off-by: Donald Sharp <sharpd@cumulusnetworkscom>
zebra: set connected route metric based on the devaddr metric
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
In a VRR/VRRP setup we can have connected routes with different costs.
So this change eliminates suppressing metric display for connected routes.
Sample output -
root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1"
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
> - selected route, * - FIB route
VRF vrf1:
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36
C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36
C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36
Donatas Abraitis [Mon, 25 Feb 2019 19:16:02 +0000 (21:16 +0200)]
bgpd: Add peer action for PEER_FLAG_IFPEER_V6ONLY flag
peer_flag_modify() will always return BGP_ERR_INVALID_FLAG because
the action was not defined for PEER_FLAG_IFPEER_V6ONLY flag.
```
global PEER_FLAG_IFPEER_V6ONLY = 16384;
global BGP_ERR_INVALID_FLAG = -2;
probe process("/usr/lib/frr/bgpd").statement("peer_flag_modify@/root/frr/bgpd/bgpd.c:3975")
{
if ($flag == PEER_FLAG_IFPEER_V6ONLY && $action->type == 0)
printf("action not found for the flag PEER_FLAG_IFPEER_V6ONLY\n");
}
probe process("/usr/lib/frr/bgpd").function("peer_flag_modify").return
{
if ($return == BGP_ERR_INVALID_FLAG)
printf("return BGP_ERR_INVALID_FLAG\n");
}
```
produces:
action not found for the flag PEER_FLAG_IFPEER_V6ONLY
return BGP_ERR_INVALID_FLAG
[7.0] bgpd: Incorrect number of peers count in "show bgp ipv6 summary" output
The "show bgp ipv6 summary" output displays incorrect number of peers count.
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 5, using 103 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
In the above output, the peers count displays as 5 but the actual peer count is 3, i.e.. 3 neighbors are activated in ipv6 unicast address family.
Displayed peer count (5) is the number of the neighbors activated in a BGP instance.
Fix : Now the peers count displays the number of neighbors activated per afi/safi.
After Fix:
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 3, using 62 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
[7.0] bgpd: 'show bgp [ipv4|ipv6] neighbors' displays all address family neighbors
Display only ipv4 neighbors when 'show bgp ipv4 neighbors' command is issued.
Display only ipv6 neighbors when 'show bgp ipv6 neighbors' command is issued.
Take the address family of the peer address into account, while displaying the neighbors.
Mark Stapp [Wed, 6 Mar 2019 15:41:47 +0000 (10:41 -0500)]
libs: make privs elevation thread-safe
[Double-commit PR 3911 to 7.0] Privs elevation is per-process,
and can deadlock if a multiple threads drive into the uid system
call. Add a refcount and a mutex to avoid reentrant calls to
the OS.
Renato Westphal [Sat, 2 Mar 2019 20:45:14 +0000 (17:45 -0300)]
ripd: fix removal of configured passive interfaces
libyang-0.16-rc3 fixed a bug [1] in which data would be auto-deleted
when it shouldn't. The problem is that the "no passive-interface"
command was relying on that wrong behavior, so the command was
affected when the libyang bug was fixed. Adapt the command to do
the right thing in order to get rid of the problem (regardless of
the libyang version being used).
"passive-interface default" still has problems though, but that
will be addressed separetely in the future.
Donald Sharp [Fri, 1 Mar 2019 18:56:12 +0000 (13:56 -0500)]
zebra: When installing a new route always use REPLACE
When we install a new route into the kernel always use
REPLACE. Else if the route is already there it can
be translated into an append with the flags we are
using.
This is especially true for the way we handle pbr
routes as that we are re-installing the same route
entry from pbr at the moment.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Tue, 26 Feb 2019 21:22:27 +0000 (18:22 -0300)]
bgpd: add missing checks for vpnv6 nexthop lengths
A few code paths weren't handling the vpnv6 nexthop lenghts as
expected, which was leading to problems like imported vpnv6 routes
not being marked as valid when they should. Fix this.
Martin Winter [Thu, 28 Feb 2019 23:32:04 +0000 (15:32 -0800)]
FRRouting Release 7.0
Major Changes since 6.0.x:
- Added libyang dependency: New work for northbound interface based on libyang
- Fabricd: New Daemon based on https://datatracker.ietf.org/doc/draft-white-openfabric/
- various bug fixes and other enhancements
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
==17102== Invalid read of size 8
==17102== at 0x44D84C: rib_dest_from_rnode (rib.h:375)
==17102== by 0x4546ED: rib_process_result (zebra_rib.c:1904)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102== Address 0x83bd468 is 88 bytes inside a block of size 96 free'd
==17102== at 0x4A35F54: free (vg_replace_malloc.c:530)
==17102== by 0x4CCAC00: qfree (memory.c:129)
==17102== by 0x4D03DC6: route_node_destroy (table.c:501)
==17102== by 0x4D039EE: route_node_free (table.c:90)
==17102== by 0x4D03971: route_node_delete (table.c:382)
==17102== by 0x44D82A: route_unlock_node (table.h:256)
==17102== by 0x454617: rib_process_result (zebra_rib.c:1882)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102== Block was alloc'd at
==17102== at 0x4A36FF6: calloc (vg_replace_malloc.c:752)
==17102== by 0x4CCAA2D: qcalloc (memory.c:110)
==17102== by 0x4D03D88: route_node_create (table.c:489)
==17102== by 0x4D0360F: route_node_new (table.c:65)
==17102== by 0x4D034F8: route_node_set (table.c:74)
==17102== by 0x4D03486: route_node_get (table.c:327)
==17102== by 0x4CFB700: srcdest_rnode_get (srcdest_table.c:243)
==17102== by 0x4545C1: rib_process_result (zebra_rib.c:1872)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102==
This is happening because of this order of events:
1) Route is deleted in the main thread and scheduled for rib processing.
2) Rib garbage collection is run and we remove the route node since it
is no longer needed.
3) Data plane returns from the deletion in the kernel and we call
the srcdest_rnode_get function to get the prefix that was deleted.
This recreates a new route node. This creates a route_node with
a lock count of 1, which we freed via the route_unlock_node call.
Then we continued to use the rn pointer. Which leaves us with use
after frees.
The solution is, of course, to just move the unlock the node at the
end of the function if we have a route_node.
Fixes: #3854 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Martin Winter [Wed, 20 Feb 2019 13:09:03 +0000 (05:09 -0800)]
redhat: Require newer libyang (> 0.16.74) for embedded extensions
The support of embedded extensions doesn't allow to build the
RPM with and without (for older version). Require new version of
Lbyang with embedded extensions supported
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Renato Westphal [Wed, 20 Feb 2019 18:54:32 +0000 (15:54 -0300)]
bgpd: fix the add-path code to understand the mpls-vpn safi
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The add-path code wasn't doing this, which was leading to lots of
crashes when add-path was enabled for the MPLS VPN SAFI. This patch
fixes the problem.
Renato Westphal [Wed, 20 Feb 2019 18:37:29 +0000 (15:37 -0300)]
bgpd: fix null pointer dereference bug
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ff7b267a42a in __GI_abort () at abort.c:89
#2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
#3 <signal handler called>
#4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
#5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
#6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
#7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
#8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
#9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481
Renato Westphal [Wed, 20 Feb 2019 18:36:50 +0000 (15:36 -0300)]
isisd: fix crash when entering "no ip[v6] router isis" twice
isisd CLI has some housekeeping code that removes the
"frr-isisd:isis" container from the interface configuration when
IS-IS is disabled for both IPv4 and IPv6 in the corresponding
interface.
The problem is that the code was checking the values of the
"ipv4-routing" and "ipv6-routing" leafs without checking if the
parent "frr-isisd:isis" container was present. So, entering "no
ip[v6] router isis" twice would cause isisd to crash since the
"frr-isisd:isis" container wouldn't be present the second time the
command is processed. Fix this.
isisd aborted: vtysh -c "configure terminal" -c "interface eth99" -c "no ip router isis WORD"
isisd aborted: vtysh -c "configure terminal" -c "interface eth99" -c "no ipv6 router isis"
Renato Westphal [Wed, 20 Feb 2019 18:32:55 +0000 (15:32 -0300)]
pbrd: fix removal of ipv6 nexthops
Fix bug in the code that compares IPv6 addresses. If memcmp()
returns 0 then the two addresses are equal.
Because of this problem, hash_release() could return NULL in a few
places, leading to the following crashes (found by the CLI fuzzer):
pbrd aborted: vtysh -c "configure terminal" -c "pbr-map WORD seq 100" -c "no set nexthop 2001:db8::1"
pbrd aborted: vtysh -c "configure terminal" -c "nexthop-group NHGROUP" -c "no nexthop 2001:db8::1"
David Lamparter [Mon, 18 Feb 2019 23:27:45 +0000 (00:27 +0100)]
tools: fix new init script wrt. multi-instance
TBH when I looked at watchfrr I didn't see any MI support and hence
assumed this just didn't work to begin with. However, it actually does
(transparently to watchfrr, by just using "ospfd-1" as daemon name.)
So, fix this up and make it work again.
(Also remove 2 extraneous \n in messages.)
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Thu, 24 Jan 2019 17:17:40 +0000 (18:17 +0100)]
watchfrr: build in defaults for -r/-s/-k
There's no good reason to not have these options default to the
installation path of tools/watchfrr.sh. Doing so allows us to ditch
watchfrr_options from daemons/daemons.conf completely.
Fixes: #3652 Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Mon, 4 Feb 2019 19:16:34 +0000 (20:16 +0100)]
debian: add missing Conflicts:
We were missing several Conflicts: (or Breaks:) lines. Specifically,
- the .png diagrams in frr-doc conflict with quagga-doc
- the quagga package was split up and we conflict on each on the
daemon's man pages
- pimd also conflicts on the man page.
This is a "conservative" fix for the time being, putting everything into
Conflicts:. Some of these might have other options to fix them (e.g.
renaming the diagrams or man pages) but that needs more thought and
isn't appropriate for a simple fix.
There is also the "layer 9" consideration of whether to add "Replaces:
quagga" lines. For the time being I'd say it's a bit early to have that
discussion.
Reported-by: Andreas Beckmann <anbe@debian.org>
References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921376 Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Mon, 4 Feb 2019 03:52:16 +0000 (04:52 +0100)]
debian: remove bogus libjson0 dependency
Dependencies for the actual library packages are autogenerated by shlib
handling. Removing the bogus line should hopefully get this to build
on Debian buildd...
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Sun, 27 Jan 2019 16:24:36 +0000 (17:24 +0100)]
debian: extend comments on pre/postinst hooks
While originally created to support upgrading within non-official
previous FRR packages, the same logic makes upgrading from Quagga
configs more straightforward.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 23 Jan 2019 13:15:52 +0000 (14:15 +0100)]
vtysh: fix pager compatibility handling
I just straight up forgot checking VTYSH_PAGER at startup, and the
"terminal paginate" command is only installed to VIEW_NODE so it can't
be processed from vtysh.conf in CONFIG_NODE...
Signed-off-by: David Lamparter <equinox@diac24.net>
Renato Westphal [Sat, 19 Jan 2019 19:24:09 +0000 (17:24 -0200)]
python: make DEFPY provide the text token of fixed parameters
In the CLI code, each cmd_token has both a "text" field, containing
the full token text (e.g. "unicast"), and an "arg" field,
containing the original text entered by the user (which might be
an abbreviation, like "uni" instead of "unicast").
To avoid the need to handle abbreviations, the recommended pattern
for DEFUN commands is to use the "text" value of fixed parameters
and the "arg" value of everything else.
Using DEFPY, however, the CLI parameters are automagically turned
into C variables which are initialized under the hood (so that
they're conveniently ready for use). The problem is that this
initialization was always using the "arg" value of the parameters,
which was leading to problems like these:
debian# show ipv6 route isi
Unknown route type
debian#
debian# conf t
debian(config)# router isis 1
debian(config-router)# redistribute ipv4 st level-1
% Configuration failed.
Invalid value "st" in "protocol" element.
YANG path: /frr-isisd:isis/instance[area-tag='1']/redistribute/ipv4[protocol='st']/protocol
To fix these problems (and probably others too), make DEFPY commands
auto-detect the type of the input parameters and use either the
"arg" or "text" value from the cmd_tokens accordingly.
Renato Westphal [Sat, 19 Jan 2019 19:19:13 +0000 (17:19 -0200)]
lib: remove the vrf_is_mapped_on_netns() function
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.
Renato Westphal [Sat, 19 Jan 2019 19:19:13 +0000 (17:19 -0200)]
zebra, lib: send VRF backend to the client daemons
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.
Renato Westphal [Sat, 19 Jan 2019 01:23:45 +0000 (23:23 -0200)]
lib: simplify detection of when the user is leaving the CLI config mode
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).
projects / mirror / frr.git / log