There exists a case where a switch already has
a eigrp_prefix_entry for a interface that is
coming up.
In this situation, we need to use the FSM
to let the connected route take precedence
instead of blindly just updating the world
about it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If the new nexthop is external while the previous
best was Internal or Connected, it should always loose.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We need to eventually be able to handle multiple
data types to figure out if the distance is better
worse.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSM was never freeing the msg. Since we
do not have a special queue for it, just don't
allocate the memory. In the future we can put
this back.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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).
Signed-off-by: Renato Westphal <renato@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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is the v6 counterpart of commit c963c20.
Fixes a bug where ipv6 routes received from babeld were being ignored.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Bug introduced by commit 37d361e7. Removing the call to bgp_close()
from bgp_delete() was a mistake.
Reported-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* 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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
