explicit_bzero() is available as an API to clean up sensitive data
and avoid compiler optimizations that remove calls to memset() or bzero().
Signed-off-by: Loganaden Velvindron <logan@cyberstorm.mu>
As helper function of Segment Routing Flex Algo or RSVP-TE
add Constrained Shortest Path First algorithm able to compute
path with constraints. Supported constraints are as follow:
- Standard IGP metric
- TE IGP metric
- Delay metric
- Bandwidth for given Class of Service for bandwidth reservation (RSVP-TE)
Usage of CSPF algorithms is detailed in the doc/developer/cspf.rst file
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Not much to say here, user docs are coming up in a separate commit.
RFC5424 and (systemd's) journald allow passing structured key-value
data. This stuffs the metadata we have available into there.
The "does the system syslogd support RFC5424" question is unfortunately
not easily answered, so we can only give an affirmative answer on NetBSD
5.0+ or FreeBSD 12+.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
like the other automake variables, setting `xyz_LDFLAGS` causes
`AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind
that automake doesn't do this for LDFLAGS, but... it does. (Which is
consistent with `_CFLAGS` and co.)
So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which
includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and
`MODULE_LDFLAGS` to handle all of this correctly (and move these bits to
a central location.)
Fixes: #9034
Fixes: 0c4285d77e ("build: properly split CFLAGS from AC_CFLAGS")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Adding a `\n' should now produce a warning. Controlled by `-Werror` so
if you're doing a dev build and it's warning about some `prefix2str`
that should be converted to `%pFX`, you can turn off `-Werror` to fix it
later like with all other warnings.
Signed-off-by: David Lamparter <equinox@diac24.net>
...really no reason to force this into a compile time decision. The
only point is avoiding the getrusage() syscall, which can easily be a
runtime decision.
[v2: also split cputime & walltime limits]
Signed-off-by: David Lamparter <equinox@diac24.net>
This includes community and large-community data.
```
exit1-debian-9# show ip route 172.16.16.1/32
Routing entry for 172.16.16.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:00:23 ago
* 192.168.0.2, via eth1, weight 1
AS-Path : 65030
Communities : 65001:1 65001:2 65001:3 65001:4 65001:5 65001:6
Large-Communities: 65001:123:1 65001:123:2
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The previous method, using zassert.h and hoping nothing includes
assert.h (which, on glibc at least, just does "#undef assert" and puts
its own definition in...) was fragile - and actually broke undetected.
Just provide our own assert.h and control overriding by putting it in a
separate directory to add to the include path (or not.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
`CFLAGS` is a "user variable", not intended to be controlled by
configure itself. Let's put all the "important" stuff in AC_CFLAGS and
only leave debug/optimization controls in CFLAGS.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The point of the `-std=gnu99` was to override a `-std=c99` that may be
coming in from net-snmp. However, we want C11, not C99.
Signed-off-by: David Lamparter <equinox@diac24.net>
Apparently you can do `#__VA_ARGS__` and it actually does something
sensible, so here we go recording the format parameters for log messages
into the xref.
This allows some more checking in xrelfo.py, e.g. hints to use `%pFX`
and co.
Signed-off-by: David Lamparter <equinox@diac24.net>
This adds _clippy.ELFFile, which provides a fast wrapper around libelf.
The API is similar to / a subset of pyelfutils, which unfortunately is
painfully slow (to the tune of minutes instead of seconds.)
The idea is that xrefs can be read out of ELF files by reading out the
"xref_array" section or "FRRouting/XREF" note.
Signed-off-by: David Lamparter <equinox@diac24.net>
This adds the machinery for cross reference points (hence "xref") for
things to be annotated with source code location or other metadata
and/or to be uniquely identified and found at runtime or by dissecting
executable files.
The extraction tool to walk down an ELF file is done and working but
needs some more cleanup and will be added in a separate commit.
Signed-off-by: David Lamparter <equinox@diac24.net>
Define new models for Link State Database a.k.a TED
and functions to manipulate the new database as well as exchange Link State
information through ZAPI Opaque message.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Previous commits added LTTng tracepoints. This was primarily for testing
/ trial purposes; in practice we'd like to support arbitrary tracing
methods, and especially USDT probes, which SystemTap and dtrace expect,
and which are supported on at least one flavor of BSD (FreeBSD).
To that end this patch adds an frr-specific tracing macro, frrtrace(),
which proxies into either DTRACE_PROBEn() or tracepoint() macros
depending on whether --enable-usdt or --enable-lttng is passed at
compile time.
At some point this could be tweaked to allow compiling in both types of
probes. Ideally there should be some logic there to use LTTng's optional
support for generating USDT probes when both are requested.
No additional libraries are required to use USDT, since these probes are
a kernel feature and only need the <sys/sdt.h> header.
- add --enable-usdt to toggle use of LTTng tracepoints or USDT probes
- add new trace.h library header for use with tracepoint definition
headers
- add frrtrace() wrapper macro; this should be used to define
tracepoints instead of using tracepoint() or DTRACE_PROBEn()
Compilation with USDT does nothing as of this commit; the existing LTTng
tracepoints need to be converted to use the frrtrace*() macros in a
subsequent commit.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
This commit adds initial support for LTTng.
When --enable-lttng=no or is not specified, no tracing code is included.
When --enable-lttng=yes, LTTng tracing events are (will be) generated.
configure.ac:
- add --enable-lttng
- define HAVE_LTTNG when enabled
- minimum LTTng version: 2.12.0
lib:
- add trace.[ch]
- update subdir.am
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
* remove pre-generation of route_types.h from configure
This change is a partial revert of commit 306ed6816. This is a little
drawback, but at least "make lib/libfrr.la", mentioned in the commit,
still works because route_types.h is forced to be built in f1b32b2e5.
* add "enabled" field to route_types.txt to track which daemon should
be enabled to add the routing protocol to "show ip route" header and
to redistribution list
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
For the sake of Segment Routing (SR) and Traffic Engineering (TE)
Policies there's a need for additional infrastructure within zebra.
The infrastructure in this PR is supposed to manage such policies
in terms of installing binding SIDs and LSPs. Also it is capable of
managing MPLS labels using the label manager, keeping track of
nexthops (for resolving labels) and notifying interested parties about
changes of a policy/LSP state. Further it enables a route map mechanism
for BGP and SR-TE colors such that learned BGP routes can be mapped
onto SR-TE Policies.
This PR does not introduce any usable features by now, it is just
infrastructure for other upcoming PRs which will introduce 'pathd',
a new SR-TE daemon.
Co-authored-by: Renato Westphal <renato@opensourcerouting.org>
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
Move pim and igmp yang files registery to appropriate makefiles.
In yang directory makefile move under `PIMD`
Remove pimd yang files from library makefile instead move them
to pimd makefile.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
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>
