Quentin Young [Fri, 25 Aug 2017 17:39:13 +0000 (13:39 -0400)]
lib: fix rare bug in ambiguous command resolution
In certain situations, the CLI matcher would not handle ambiguous
commands properly. If it found an ambiguous result in a lower subgraph,
the ambiguous result would not correctly propagate up to previous frames
in the resolution DFS as ambiguous; instead it would propagate up as a
non-match, which could subsequently be overridden by a partial match.
Example CLI space:
show ip route summary
show ip route supernet-only
show ipv6 route summary
Entering `show ip route su` would result in an ambiguous resolution for
the `show ip route` subgraph but would propagate up to the `show ip`
subgraph as a no-match, allowing `ip` to partial-match `ipv6` and
execute that command.
In this example entering `show ip route summary` would disambiguate the
`show ip` subgraph. So this bug would only appear when entering input
that caused ambiguities in at least two parallel subgraphs.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
David Lamparter [Fri, 25 Aug 2017 16:54:13 +0000 (18:54 +0200)]
clippy: disable unneeded autogenerated code
Coverity is generating a lot of warnings about unused stuff being
around. Disabling these bits is most easily done by just putting a few
preprocessor directives into the template.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Thu, 24 Aug 2017 13:55:19 +0000 (09:55 -0400)]
pimd: Cleanup S,GRPt prune handling on Mroute Loss
1) Clean up display of S,GRPt prune state to be more meaningful
2) Upon receipt of a S,GRPt prune make sure we transition to
the correct state
3) Upon loss of a S,GRPt prune make sure we transition to
the correct state as well as immediately send a *,G
join upstream to propagate the loss of the prune.
4) Removal of a weird S,G state being installed upon
loss of a S,G RPt prune.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 24 Aug 2017 12:30:08 +0000 (08:30 -0400)]
lib: Fix nexthop num
If we assign MULTIPATH_NUM to be 256, this causes issues
for us since 256 is bigger than a u_char. So let's make
the api's multipath_num to be a u_int16_t and pass it
around as a word.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 22 Aug 2017 18:40:24 +0000 (14:40 -0400)]
eigrpd: Start split-horizon
EIGRP was not handling split-horizon. This code starts
down the path of properly considering it. There still
exists situations where we are not properly handling it
though.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Mon, 21 Aug 2017 22:43:43 +0000 (19:43 -0300)]
ospf6d: fix regression detected by topotest
With the old API, ospf6d always needed to send a nexthop address and a
nexthop interface when advertising a route to zebra. In the case where
the nexthop address didn't exist (e.g. connected route), zebra would
take care of ignore it in the zread_ipv6_add() function.
Now, if we have a nexthop interface but not a nexthop address, we not
only can but we should send a nexthop of type NEXTHOP_TYPE_IFINDEX. zebra
won't fix bad nexthops anymore because the clients have a proper API to
send correct messages.
Renato Westphal [Mon, 21 Aug 2017 01:10:50 +0000 (22:10 -0300)]
*: use zapi_route to send/receive redistributed routes as well
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
there's no dependency between libraries and other things to be
installed, but libtool in its 90ies design wants to relink libraries
when installing them. Add manual dependencies to work around this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 23 Aug 2017 14:54:15 +0000 (16:54 +0200)]
ospf6d: properly update prefix list references
Register add/delete hooks with the prefix list code to properly change
ospf6_area's prefix list in/out pointers.
There are 2 other uncached uses of prefix lists in the ASBR route-map
code and the interface code; these should probably be cached too. (To
be fixed another day...)
Fixes: #453 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 23 Aug 2017 14:23:17 +0000 (16:23 +0200)]
lib: fix cosmetic issue with exit race
if we're using --terminal, the daemon may in some cases exit fast enough
for the parent to see this; this resulted in a confusing/bogus "failed
to start, exited 0" message.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 23 Aug 2017 14:18:49 +0000 (16:18 +0200)]
lib: centralized memstats-at-exit
adds a new all-daemon "debug memstats-at-exit" command. Also saves
memstats to a file in /tmp, useful if a long-running daemon is having
weird issues (e.g. in a user install).
Fixes: #437 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
As noticed in 657cde1, the zapi_ipv[4|6]_route functions are broken in
many ways and that's the reason that many client daemons (e.g. ospfd,
isisd) need to send handcrafted messages to zebra.
The zapi_route() function introduced by Donald solves the problem
by providing a consistent way to send ipv4/ipv6 routes to zebra with
nexthops of any type, in all possible combinations including IPv4 routes
with IPv6 nexthops (for BGP unnumbered routes).
This patch goes a bit further and creates two new address-family
independent ZAPI message types that the client daemons can
use to advertise route information to zebra: ZEBRA_ROUTE_ADD and
ZEBRA_ROUTE_DELETE. The big advantage of having address-family independent
messages is that it allows us to remove a lot of duplicate code in zebra
and in the client daemons.
This patch also introduces the zapi_route_decode() function. It will be
used by zebra to decode route messages sent by the client daemons using
zclient_route_send(), which calls zapi_route_encode().
Later on we'll use this same pair of encode/decode functions to
send/receive redistributed routes from zebra to the client daemons,
taking the idea of removing code duplication to the next level.
Renato Westphal [Sun, 20 Aug 2017 00:25:12 +0000 (21:25 -0300)]
lib: updates to zapi_route
This patch introduces the following changes to the zapi_route structure
and associated code:
* Use a fixed-size array to store the nexthops instead of a pointer. This
makes the zapi_route() function much easier to use when we have multiple
nexthops to send. It's also much more efficient to put everything on
the stack rather than allocating an array in the heap every time we
need to send a route to zebra;
* Use the new 'zapi_nexthop' structure. This will allow the client daemons
to send labeled routes without having to allocate memory for the labels
(the 'nexthop' structure was designed to be memory efficient and doesn't
have room for MPLS labels, only a pointer). Also, 'zapi_nexthop' is more
compact and more clean from an API perspective;
* Embed the route prefix inside the zapi_route structure. Since the
route's prefix is sent along with its nexthops and attributes, it makes
sense to pack everything inside the same structure.
Renato Westphal [Sat, 19 Aug 2017 17:26:00 +0000 (14:26 -0300)]
zserv: simplify handling of route delete requests
Route attributes like tag, distance and metric are irrelevant when we
want to delete a route from a client daemon. The same can be said about
the nexthops of the route. Only the IP prefix and client protocol are
enough to identify the route we want to remove, considering that zebra
maintains at most one route from each client daemon for each prefix. Once
rib_delete() is called, it deletes the selected route with all of its
nexthops.
Renato Westphal [Tue, 22 Aug 2017 20:01:54 +0000 (17:01 -0300)]
zebra: increase maximum label stack depth
* Bump MPLS_MAX_LABELS from 2 to 16;
* Adjust the static_nh_label structure and the mpls_label2str() function;
* On OpenBSD, print an error message when trying to push more than one
label at once (kernel limitation). While here, add support for MPLSv6
FTNs in OpenBSD.
This is not the full package. We still can't pop multiple labels at once,
or do things like swap a label and push other ones. We'll address that
in the future.
Renato Westphal [Tue, 22 Aug 2017 13:52:07 +0000 (10:52 -0300)]
zebra: fix display of static routes pointing to nonexistent interfaces
Bug introduced a couple of weeks ago by myself. Only happens when the
route has an IP nexthop + a nexthop interface.
Example:
debian(config)# ip route 10.0.1.0/24 172.16.1.10 fake1
debian(config)# do sh run
Building configuration...
[snip]
!
ip route 10.0.1.0/24 172.16.1.10 unknown
!
end
David Lamparter [Tue, 22 Aug 2017 13:27:08 +0000 (15:27 +0200)]
lib: fix const-check in route_node
route_node->lock is "const" if --enable-dev-build is used. This is done
to deter people from messing with internals of the route_table...
unfortunately, the inline'd route_[un]lock_node runs into this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
projects / mirror / frr.git / log