In some circumstances zebra and ldpd would display a pseudowire as UP
when in reality it's not (example: MTU mismatch between the two ends). Fix
this to avoid confusion.
Reported-by: ßingen <bingen@voltanet.io>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
zebra_find_client needs to match on instance as well so
protocols like ospfd will work correctly for notification.
Modify the zebra_find_client code to accept the instance
number and to pass it in appropriately.
Signed-off-by: Doanld Sharp <sharpd@cumulusnetworks.com>
Add a daemon that will allow us to test the zapi
as well as test route install/removal times from
the kernel.
The current commands are:
install route <starting ip address> nexthop <nexthop> (1-1000000)
This command starts installing at <starting ip address>/32
(1-100000) routes that it auto-increments by 1
Installation start time is noted in the log and finish
time is noted as well.
remove routes <starting ip address> (1-1000000)
This command removes routes at <starting ip address>/32
and removes (1-100000) routes created by the install route
command.
This code can be considered experimental and *is not*
something that should be run in a production environment.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are installing into the kernel, not the
change points for notification to a higher level
protocol and make it happen
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the higher level protocol to specify if it would
like to receive notifications about it's routes that
it has installed.
I've purposely made it part of zclient_new_notify because
we need to track the routes on a per daemon basis only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Provide ZAPI code that can pass to an upper level protocol
what happened to it's route on install.
There are these notifications:
1) ZAPI_ROUTE_FAIL_INSTALL - The route attempted to be
installed did not work.
2) ZAPI_ROUTE_BETTER_ADMIN_WON - A route that was installed
has become un-installed due to another routing protocol
installing a better admin distance
3) ZAPI_ROUTE_INSTALLED - The route specified has been installed
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The rib_uninstall_kernel for non-UNICAST routes when
it is marking a route as no-longer installed should
actually mark it as uninstalled.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Rework of do_show_ip_route caused the 'show ip rpf'
cli to stop working. This put's it back into working
order.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The v6 linux kernel netlink code doees not have
route replace semantics. So if we are in that
situation, do a delete/add to get the correct
results.
Fixes: #1461
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the kernel installs/updates a lsp the return code for
success is a 0. The code was interpreting the 0 as a failure
case for the Install/Update code paths. This caused upon
a true deletion zebra loosing knowledge of the lsp
but the kernel still had it installed.
Failure:
mpls label bind 10.50.4.11/32 4444
!
line vty
!
end
robot.cumulusnetworks.com# conf t
robot.cumulusnetworks.com(config)# no mpls lsp 6666 10.50.11.1 3933
robot.cumulusnetworks.com(config)# exit
robot.cumulusnetworks.com# show mpls table 6666
robot.cumulusnetworks.com# exit
sharpd@robot ~/frr4> ip -f mpls route show
6666 as to 3933 via inet 10.50.11.1 dev enp0s10 proto static
With Fix:
sharpd@robot ~/frr4> ip -f mpls route show
6666 as to 3933 via inet 10.50.11.1 dev enp0s10 proto static
sharpd@robot ~/frr4> sudo vtysh
Hello, this is FRRouting (version 3.1-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
robot.cumulusnetworks.com# conf t
robot.cumulusnetworks.com(config)# no mpls lsp 6666 10.50.11.1 3933
robot.cumulusnetworks.com(config)# end
robot.cumulusnetworks.com# show mpls table 6666
robot.cumulusnetworks.com# exit
sharpd@robot ~/frr4> ip -f mpls route show
sharpd@robot ~/frr4>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The LSP_FLAG_CHANGED and LSP_FLAG_INSTALLED flags
should be handled in the common call function
for adding/updating/removing a lsp to/from the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The SET_FLAG(nexthop->flags, NEXTHOP_FLAG_FIB)
is already taken care of in zebra_rib.c. There
is no need for this to be handled by rt_socket.c.
rt_netlink.c does not do a SET_FLAG(nexthop->flags, NEXTHOP_FLAG_FIB)
for route installation. Please note it does do it for a mpls
labeled route installation, which will be fixed in a future
commit.
Remove some dead code from 2002 as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are modifying the kernel there could
be multiple modules/hooks involved in this
process. As such let the caller set
the appropriate flags for success/failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The flags value is not used for unregister events. Let's purposefully
not send anything and purposefully not accept non 0 for it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This code modifies zebra to use the STREAM_GET functionality.
This will allow zebra to continue functioning in the case of
bad input data from higher level protocols instead of crashing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) Write zserv api commands( one of each type ) to the side. This will allow
us to use them as input for a fuzzer.
2) Add -c <file to pass to zapi read process> into zebra as a run-time
option of we've turned on fuzzing.
While in and of itself these are not terribly useful( you still need
an external fuzzer ), they provide an infrastructure to allow
tools like afl to test the zapi.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems reported with zebra nht oscillating when a nexthop is resolved
using the same address to reach the nexthop (for example, 10.0.0.8 is
resolved via 10.0.0.8/32.) This fix removes this attempt to resolve
thru itself unless the route being resolved is also a host route.
This fix also walks up the tree looking for a less specific route to
reach the nexthop if needed. Smoke testing completed successfully.
Ticket: CM-8192
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6583
Testing done: Manual testing successful, bgp-min completed successfully
l3-smoke completed with two test changes required.
The original clippy implementation used if VTYSH_EXTRACT_PL
was defined or not to know to include as part of the creation
of vtysh.
Follow their lead here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to match a specific prefix-length in zebra.
This command behaves in the same manner that the v4 version
of the command behaves.
Fixes: #1398
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The linux kernel passes the IFLA_IFALIAS value. Allow
zebra to read and set the description appropriately.
Currently I don't set the value down into the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The function clear_nhlfe_installed is to be called
when we get a install failure of some sort for
a lsp change. Since an install failure can happen
in both linux and openBSD moving the function call
northbound is a good idea.
I've also added it to the kernel_del_lsp for completeness
on failure as well, even though neither linux or openBSD
currently can fail a uninstall.
This still leaves the hole where if we have multiple
nhlfes and have an install failure we are not quite
doing the right thing by just blanketly calling
clear_nhlfe_installed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the end user to specify how many packets we want
to process at one time coming down the zapi, before
we yield and let other things process.
This is a Hidden command because it is not necessarily
something that we want end users to be able to play with
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Store the number of packets we should process at
one time in `struct zebra_t`. A future commit
will allow the user to control this via
a hidden cli.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the user to modify the work-queue processing hold time
from 10ms to a value from (0-10000). Make the command hidden
as that it's a semi-dangerous command and it could cause
issues.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported with not deleting LSPs from the zebra kernal mpls table
when a delete occurred in bgp. Found that we were exiting the delete
process incorrectly due to not being able to derive the route_type from
the best_nhlre on the lsp while deleting. Since this info was only
needed for route installation, removed this early exit in the case of
deleting the lsp.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-18309
Reviewed By: CCR-6781
Testing Done: Manual testing looks good. mpls tests successful
These are mostly trivial fixes for leaks in the error path of some functions.
The changes in bgpd/bgp_mpath.c deserves a bit of explanation though. In
the bgp_info_mpath_aggregate_update() function, we were allocating memory
for the lcomm variable but doing nothing with it. Since the code for
communities, extended communities and large communities is pretty much
the same in this function, it's clear that this was a copy and paste
error where most of the ext. community code was copied but not all of
it as it should have been.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Now it's possible to specify multiple options when viewing the RIB or
FIB.
Example: 'show ip route 192.168.0.0/16 longer-prefixes tag 10 ospf'
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Note: I had to remove one assert in clidef.py in order to fix a build
error when using a preprocessor string (FRR_IP_REDIST_STR_ZEBRA) inside
a DEFPY command. This should be revisited later.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is the definitive solution to avoid build issues on old Linux
systems, where the system kernel headers might not contain some constants
or macros used by FRR (e.g. MPLS_IPTUNNEL_DST, introduced on 2015).
This is the same strategy adopted by other projects, like iproute2,
libnl, lldpd, strongswan, etc. These header files don't need to be in
sync with upstream, they only need to be updated when necessary (e.g. if
we want to use a new feature introduced by a recent kernel).
Fixes#962 using the solution suggested by David Lamparter.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The zebra_client_read functionality was reading 1 message
from a peer at a time. Modify the code so that we can
read up to 10 at a time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
