- split NewRpcState object into 2, a Unary and a Streaming variant, which
then allows for the next.
- move all state machine details inside these new state objects
- use a template arg to allow for Streaming state tracking object
creation and deletion w/o requiring this in each specific RPC
hander.
- Code is more rugged by design now.
Thanks to Rafael Zalamena <rzalamena@opensourcerouting.org> for the cleanup
ideas/motivation.
Signed-off-by: Christian Hopps <chopps@labn.net>
Let's clean up the valgrind output even more by calling the protobuf
shutdown function that deallocates all library used memory.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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 b8210849b8 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>
sockopt_cork is a no-op function that was cleaned up
in 2017. Since then it's still not being used. At
this point in time there is little point in keeping a
dead function that will not be used because of vagaries
between platforms
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
RB-tree and double-linked-list easily support backwards iteration, and
an use case seems to have popped up. Let's make it accessible.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The prefix_master->str data structure was a sorted
list of the prefix names. Not that big of a deal
other than insertion and deletion is insanely expensive
when you have a large number of unique prefix-lists.
In my test config file that I discovered this,
I have 587 unique prefix lists spread out acros
~26k lines of prefix-lists. When reading
this config file into FRR the read time goes
from 690 seconds to 650 seconds.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`json_object_object_add()` adds keys/items to objects/dictionaries.
Useful to have a printfrr based variant for the key there.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The vtysh live logs don't try to buffer messages when vtysh isn't
reading them fast enough. Either the kernel has space and can accept
messages without delay, or it doesn't and we continue on.
While this is intentional (otherwise slow vtysh could block a routing
daemon), at least give the user an indication if messages were dropped.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This provides direct raw log output with full metadata directly at
startup regardless of configuration details.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This was the intent here to begin with, not sure where I managed to
forget this along the way...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The timestamps used for the live log are wallclock, not monotonic. Also
some fields were left uninitialized.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
While running singlethreaded, the RCU code is "dormant" and rcu_free is
an immediate operation. This results in the log target loop accessing
free'd memory if a log target removes itself while a message is printed
(which is likely to happen on e.g. error conditions.)
Just use frr_each_safe to avoid this issue.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
- rather than coerce `const char *` to std:string&, just pass the
C ptr, as that's what is used anyway.
fixes#10578
Signed-off-by: Christian Hopps <chopps@labn.net>
Don't let open sockets hang for too long. This will fix an issue where a
improperly coded client (e.g. socat) could exaust the amount of open
file descriptors.
Documentation:
https://grpc.github.io/grpc/cpp/md_doc_keepalive.html
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This issue is applicable to other protocols as well.
When user has used route-map, even though the prefixes are falling
under the permit rule, the prefixes were denied and were shown
as inactive route in zebra.
Reason being the parameter which is of type enum was passed to the api
route_map_get_index and was typecasted to uint8_t *.
This problem is visible in case of Big Endian systems because we are
accessing the most significant byte.
'match_ret' field is an enum in the caller and so it is of 4 bytes,
the typecasting it to 1 byte and passing it to the api made
the api to put the value in the most significant byte
which was already zero previously. Therefore the actual value
RMAP_NOMATCH which was 1 never gets reset in this case.
Therefore the api always returns 'RMAP_NOMATCH' and hence
the prefixes are always denied.
Fixes: #9782
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Call `zlog_file_rotate` for command file lines as well otherwise on
`SIGUSR1` the old descriptor will still be used and no new log file will
be created for the rotation.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
If a operator issues a series of route-map deletions and
then re-adds, *and* this triggers the hash table to realloc
to grow to a larger size, then subsuquent route-map operations
will be against a corrupted hash table.
Why?
Effectively the route-map code was inserting each
route-map <NAME> into a hash for storage. Upon
deletion there is this concept of delayed processing
so the routemap code sets a bit `to-be-processed`
and marks the route-map for deletion. This is
1 entry in the hash table. Then if the operator
recreates the hash, FRR would add another hash
entry. If another deletion happens then there
now are 2 deletion entries that are indistinguishable
from a hash perspective.
FRR stores the deleted name of the route-map so that
any delayed processing can lookup the name and only process
those peers that are related to that route-map name.
This is good as that if in say BGP, we do not want
to reprocess all the peers that don't use the route-map.
Solution:
The whole purpose of the delay of deletion and the
storage of the route-map is to allow the using protocol
the ability to process the route-map at a later time
while still retaining the route-map name( for more efficient
reprocessing ). The problem exists because we are keeping
multiple copies of deletion events that are indistinguishable
from each other causing hash havoc.
The truth is that we only need to keep 1 copy of the
routemap in the table. If the series of events is:
a) delete ( schedule processing )
b) add ( reschedule processing )
Current code ends up processing the route-map two times
and in this event we really just need to reprocess everything
with the new route-map.
If the series of events is:
a) delete (schedule processing )
b) add (reschedule)
c) delete (reschedule)
d) add (reschedule)
All this really points to is that FRR just needs to keep the last
in the series of maps and ensuring that FRR knows that we need
to continue processing the route-map. So in the creation processing
if the hash has an entry for this map, the routemap code knows that
this is a deletion event. Mark this route-map for later processing
if it was marked so. Also in the lookup function do not return
a map if the map found was deleted.
Fixes: #10708
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
State-only and configuration presence-containers need to be treated
differently when iterating over YANG operational data. Currently the
get_elem() callback is used to know when a state-only p-container
exists or not, and configuration p-containers are assumed to always
exist, which is clearly wrong. Fix this by checking the running
configuration to know whether a rw p-container exists or not.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
On FreeBSD I have noticed that subsuquent calls to clock_gettime(..)
can return an after time that is before first calls value.
This in turn is generating CPU_HOG's because the subtraction
is wrapping into very very large numbers:
2022/02/28 20:12:58 SHARP: [PTDQA-70FG5] start: 35.741981000 now: 35.740581000
2022/02/28 20:12:58 SHARP: [XK9YH-ZD8FA][EC 100663313] CPU HOG: task zclient_read (800744240) ran for 0ms (cpu time 18446744073709550ms)
(Please note I added the first line of debug to figure this issue out).
I have been asked to open a FreeBSD bug report and have done so.
In the mean time I think that it is important that FRR does
not generate bogus CPU HOG's on FreeBSD ( especially since
this may or may not be easily fixed and FRR has no control
over what version of the operating system, operators are
going to be running with FRR.
So, add a bit of specialized code that checks to see if
the after time in FreeBSD is before the now time in
thread_consumed_time and do some quick manipulations
to not have this issue.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This adds the plumbing necessary to yield back a file descriptor to
vtysh. The fd is passed on the command status code bytes through
AF_UNIX SCM_RIGHTS.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Add the ability to inspect the timers and when they will pop
per daemon:
sharpd@eva ~/frr (thread_return_null)> vtysh -c "show thread timers"
Thread timers for zebra:
Showing timers for default
--------------------------
rtadv_timer 00:00:00.520
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.745
if_zebra_speed_update 00:00:02.746
if_zebra_speed_update 00:00:02.744
if_zebra_speed_update 00:00:02.745
Showing timers for Zebra dplane thread
--------------------------------------
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Since there are timers that are created based upon doing some
math and we know that unsigned values when doing math and we accidently
subtract a larger number from a smaller number causes the unsigned
number to wrap to very large numbers, let's put in a small catch
in place to see if there are any places in the system that
mistakes are made and FRR is accidently creating a problem
for itself.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
assert when if_lookup_address is passed with
a family that is not AF_INET or AF_INET6 as
that we are dead in the water and this is a
dev escape
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a counter to the number of times a thread is starved from
a timer event and add the output to `show thread cpu`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
==================
Currently there is no support for configuring hash algorithm in
keychain.
RCA:
====
Not implemented yet.
Fix:
====
Changes are done to configure hash algorithm as part of keychain.
which will easy the configuration from modules using keychain.
Risk:
=====
Low risk
Tests Executed:
===============
Have tested the configuration and unconfiguration flow for newly
implemented CLI.
!
key chain abcd
key 100
key-string password
cryptographic-algorithm sha1
exit
key 200
key-string password
cryptographic-algorithm sha256
exit
!
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
=================
When modules use keychain there is no option for auto completion
of configured keychains.
RCA:
====
Not implemented.
Fix:
====
Changes to support auto completion of configured keychain names.
Risk:
=====
Low risk
Tests Executed:
===============
Have tested auto completion of configured keychain names with newly
implemented auth CLI.
frr(config-if)# ipv6 ospf6 authentication keychain
KEYCHAIN_NAME Keychain name
abcd pqr 12345
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Multiple deletions from the hash_walk or hash_iteration calls
during a single invocation of the passed in function can and
will cause the program to crash. Warn against doing such a
thing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add to lib/command.c the ability to remember the
release/version/system information and to allow
`show version` to dump some of it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
When link-param is enabled for a given interface, TE metric is automatically
assigned to the metric of the interface. However, the metric of the interface
could be unassigned and keep the default value equal to 0. Thus, if the TE
metric is not explicitely modified within the `link-param metric` statement,
TE metric remains set to 0 which is not a valid value especially when
computing constrainted path.
This patch changes the assignement of the default value of the TE metric.
It is set to the metric of the interface only if the latter is not equal to 0.
TE topotests for OSPF and IS-IS have been adjusted accordingly.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Replace custom implementation or call to ipaddr_isset with a call to
ipaddr_is_zero.
ipaddr_isset is not fully correct, because it's fine to have some
non-zero bytes at the end of the struct in case of IPv4 and the function
doesn't allow that.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add a thread_ignore_late_timer(struct thread *thread) function
that allows thread.c to ignore when timers are late to the party.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If a thread timer should have popped CPU_CONSUMED_CHECK
seconds in the past, and we are only handling it now. Consider
the thread starved and notice it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
BGP EVPN custom `union gw_addr` is basically the same thing as a common
`struct ipaddr` but it lacks the address family which is needed in some
cases.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
elf_getdata_rawchunk() already endian-converts; doing it again is, uh,
counterproductive.
Fixes: #10051
Reported-by: Lucian Cristian <lucian.cristian@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This causes confusing/annoying log messages at startup otherwise:
`YANG model "ietf-inet-types@*" "*@*"not embedded, trying external file`
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
systemd sets up environment variables to allow autodetecting and
switching the log format to journald native. Make use of that for the
stdout logging target.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
Update ospfd and ospf6d to send opaque route attributes to
zebra. Those attributes are stored in the RIB and can be viewed
using the "show ip[v6] route" commands (other than that, they are
completely ignored by zebra).
Example:
```
debian# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "ospf", distance 110, metric 20, best
Last update 01:57:08 ago
* 10.0.1.2, via eth-rt2, weight 1
OSPF path type : External-2
OSPF tag : 0
debian#
debian# show ip route 192.168.1.0/24 json
{
"192.168.1.0\/24":[
{
"prefix":"192.168.1.0\/24",
"prefixLen":24,
"protocol":"ospf",
"vrfId":0,
"vrfName":"default",
"selected":true,
[snip]
"ospfPathType":"External-2",
"ospfTag":"0"
}
]
}
```
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Adding an `s` after these printfrr specifiers replaces 0.0.0.0 / :: in
the output with a star (`*`). This is primarily intended for use with
multicast, e.g. to print `(*,G)`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Used for graceful-restart mostly.
Especially for bgp_show_neighbor_graceful_restart_capability_per_afi_safi()
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Since this is only used in very few places, moving it out of the way is
reasonable. (`%pSG` will be pim_sgaddr)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently `bfd_get_peer_info` should return invalid sp->family
and dp->family during fail cases.
Before this fix, in those fail cases `bfd_get_peer_info` maybe
return valid sp->family and dp->family.
This fix ensures all fail cases return invalid sp->family and
dp->family for outside callers.
Signed-off-by: anlan_cs <anlan_cs@tom.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>
If we're exiting before we finished initializing, we can end up trying
to shut down a NULL vrf here.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
New `FRR_NO_SPLIT_CONFIG` flag for newly added daemons where we're just
rolling without split config and always expect configs to be loaded via
vtysh/integrated config.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In order to add Link State Traffic Engineering to IS-IS, Link State library
should have been updated:
- Correct Node and Edge RB Tree comparison functions to support key > 32 bits
- Change Subnet RB Tree comparison function to take into account host part of
the prefix i.e. 10.0.0.1/24 and 10.0.0.2/24 are considered as different
- Add new function to convert IS-IS ISO system ID into Vertex or Edge key that
take into account Endianness architecture
- Correct Vertex and Edge creation and search function accordingly
- Add extra Adjacency entries in Link State Attributes for IPv6 Segment Routing
- Update send/received and show TED functions accordingly
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Duplicate a couple of definitions in order to remove the bgpd
includes from this libfrr header. This is necessary to fix some
name collisions like PREFIX_LIST_IN being defined differently on
multiple daemons (as soon as other daemons start including
route_opaque.h).
Including daemon headers on libfrr headers is a bad practice and
should be avoided whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is needed for the following two reasons:
1. To be able to remove the northbound HACK in if_update_to_new_vrf. It
is totally wrong to rewrite the configuration datastore when some
operational state changes. It is a hard blocker for storing a
configuration data in a management daemon which knows nothing about
the operational state.
2. To allow changing the VRF of the interface using FRR CLI or any other
frontend in the future. If the VRF is a part of the key, it can't be
changed. If the VRF is a simple leaf, it becomes possible to change
it and thus move the interface between VRFs. For now I mark the leaf
as a "config false" as it's not yet possible to control it from FRR.
But we can't simply remove the VRF from the key, because it is needed to
distinguish interfaces when using netns based VRFs, as it is possible to
have multiple interfaces with the same name in different namespaces. To
handle this, I came up with an idea to store both VRF and an interface
name in the "name" leaf using the pattern "vrfname:ifname". For example,
if there's an interface "eth0" in VRF "red" then its "name" leaf will be
"red:eth0".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
add a parameter to resolver api that is the vrf identifier. this permits
to make resolution self to each vrf. in case vrf netns backend is used,
this is very practical, since resolution can happen on one netns, while
it is not the case in an other one.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
For IPv4 matching, we have "match ip next-hop address A.B.C.D".
For IPv6 matching, we have "match ipv6 next-hop X:X::X:X".
To have consistency, let's add "address" keyword to IPv6 commands.
Old commands are preserved as hidden for backward compatibility.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
(This is mostly just to exercise the code, the actual replacement needs
to be a cocci script.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... these should probably have been added ages ago.
`json_object_string_addf(json, "key", "%pFX", prefix)` is super useful.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... this is copypasted all over the codebase & should've been a helper
to begin with really.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Most users of if_lookup_address_exact only cared about whether the
address is any local address. Split that off into a separate function.
For the users that actually need the ifp - which I'm about to add a few
of - change it to prefer returning interfaces that are UP.
(Function name changed due to slight change in behavior re. UP state, to
avoid possible bugs from this change.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
i.e. to whoever cares, since some unique IDs (from libfrr) are valid
everywhere but some others (from the daemons) only apply to specific
daemons.
(Default handling aborts on first error, so configuring any unique IDs
that don't exist on the first daemon vtysh connects to just failed
before this.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Why would this be in a vector to loop over with strcmp()'ing each
item... that just makes no sense. Use a hash instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We should always treat the VRF interface as a loopback. Currently, this
is not the case, because in some old pre-VRF code we use if_is_loopback
instead of if_is_loopback_or_vrf. To avoid any future problems, the
proposal is to rename if_is_loopback_or_vrf to if_is_loopback and use it
everywhere. if_is_loopback is renamed to if_is_loopback_exact in case
it's ever needed, but currently it's not used anywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
