Add new topotest for the Constraints ShortestPath First (CSPF) algorithm.
This topotest uses IS-IS-TE as base network to populate a Traffic Engineering
Database (TED) and sharpd to call cspf algorithms on this IS-IS-TE topology.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
New Constaint Shortest Path First algorithm has been introduce in FRR library.
Add a new 'show sharp cspf' command as example of how to use these
CSPF algorithm.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This removes a giant `switch { }` block from lib/zclient.c and
harmonizes all zclient callback function types to be the same (some had
a subset of the args, some had a void return, now they all have
ZAPI_CALLBACK_ARGS and int return.)
Apart from getting rid of the giant switch, this is a minor security
benefit since the function pointers are now in a `const` array, so they
can't be overwritten by e.g. heap overflows for code execution anymore.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These are no longer really needed. The client just needs
to call nexthop resolution instead.
So let's remove the zapi types.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
https://github.com/FRRouting/frr/pull/5865#discussion_r597670225
As this comment says. ZEBRA_FLAG_XXX should not have been used.
To communicate SRv6 Route Information. A simple Nexthop Flag would
have been sufficient for SRv6 information. And I fixed the whole
thing that way.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
The "show sharp segment-routing srv6" command was a
json output command, but it did not follow the common
practice of the other commands.
It follows the review and outputs the json format by
using the json keyword. Otherwise, it produces human
readable output.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
We can install seg6 routes from shapd cli.
This is for the behaviour test(topotest) to ensure
SRv6 ZAPI is working fine.
NEW-CLI:
sharp install routes 1::1 nexthop-seg6 2001::1 encap a::
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
In this patch, we can install seg6local routes from shapd cli. New sub
command "sharp install route $PREFIX nexthop-seg6local" is added to
install seg6local routes via ZEBRA_ROUTE_ADD. This is for the behaviour
test(topotest) to ensure SRv6 ZAPI is working fine.
NEW-CLI:
sharp install routes 1::1 nexthop-seg6local dum0 End 1
sharp install routes 2::1 nexthop-seg6local dum0 End_X 2001::1 1
sharp install routes 3::1 nexthop-seg6local dum0 End_T 10 1
sharp install routes 4::1 nexthop-seg6local dum0 End_DX4 10.0.0.1 1
SRv6 routes are installed as NEXTHOP_IFINDEX routes because of seg6local
specification. seg6local routes depends the output device status instead
of routing-nexthop.
FYI:
In seg6local implementation, kernel don't care RTA_OIF on the nexthop
deeply but some requirement are exist as follow.
(a) DEV isn't loopback interface
(b) DEV's ipv6 status is enabled
(c) DEV's enslaving status is the same with target-route
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
current route addition mechanism on shaprd support only ipv4/v6 nexthop
routes simply. so It doesn't need to ensure flags of zapi_routes.
Then when we want to configure more complicated routing feature (like a
srv6), we will want to control flags of zapi_route. In this patch, it
will supports to configure flags of zapi_route when sharpd calls
ZEBRA_ROUTE_ADD.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
The remove lsp command was using the wrong list of route
protocols - use the ZEBRA list, same as the other clis.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Most of these are many, many years out of date. All of them vary
randomly in quality. They show up by default in packages where they
aren't really useful now that we use integrated config. Remove them.
The useful ones have been moved to the docs.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Add new feature and commands to sharpd in order to collect Traffic Engineering
Database information from an IGP (OSPF or IS-IS) though the ZAPI Opaque
Message and the support of the Link State Library.
This feature serves as an example of how to code a Traffic Engineering
Database consumer and tests the mechanism.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
Ensure that there are valid (resolved) nexthops, and no
invalid backup nexthops, in nhgs sent to zebra for
installation.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The `enum zclient_send_status` enum needs to be extended
throughout the code base to use the new states and
to fix up places where we tested against the return
value being non zero.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a `enum zclient_send_status` for appropriate handling
of return codes from zclient_send_message. Touch all the places
where we handle this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Have sharpd notice that when sending routes to zebra that the
underlying system has buffered data and to pause sending
more data to zebra until such time we get a callback that
the write was successful to zebra.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
These functions are never called outside of sharp_zebra.c, re-arrange
a little to make the inclusions in sharp_zebra.h not needed and
to also have these functions return whether or not the underlying
buffering system was invoked in stream sending.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue:
The bgp routes learnt from peers which are not installed in kernel are
advertised to peers. This can cause routers to send traffic to these
destinations only to get dropped. The fix is to provide a configurable
option "bgp suppress-fib-pending". When the option is enabled, bgp will
advertise routes only if it these are successfully installed in kernel.
Fix (Part1) :
* Added message ZEBRA_ROUTE_NOTIFY_REQUEST used by client to request
FIB install status for routes
* Added AFI/SAFI to ZAPI messages
* Modified the functions zapi_route_notify_decode(), zsend_route_notify_owner()
and route_notify_internal() to include AFI, SAFI as parameters
Signed-off-by: kssoman <somanks@gmail.com>
If you have two nexthop groups named
one
oneone
then the sharp daemon will treat them as the same nexthop
group. This is because we are doign this:
static int sharp_nhg_compare_func(const struct sharp_nhg *a,
const struct sharp_nhg *b)
{
return strncmp(a->name, b->name, strlen(a->name));
}
The strlen should be the size of the array of name.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This should never happen; no need to debug guard it and it's not a
warning, if this isn't working then NHT is not working at all.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Add the zapi code for encoding/decoding of backup nexthops for when
we are ready for it, but disable it for now so that we revert
to the old way with them.
When zebra gets a proto-NHG with a backup in it, we early fail and
tell the upper level proto. In this case sharpd. Sharpd then reverts
to the old way of installation with the route.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Align the zapi NHG apis to be more consistent with the zapi_route
apis. Add a struct zapi_nhg to use for encodings as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a check for installing nexthop_group greater than multipath
number. Truncate if we hit it and log a warning to the user.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Implement handling of NHG notifications in sharpd so that
the routes don't attempt to use an NHG ID that did not
successfully get created. If it does not get installed, we
fall back to traditional zapi messaging.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a command `set installable` that allows configured nexthop
groups to be treated as separate/installable objects in the RIB.
A callback needs to be implemented per daemon to handle installing
the NHG into the rib via zapi when this command is set. This
patch includes the implementation for sharpd.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were incrementing in the output the ID value when we
shouldnt be. The value the NHG is assigned is before its
incremented.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Modify the sharpd program to have the ability to pass down
a NHG and then operate on it for route installation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
Fix a number of library and daemon issues so that daemons can
call frr_fini() during normal termination. Without this,
temporary logging files are left behind in /var/tmp/frr/.
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>
Start modifying the OPAQUE zapi message to include optional
unicast destination zapi client info. Add a 'decode' api and
opaque msg struct to encapsulate that optional info.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Don't crash when trying to `show running-config` because of missing
filter northbound integration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
These are easy to get subtly wrong, and doing so can cause
nondeterministic failures when racing in parallel builds.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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 is a full rewrite of the "back end" logging code. It now uses a
lock-free list to iterate over logging targets, and the targets
themselves are as lock-free as possible. (syslog() may have a hidden
internal mutex in the C library; the file/fd targets use a single
write() call which should ensure atomicity kernel-side.)
Note that some functionality is lost in this patch:
- Solaris printstack() backtraces are ditched (unlikely to come back)
- the `log-filter` machinery is gone (re-added in followup commit)
- `terminal monitor` is temporarily stubbed out. The old code had a
race condition with VTYs going away. It'll likely come back rewritten
and with vtysh support.
- The `zebra_ext_log` hook is gone. Instead, it's now much easier to
add a "proper" logging target.
v2: TLS buffer to get some actual performance
Signed-off-by: David Lamparter <equinox@diac24.net>
Some logging systems are, er, "allergic" to tabs in log messages.
(RFC5424: "The syslog application SHOULD avoid octet values below 32")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
The vrrpd one conflicts with the standalone vrrpd package; also we're
installing daemons to /usr/lib/frr on some systems so they're not on
PATH.
Signed-off-by: David Lamparter <equinox@diac24.net>
