| Age | Commit message (Collapse) | Author |
|---|
|
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 routes
(seg6 and seg6local routes) are handled: when the user executes the CLI
command `sharp install seg6-routes` or `sharp install seg6local-routes`
to create a seg6 or seg6local route, sharpd calls
`nexthop_add_srv6_seg6` or `nexthop_add_srv6_seg6local` to create an
SRv6 nexthop. A pointer to the SRv6 nexthop is stored in the global data
structure `sg.r.nhop`. If you call `sharp install routes`,
`sharp install seg6-routes` or `sharp install seg6local-routes` to create
more routes, `sg.r.nhop` is set to zero and the
pointer to the SRv6 nexthop contained in `sg.r.nhop` is definitely lost
and the allocated memory is never freed.
This patch adds calls to `nexthop_del_srv6_seg6()` and
`nexthop_del_srv6_seg6local()` to free the memory allocated for the SRv6
nexthop before clearing the `sg.r.nhop` data structure.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
|
|
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, the `list_delete()` function is called to delete the
chunks list (`loc->chunks`), but the memory allocated for the chunks is
not freed.
This patch defines a new callback `sharp_srv6_locator_chunk_free()`.
This callback takes care of freeing the memory allocated for a given
chunk. When `list_delete()` is called to remove the chunk list
`loc->chunks`, it automatically calls `sharp_srv6_locator_chunk_free()`
on each element of the list to free the allocated memory before
deleting the list.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
|
|
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, all the chunks are removed from the list `loc->chunks`.
Also, the locator is removed from the SRv6 locators list
`sg.srv6_locators`, but the memory allocated for the locator is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when all the chunks of an SRv6 locator are removed and the
locator is removed as well.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
|
|
Some recent improvement in GCC triggers 2 new warnings, and they're
actual bugs (reading beyond end of prefix_ipv6 by accessing it as
prefix, which is larger.) Luckily it's only in sharpd.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Just pushing that SAFI_UNICAST up 1 level to the caller.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Add Support for Setting Protodown Reason Code
|
|
Currently the nexthop tracking code is only sending to the requestor
what it was requested to match against. When the nexthop tracking
code was simplified to not need an import check and a nexthop check
in b8210849b8ac1abe2d5d9a5ab2459abfde65efa5 for bgpd. It was not
noticed that a longer prefix could match but it would be seen
as a match because FRR was not sending up both the resolved
route prefix and the route FRR was asked to match against.
This code change causes the nexthop tracking code to pass
back up the matched requested route (so that the calling
protocol can figure out which one it is being told about )
as well as the actual prefix that was matched to.
Fixes: #10766
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Add support for setting protodown via sharpd. This is just useful
for testing. We can make use of this in topotests.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
|
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
The int return value is never used. Modify the code
base to just return a void instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
add support for SRv6 IPv4 L3VPN
|
|
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>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
This patch enables sharpd to insert End.DT4 routes into zebra.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
|
|
Naming functions/data structures more appropriately for
the project we are actually in.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
|
|
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.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>
|
|
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
|
|
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>
|
|
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
|
|
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
|
|
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>
|
|
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>
|
|
Add the ability for sharpd to watch v4 redistribution events
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
|
|
*: require ISO C11 + semicolons after file-scope macros
|
|
... again ...
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
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>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
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>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Pass data from sharpd to zebra as opaque data and display
it as part of the detailed route data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
