kssoman [Fri, 17 Aug 2018 15:47:48 +0000 (08:47 -0700)]
zebra : Zebra does not properly track which route-maps are changed (#2493)
* Check for the modified routemap in zebra_route_map_process_update_cb()
* Added zebra_rib_table_rm_update() for RIB routemap processing
* Added zebra_nht_rm_update() for NHT routemap processing
lib, vtysh: fix inconsistent interface commands in vtysh
The definition of the interface commands in vtysh.c were outdated.
Currently, all daemons that call if_cmd_init() will have the "no interface
IFNAME" command and the "[no] description" commands as well, so there's
no need to define exceptions for these commands anymore.
To fix this, make extract.pl parse the if.c file so that vtysh can get the
interface commands from there automatically. Only the "interface IFNAME
[vrf NAME]" must be kept in vtysh.c because it changes the vty node and
thus needs special treatment.
Finally, make pimd and pbrd display interface descriptions on "sh run"
when they are configured.
lib, vtysh: fix inconsistent VRF commands in vtysh
* Only zebra and pimd call vrf_cmd_init(), so these are the only daemons
that should receive VRF commands from vtysh;
* "netns NAME" and "no netns NAME" are available only in zebra, write
custom DEFSHs in vtysh to make it aware of that;
* Remove the "no vrf NAME" definition from vtysh.c and expose the
original command to vtysh by converting the DEFUN_NOSH to a simple
DEFUN. This command doesn't change the vty node so there's no need to
special case it.
We must hide only "pseudowire IFNAME" from vtysh, the "no" form of the
command should be made available to the extract.pl script. Split the
command into two to fix this problem.
All ldpd commands were written using DEFPY except the ones that needed
to be ignored by vtysh, in which case we were using DEFUN_NOSH. Now that
DEFPY_NOSH is available, convert the remaining commands for consistency
and to simplify the code a little bit.
The correction in commit 7edb6aa (PR #2502) was wrong, as it is was not
taking in consideration the unlock counter. Thanks to @eqvinox for noticing
it.
Donald Sharp [Thu, 14 Jun 2018 12:58:05 +0000 (08:58 -0400)]
*: ALLOC calls cannot fail
There is no need to check for failure of a ALLOC call
as that any failure to do so will result in a assert
happening. So we can safely remove all of this code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don Slice [Thu, 9 Aug 2018 21:24:24 +0000 (21:24 +0000)]
tools: correct frr-reload.py handling of bgp vni/exit-vni config
Problem reported that when a peer-group was added in certain
configurations, it would be rejected because of the order of the
commands put in by nclu. Issued turned out to be how frr-reload.py
was handling the sub-sub-context of the vni under the address-family
and subsequently how it handled the following exit-vni.
Ticket: CM-21996 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
David Lamparter [Wed, 8 Aug 2018 10:32:21 +0000 (12:32 +0200)]
pimd: fix bogus uninitialized warning
pimd/pim_nht.c: In function ‘pim_ecmp_nexthop_search’:
pimd/pim_nht.c:523:17: error: ‘nbr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
nexthop->nbr = nbr;
(on gcc 5.4.0; this is the only warning with that version.)
Signed-off-by: David Lamparter <equinox@diac24.net>
Quentin Young [Thu, 2 Aug 2018 18:34:37 +0000 (18:34 +0000)]
tools: improve checkpatch slicing
checkpatch cuts from the diff between the outputs of pre-patch and
post-patch runs of `checkpatch.pl`, but fixed-length greps sometimes
don't cut correctly.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Fri, 3 Aug 2018 12:18:11 +0000 (08:18 -0400)]
lib, bgpd, ospf6d, ospfd, pimd: Allow finish to cleanup a bit more
When calling route_map_finish, every place that we do we must
first set the deletion event to NULL, or we will create an infinite
loop, if we are using the delayed route-map application code.
As such we might as well just make the route_map_finish code
do this work, as that there is really no viable alternative here
and route_map_finish should only be called on shutdown.
This fixes an infinite loop in zebra on shutdown when there
are route-maps.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Christian Franke [Thu, 26 Jul 2018 13:08:11 +0000 (15:08 +0200)]
isisd: don't infer spftree from address family
Instead of using the address family to determine which spftree structure
should be used, specify it explicitly. With the advent of ipv6 dst-src
routing, the tree cannot be uniquely determined from the family.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Thu, 26 Jul 2018 08:02:15 +0000 (10:02 +0200)]
isisd: fix isis_route_merge_verify logic
This addresses two issues for L1L2 operation:
a) If an L1 route has ROUTE_ACTIVE unset and an L2 route for the same
destination has ROUTE_ACTIVE set, isisd would still put the L1 route
into the merged table. This causes the route for the destination to
get uninstalled from zebra until the next SPF run, which is incorrect.
To fix this, look at the ROUTE_ACTIVE flag and allow L2 routes to win
against L1 routes, when the L1 has ROUTE_ACTIVE unset.
b) If an L1 route wins against an existing L2 route, the ZEBRA_SYNCED
flag would remain on the L2 route. This leads to the problem that when
the L1 route disappears again, the L2 doesn't get reinstalled, since
isisd assumes it's already in the RIB because ZEBRA_SYNCED is set.
Solve this by clearing ZEBRA_SYNCED on L2 routes, if they lose against
an L1 route.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Tue, 24 Jul 2018 15:40:24 +0000 (17:40 +0200)]
isisd: move route_table into spftree
As isisd's route_tables are directly related to spf trees, move
the route tables into the spftree instead of maintaining them
alongside of the spftrees.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Sun, 22 Jul 2018 17:59:43 +0000 (13:59 -0400)]
isisd: add debug message if adjacency is ignored because IP is unusable
isisd verifies whether the neighboring IPv4 addresses overlap with its own
unless the interface is running in unnumbered mode. If no overlap is found
and IPv6 is also not enabled, IIHs will be ignored.
Add a debug message for this case, to avoid people wondering why adjacencies
are not coming up.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>