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.
Donald Sharp [Sun, 27 Feb 2022 19:18:09 +0000 (14:18 -0500)]
doc: Update documentation to indicate *BSD struggles
*BSD has some special struggles associated with the graceful
restart code in zebra. Add a bit of documentation to outline
this problem and how it is solved.
Donald Sharp [Sun, 27 Feb 2022 19:11:13 +0000 (14:11 -0500)]
zebra: Get zebra graceful restart working when restarting on *BSD
Upon restart zebra reads in the kernel state. Under linux
there is a mechanism to read the route and convert the protocol
to the correct internal FRR protocol to allow the zebra graceful
restart efforts to work properly.
Under *BSD I do not see a mechanism to convey the original FRR
protocol into the kernel and thus back out of it. Thus when
zebra crashes ( or restarts ) the routes read back in are kernel
routes and are effectively lost to the system and FRR cannot
remove them properly. Why? Because FRR see's kernel routes
as routes that it should not own and in general the admin
distance for those routes will be a better one than the
admin distance from a routing protocol. This is even
worse because when the graceful restart timer pops and rib_sweep
is run, FRR becomes out of sync with the state of the kernel forwarding
on *BSD.
On restart, notice that the route is a self route that there
is no way to know it's originating protocol. In this case
let's set the protocol to ZEBRA_ROUTE_STATIC and set the admin
distance to 255.
This way when an upper level protocol reinstalls it's route
the general zebra graceful restart code still works. The
high admin distance allows the code to just work in a way
that is graceful( HA! )
The drawback here is that the route shows up as a static
route for the time the system is doing it's work. FRR
could introduce *another* route type but this seems like
a bad idea and the STATIC route type is loosely analagous
to the type of route it has become.
Donald Sharp [Sun, 27 Feb 2022 19:00:41 +0000 (14:00 -0500)]
zebra: Prevent crash if ZEBRA_ROUTE_ALL is used for a route type
FRR will crash when the re->type is a ZEBRA_ROUTE_ALL and it
is inserted into the meta-queue. Let's just put some basic
code in place to prevent a crash from happening. No routing
protocol should be using ZEBRA_ROUTE_ALL as a value but
bugs do happen. Let's just accept the weird route type
gracefully and move on.
Has broken `make check` with recently new compilers:
/usr/bin/ld: staticd/libstatic.a(static_nb_config.o): warning: relocation against `zebra_ecmp_count' in read-only section `.text'
CCLD tests/bgpd/test_peer_attr
CCLD tests/bgpd/test_packet
/usr/bin/ld: staticd/libstatic.a(static_zebra.o): in function `static_zebra_capabilities':
/home/sharpd/frr5/staticd/static_zebra.c:208: undefined reference to `zebra_ecmp_count'
/usr/bin/ld: staticd/libstatic.a(static_zebra.o): in function `static_zebra_route_add':
/home/sharpd/frr5/staticd/static_zebra.c:418: undefined reference to `zebra_ecmp_count'
/usr/bin/ld: staticd/libstatic.a(static_nb_config.o): in function `static_nexthop_create':
/home/sharpd/frr5/staticd/static_nb_config.c:174: undefined reference to `zebra_ecmp_count'
/usr/bin/ld: /home/sharpd/frr5/staticd/static_nb_config.c:175: undefined reference to `zebra_ecmp_count'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make: *** [Makefile:8679: tests/lib/test_grpc] Error 1
make: *** Waiting for unfinished jobs....
Essentially the newly introduced variable zebra_ecmp_count is not available in the
libstatic.a compiled and make check has code that compiles against it.
The fix is to just move the variable to the library.
David Lamparter [Tue, 3 Dec 2019 23:17:50 +0000 (00:17 +0100)]
lib: allow returning a file descriptor over vtysh
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>
Donald Sharp [Wed, 23 Feb 2022 15:32:23 +0000 (10:32 -0500)]
zebra: Limit speed lookup to at most 4 minutes
There exists some interface types that are slow on startup
to fully register their link speed. Especially those that
are working with an asic backend. The speed_update timer
associated with each interface would keep trying if the
system returned a MAX_UINT32 as the speed. This speed
means both unknown or there is none under linux.
Since some interface types are slow on startup let's modify
FRR to try for at most 4 minutes and give up trying on those
interfaces where we never get any useful data.
Why 4 minutes? I wanted to balance the time associated with
slow interfaces coming up with those that will never give us
a value. So I choose 4 minutes as a good ballpark of time
to keep trying
Why not track all those interfaces and just not attempt to
do the speed lookup? I would prefer to not keep track of these
as that I do not know all the interface types, nor do I wish
to keep programming as new ones come in.
Zebra sends a nexthop-update message on registeration, which will cause
existing routes to be reconfigured even no changes actually happened.
Don't register the nexthop again if it's already done.
Sai Gomathi N [Tue, 18 Jan 2022 14:36:17 +0000 (06:36 -0800)]
pim6d: Adding the base changes
Adding the file pim6_cmd.h and pim6d_cmd.c as the base changes
for implementing the CLI changes
Removed the pim_cmd_init from the stub file.
Co-authored-by: Sarita Patra <saritap@vmware.com> Co-authored-by: Abhishek N R <abnr@vmware.com> Co-authored-by: Sai Gomathi N <nsaigomathi@vmware.com> Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
topotests: add support for frr.conf as a unified config
This PR adds support for configuring topotest routers using a single file.
instead of:
```
router.load_config(
TopoRouter.RD_ZEBRA, os.path.join(CWD, "{}/zebra.conf".format(rname))
)
router.load_config(
TopoRouter.RD_OSPF, os.path.join(CWD, "{}/ospfd.conf".format(rname))
)
router.load_config(
TopoRouter.RD_BGP, os.path.join(CWD, "{}/bgpd.conf".format(rname))
)
```
you can now do:
```
router.load_frr_config(
os.path.join(CWD, "{}/frr.conf".format(rname)),
[TopoRouter.RD_ZEBRA, TopoRouter.RD_OSPF, TopoRouter.RD_BGP]
)
```
or just:
```
router.load_frr_config(os.path.join(CWD, "{}/frr.conf".format(rname)))
```
In this latter case, the daemons list will be inferred from frr.conf file.
Donald Sharp [Sat, 26 Feb 2022 20:40:15 +0000 (15:40 -0500)]
zebra: Allow *BSD to specify a receive buffer size
End operator is reporting that they are receiving buffer overruns
when attempting to read from the kernel receive socket. It is
possible to adjust this size to more modern levels especially
for when the system is under load. Modify the code base
so that *BSD operators can use the zebra `-s XXX` option
to specify a read buffer.
Additionally setup the default receive buffer size on *BSD
to be 128k instead of the 8k so that FRR does not run into
this issue again.
Fixes: #10666 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Ryoga Saito [Fri, 25 Feb 2022 13:42:32 +0000 (13:42 +0000)]
bgpd: announce locators instead of transposed SIDs
This patch changes the format of the Prefix-SID advertised by
bgpd. In current implementation, transposed SIDs were
advertised, which caused two problems:
1. bgpd that receives SRv6 L3VPN routes whose SID is
transposed couldn't put bgp_attr_srv6_l3vpn whose those
routes together. This leads extra memory consumption.
2. Some implementation will reject a route with transposed SID.
This will affect interoperability.
For those reasons, in this patch, instead of advertising
transposed SID, we change it to advertise the locator of SID.
Mark Stapp [Thu, 28 Oct 2021 15:23:31 +0000 (11:23 -0400)]
zebra: use dataplane to read interface NETCONF info
Use the dataplane to query and read interface NETCONF data;
add netconf-oriented data to the dplane context object, and
add accessors for it. Add handler for incoming update
processing.
Mark Stapp [Mon, 18 Oct 2021 15:55:24 +0000 (11:55 -0400)]
zebra: add xxxNETCONF messages to the netlink BPF filter
Allow self-produced xxxNETCONF netlink messages through the BPF
filter we use. Just like address-configuration actions, we'll
process NETCONF changes in one path, whether the changes were
generated by zebra or by something else in the host OS.
Donald Sharp [Tue, 4 May 2021 12:50:00 +0000 (08:50 -0400)]
zebra: Start of work to get data about mpls from kernel
a) We'll need to pass the info up via some dataplane control method
(This way bsd and linux can both be zebra agnostic of each other)
b) We'll need to modify `struct interface *` to track this data
and when it changes to notify upper level protocols about it.
c) Work is needed to dump the entire mpls state at the start
so we can gather interface state. This should be done
after interface data gathering from the kernel.
Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Mark Stapp <mstapp@nvidia.com>
Donald Sharp [Fri, 25 Feb 2022 13:19:07 +0000 (08:19 -0500)]
lib: Add a Dev catch for when a timer is set for > 1 year
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.
projects / matthieu / frr.git / log