lynne [Wed, 5 Aug 2020 19:22:08 +0000 (15:22 -0400)]
ldpd: ldp-oc withdraw fix
When LDP is configured in Order Control mode and we receive a
label withdraw message, we should only resend label withdraws to
peers that are the NH for that fec being withdrawn.
pimd crash at pim_msg_build_jp_groups (
grp=grp@entry=0x7ffca55b5d1e, sgs=sgs@entry=0x17821a0, size=20)
at pimd/pim_msg.c:198
Fix for https://github.com/FRRouting/frr/issues/6849
Root Cause:
===========
pimd has crashed because pim_upstream_rpf_clear function sets the
up->rpf.source_nexthop.interface pointer to NULL and has not removed
the upstream source node from the neighbor. When the upstream gets
deleted the source is not removed from neighbor
neigh->upstream_jp_agg->groups->sources list. This source node has
pointer to upstream freed memory. Hence when on_neighbor_jp_timer expires,
it tries to access the upstream pointer and crashed.
Fix:
====
Before setting the interface pointer to NULL, remove the node from
neigh->upstream_jp_agg->groups->sources list. Also the upstream state
has to be changed to Not joined.
Donald Sharp [Tue, 28 Jul 2020 14:58:47 +0000 (10:58 -0400)]
vtysh: Speed up output of configuration across daemons
With a config that contains a large number of prefix-lists a 'show run' command
was an expensive operation:
sharpd@eva ~/frr_internal2 ((cl4.1.0))> time vtysh -c "show run" | grep ACTIVE | wc -l
32397
________________________________________________________
Executed in 14.53 secs fish external
usr time 14.45 secs 591.00 micros 14.45 secs
sys time 0.03 secs 189.00 micros 0.03 secs
sharpd@eva ~/frr_internal2 ((cl4.1.0))>
Effectively we are keeping a linked list of data to store the configuration.
When we received a new item we would look in the list to see if it already
does, by doing a string search across each element in the list.
Add to the master configuration a hash of items for O(1) lookup.
Keep the list for order so we don't mangle that up.
New time:
sharpd@eva ~/frr_internal1 (dev)> time vtysh -c "show run" | grep ACTIVE | wc -l
32397
________________________________________________________
Executed in 277.94 millis fish external
usr time 237.46 millis 20.53 millis 216.93 millis
sys time 14.31 millis 0.00 millis 14.31 millis
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
lib,zebra,bgpd: Fix for nexthop as IPv4 mapped IPv6 address
Added a macro to validate the v4 mapped v6 address.
Modified bgp receive & send updates for v4 mapped v6 address as
nexthop and installing it as recursive nexthop in RIB.
Minor change in fpm while sending the routes for nexthop as
v4 mapped v6 address.
Rafael Zalamena [Tue, 28 Jul 2020 12:33:08 +0000 (09:33 -0300)]
topotests: remove sharpd from route map output
`sharpd` doesn't handle any route map commands and neither should show
up in route map commands. This makes the CI pass again after not sending
route map commands to it again.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
lib: introduce configuration back-off timer for YANG-modeled commands
When using the default CLI mode, the northbound layer needs to create
a separate transaction to process each YANG-modeled command since
they are supposed to be applied immediately (there's no candidate
configuration nor the "commit" command like in the transactional
CLI). The problem is that configuration transactions have an overhead
associated to them, in big part because of the use of some heavy
libyang functions like `lyd_validate()` and `lyd_diff()`. As of
now this overhead is substantial and doesn't scale well when large
numbers of transactions need to be performed in sequence.
As an example, loading 50k prefix-lists using a single transaction
takes about 2 seconds on a modern CPU. Loading the same 50k
prefix-lists using 50k transactions can take more than an hour
to complete (which is unacceptable by any standard). To fix this
problem, some heavy optimization work needs to be done on libyang and
on the FRR northbound itself too (e.g. perform partial configuration
diffs whenever possible). This, however, should be a long term
effort since these optimizations shouldn't be trivial to implement
and we're far from having the performance numbers we need.
In the meanwhile, this commit introduces a simple but efficient
workaround to alleviate the issue. In short, a new back-off timer
was introduced in the CLI to monitor and detect when too many
YANG-modeled commands are being received at the same time. When
a certain threshold is reached (100 YANG-modeled commands within
one second), the northbound starts to group all subsequent commands
into a single large transaction, which allows them to be processed
much faster (e.g. seconds and not hours). It's essentially a
protection mechanism that creates dynamically-sized transactions
when necessary to prevent performance issues from happening. This
mechanism is enabled both when parsing configuration files and when
reading commands from a terminal.
The downside of this optimization is that, if several YANG-modeled
commands are grouped into the same transaction and at least one of
them fails, the whole transaction is rejected. This is undesirable
since users don't expect transactional behavior when that's not
enabled explicitly. To minimize this issue, the CLI will log all
commands that were rejected whenever that happens, to make the
user aware of what happened and have enough information to fix
the problem. Commands that fail due to parsing errors or CLI-level
validations in general are rejected separately.
Again, this proposed workaround is intended to be temporary. The
goal is to provided a quick fix to issues like #6658 while we work
on better long-term solutions.
DEFPY_YANG will allow the CLI to identify which commands are
YANG-modeled or not before executing them. This is going to be
useful for the upcoming configuration back-off timer work that
needs to commit pending configuration changes before executing a
command that isn't YANG-modeled.
nhrpd: ignore zebra updates about our routes being deleted/added
nhrp listens for route entries to be deleted, in case some new routes
impact the current routes installed by nhrp. To prevent from
unconfiguring nhrp shortcut route, just prevent nhrp routes to be
processed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Mark Stapp [Wed, 29 Jul 2020 20:57:37 +0000 (16:57 -0400)]
tests: Avoid top ecmp route_scale test case when memory limited
Address-sanitizer runs in the CI appear to require more
memory than is available (at present), so skip the top
x32 route_scale testcase when running with <4G of ram.
Mark Stapp [Mon, 20 Jul 2020 18:51:16 +0000 (14:51 -0400)]
tests: rework route_scale topotest
Make some changes to the route-scale topotest, in view of
issue #6734. Table-drive the test to eliminate some
repeated code. Assert and fail if a step in the progression
of scale fails. Wait a little longer between checking the show
output - it's costly to generate that output at scale. Add a
memleak testcase.
The `INET_ADDRSTRLEN` is 16 and is only enough to format an IPv4 address.
So when there is a prefix (`/xx`), the debug output may get truncated.
Use `PREFIX2STR_BUFFER` macro instead to fix the issue.
tests: Skipping evpn_type5_test_topo1 tests from CI runs
1. evpn_type5_test_topo1 tests started failing in CI for all Ubuntu 18.04 machine,
which are having kernel version: 5.4.0-42-generic
2. We will enable these tests once issue is found and fixed.
Rafael Zalamena [Fri, 17 Jul 2020 19:15:04 +0000 (16:15 -0300)]
zebra,fpm: serialize zebra table walks
We were not getting any benefits from attempting to walk all tables at the
same time and it made debugging harder, so lets execute one table walk
per time.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rafael Zalamena [Fri, 17 Jul 2020 14:37:38 +0000 (11:37 -0300)]
zebra,fpm: fix race on completion detection
Zebra runs on a different thread than FPM, so we need to synchronize
them by using events. While here, implement completion detection for all
kinds of walk.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rafael Zalamena [Fri, 17 Jul 2020 17:37:55 +0000 (14:37 -0300)]
zebra,fpm: fix input handling
Two important fixes:
* `stream_read_try` does a dirty trick and converts the `-1` return to
`-2` when errno is `EAGAIN`, `EWOULDBLOCK` or `EINTR`.
* Don't enable reads until the connection is complete.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Donald Sharp [Mon, 27 Jul 2020 15:09:16 +0000 (11:09 -0400)]
tests: Remove 'log monitor' from tests
The `log monitor' command is a no-op and actually
outputs a `this doesn't do anything` warning. Let's remove
this cli line from our tests as that don't do anything and
people will look at these configs for guidance.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 27 Jul 2020 11:10:41 +0000 (07:10 -0400)]
bgpd: Deref after null check in bgp_evpn_vty.c
Coverity has noticed that we are using bgp_evpn after
we have already NULL checked it one time. Add an assert
to make Coverity happy here, if we get to this point
something terrible has happened.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
causes clang 11 to be unhappy, with length of field warnings.
Modify the offending code to compile properly using that compiler.
I've tested against clang 11 and gcc 9.3
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Russell Bryant [Fri, 24 Jul 2020 00:26:54 +0000 (20:26 -0400)]
bgpd: Add missing newline to a log message
While checking my BGP debugging settings at the console, I noticed
this message was missing a newline. Add it to be consistent with the
other similar messages.
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Tore Anderson [Wed, 22 Jul 2020 15:32:18 +0000 (17:32 +0200)]
tools: do not silently ignore errors when loading config during startup
Drop the `-n` (`--noerror`) flag from the `vtysh -b` invocation called by the
init script responsible for starting FRR. This ensures that errors in the
configuration file is propagated to the administrator, and prevents a node from
entering a production network while running an essentially undefined
configuration (a behaviour that I can personally attest to has the potential to
cause disastrous network outages - documented in more detail in Cumulus
Networks CS#12791).
Silently ignoring errors also leads to the rather odd behaviour that starting
FRR will ostensibly succeed, while reloading it immediately after - without
changing the configuration - will fail. This is due to the fact that the `-n`
flag is not used while reloading.
The use of the `-n` flag appears to have been introduced without any
explanation in commit 858aa29c6862ed2390baee53b6fc9f54e65246e2 by @donaldsharp.
Looking at the commit message, I suspect that it was not an intentional change.
It seems more likely to me that it was just meant to be used during testing and
development, but ended up being committed to master by accident.
projects / mirror / frr.git / log