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.
Removed extra line changes.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Document the commands `addpath-tx-all-paths`,
`addpath-tx-bestpath-per-AS` and attempt to provide an useful
explanation.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Current behavior:
eva# show mem
2020/08/04 18:07:38 ZEBRA: Not Notifying Owner: 2 about prefix 3.3.3.3/32(254) 2 vrf: 0
Fix it to show:
2020/08/04 18:07:38 ZEBRA: Not Notifying Owner: connected about prefix 3.3.3.3/32(254) 2 vrf: 0
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
When you make a change to a route-map or a prefix-list it depends on, note
that the route-map needs to be reprocessed for the change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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.
Signed-off-by: Kaushik <kaushik@niralnetworks.com>
`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>
Create a new category for access lists commands so we can avoid sending
configurations (which might be big) to daemons which do not use it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When we have a prefix that has been selected, note that that
particular flag has been set and give that information to the
end user.
eva# show bgp ipv4 uni neighbors 192.168.161.131 prefix-counts
Prefix counts for 192.168.161.131, IPv4 Unicast
PfxCt: 814246
Counts from RIB table walk:
Adj-in: 0
Damped: 0
Removed: 0
History: 0
Stale: 0
Valid: 814246
All RIB: 814246
PfxCt counted: 814246
PfxCt Best Selected: 0
Useable: 814246
eva# show bgp ipv4 uni neighbors 192.168.161.2 prefix-counts
Prefix counts for 192.168.161.2, IPv4 Unicast
PfxCt: 814070
Counts from RIB table walk:
Adj-in: 0
Damped: 0
Removed: 0
History: 0
Stale: 0
Valid: 814070
All RIB: 814070
PfxCt counted: 814070
PfxCt Best Selected: 814070
Useable: 814070
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
