Initial changes to support a nexthop with multiple backups. Lib
changes to hold a small array in each primary, zapi message
changes to support sending multiple backups, and daemon
changes to show commands to support multiple backups. The config
input for multiple backup indices is not present here.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Distinguish between unicast and broadcast opaque messages
in zebra handler code. Add cli and internal api changes to
have sharpd send unicast opaque messages. Add opaque cli
commands to the sharp user doc.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
If present in a configured nexthop_group, include
backup nexthop/nhlfe info with LSP zapi add/update
messages.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
With the command using STR_SHARP, the sharp daemon is not allowed
to use it's own routes for label modification. Switching over
to STR_ZEBRA allows the sharp daemon to modify labels on any
route in the system, since there are no `ROUTE_ZEBRA` types.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This just generates log messages in bulk for testing logging backend
performance. It's in sharpd so the full "context" of being in a daemon
is available (e.g. different logging configs, parallel load in the main
thread.)
Signed-off-by: David Lamparter <equinox@diac24.net>
First round of support for exercising the lsp and ftn paths
using sharpd. This supports lsp-only, and binding to
ipv4 prefix. Also use the common lib nexthop-to-zapi
helper api instead of sharpd's open-coded version.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Current autocompletion works only for simple "vrf NAME" case.
This commit expands it also for the following cases:
- "nexthop-vrf NAME" in staticd
- usage of $varname in many daemons
All daemons are updated to use single varname "$vrf_name".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Instead of defaulting the import-check to a /32
allow the tester to specify any prefix that they want
when doing an import-check.
Test:
donna.cumulusnetworks.com# sharp watch import
A.B.C.D/M The v4 prefix for import check to watch
X:X::X:X/M The v6 prefix to signal for watching
donna.cumulusnetworks.com# sharp watch import 4.5.6.0/24
donna.cumulusnetworks.com# show ip import-check
4.5.6.0
resolved via kernel
via 10.50.11.1, enp0s3
Client list: sharp(fd 21)
donna.cumulusnetworks.com# sharp watch import 4:5:6::0/64
donna.cumulusnetworks.com# show ipv6 import-check
4:5:6::
resolved via kernel
fe80::cad7:19ff:fe0a:fdfd, via enp0s3
fe80::ce37:abff:fe4f:a601, via enp0s3
Client list: sharp(fd 21)
donna.cumulusnetworks.com# sharp watch nexthop
A.B.C.D The v4 address to signal for watching
X:X::X:X The v6 nexthop to signal for watching
donna.cumulusnetworks.com# sharp watch nexthop 4.5.6.7
donna.cumulusnetworks.com# sharp watch nexthop 4:5::6:7
donna.cumulusnetworks.com# show ip nht
4.5.6.7
unresolved
Client list: sharp(fd 21)
donna.cumulusnetworks.com# show ipv6 nht
4:5::6:7
unresolved
Client list: sharp(fd 21)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Various compilers in our CI system were complaining about various
auto-conversions. Let's get these cleaned up a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability for the sharp zebra code to pass down the
vrf that we want to watch. At this point in time, we
cannot use it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a bit of code to allow the end user to specify a [vrf NAME]
for route installation/deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the sharp code to allow for vrf route installation. At
this point in time the code is nascent. Future commits will turn
on this behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Minor code modification to allow the sharp_zebra.c code
to differentiate between import check or nexthop watch
types.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you are using the install/remove routes command, the
output goes to a log file. This command allows for ease
of dump of timing information from the vty or vtysh.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the sharp daemon to specify whether or not a watched
nexthop should be connected or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Not sure why this wasn't caught by our CI system. I thought it
would. My screw up this should have been right from the start.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Add a bit of test code to allow the tester to install/uninstall
the routes via:
sharp install routes A.B.C.D nexthop Y.Z.M.D 1000000 repeat 100
This will install 1000000 routes wait for them to be finished
then uninstall them then start installation over 100 times.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Abstract the route install/delete functions a bit to allow me to
expand on them in the with future commits.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When installing routes via sharpd 'sharp install route... ' command
add the ability to specify a nexthop-group to use. This will
allow sharpd to create ECMP routes into zebra.
Nexthop-group:
!
nexthop-group JANELLE
nexthop 192.168.209.1
nexthop 192.168.210.1
!
The install:
donna.cumulusnetworks.com# sharp install routes 10.0.50.0 nexthop-group JANELLE 10
donna.cumulusnetworks.com# end
donna.cumulusnetworks.com# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route
K>* 0.0.0.0/0 [0/106] via 10.0.2.2, enp0s3, 00:20:38
C>* 10.0.2.0/24 is directly connected, enp0s3, 00:20:38
D>* 10.0.50.0/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.1/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.2/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.3/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.4/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.5/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.6/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.7/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.8/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.9/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:20:38
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:20:38
donna.cumulusnetworks.com#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the route_add function to take nexthop groups. Future commits
will allow sharpd to use nexthop groups as the install mechanism
for routes.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add code to sharpd to allow it to register for nexthop tracking
and then to display when it receives information about the nexthop
it is watching.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to pass in an afi to zebra. zebra_vrf keeps
track of the afi/label tuple and then does the right thing
before we call down. AF_MPLS does not care about v4 or v6
it just knows label and what device to use for lookup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify mpls.h to rename MPLS_LABEL_ILLEGAL to be MPLS_LABEL_NONE.
Fix all pre-existing code that used MPLS_LABEL_ILLEGAL.
Modify the zapi vrf label message to use MPLS_LABEL_NONE as the
signal to remove label associated with a vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The commands if not careful needed a way to isolate
themselves from each other and 'real' system commands
so let's put them under the sharp keyword.
Signed-off-by: Donald 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>
