Donald Sharp [Fri, 25 Oct 2019 11:05:11 +0000 (07:05 -0400)]
pimd: All paths have already derefed pim->global_scope.bsrp_table
All paths leading to this point in the code have already deref'ed
the pim->global_scope.bsrp_table. No point in testing for
validness now. This was caught by Coverity.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donatas Abraitis [Fri, 25 Oct 2019 10:01:02 +0000 (13:01 +0300)]
nhrp: Make sure `no ip nhrp map <something>` works as expected
We passed peer as NULL and nothing happened.
exit2-debian-9# conf
exit2-debian-9(config)# int gre1
exit2-debian-9(config-if)# ip nhrp map 1.1.1.1 local
exit2-debian-9(config-if)# ip nhrp map 2.2.2.2 3.3.3.3
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 1.1.1.1 local
ip nhrp map 2.2.2.2 3.3.3.3
!
...
exit2-debian-9(config-if)# no ip nhrp map 1.1.1.1
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 2.2.2.2 3.3.3.3
!
Don Slice [Wed, 23 Oct 2019 16:30:28 +0000 (16:30 +0000)]
bgpd: remove error message for unkown afi/safi combination
Problem reported with error messages appearing in the log
complaining about invalid afi/safi combinations. Determined
that the error messages were recently added in the function
that turns afi and safi values to strings. Unfortunately,
the function is called from places using FOREACH_AFI_SAFI,
which spins thru every afi and safi number including some
that are not legal together (ipv4 evpn and l2vpn multicast
for example.) This fix removes these error messages since
it is not necessarily an error to call it with invalid
combinations.
Ticket: CM-26883 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Philippe Guibert [Wed, 23 Oct 2019 14:53:09 +0000 (16:53 +0200)]
staticd: check tuple (vrf, name) when interface events received
with network namespace vrf backend, there is possibilities that the same
interface name can be used across two different vrfs. Then, enforce the
check when static daemon receives interface events. Adding to the
interface name, check for the vrf id, too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Quentin Young [Mon, 21 Oct 2019 18:21:16 +0000 (18:21 +0000)]
vrrpd: fix startup error message reporting
Due to some extremely shoddy programming on my part, the error messages
for certain errors was pretty much always wrong. We would start with the
correct error message, then on the next check, regardless of whether it
passed or failed, we would null out the error message, then on the next
one set it again (to the wrong message), then null it, and just keep
alternating. So errors were sometimes not being reported, sometimes
being reported correctly (if the condition parity happened to match the
appropriate condition), and sometimes being reported correctly.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Olivier Dugeon [Mon, 21 Oct 2019 16:39:15 +0000 (18:39 +0200)]
isisd: Correct missing advertisement of TE param.
Traffic Engineering parameters are correctly advertised in LSP when
'mpls-te on' CLI command is present in the startup config file.
However, if IS-IS is started without TE enable at startup and
'mpls-te on' command is issued after, TE link parameters are never
announced. The patch correct this issue.
Stephen Worley [Thu, 17 Oct 2019 19:44:08 +0000 (15:44 -0400)]
zebra: On if down/addr-del, process kernel routes
Since we don't have a daemon who's job is to handle kernel
routes and we don't get an explicit route delete anymore if
nexthops become unreachable from the kernel, zebra must
re-process kernel routes itself to make sure they are still valid.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 17 Oct 2019 19:41:25 +0000 (15:41 -0400)]
zebra: Check active on OLD system/kernel routes
We can assume that system/kernel routes are valid indeed
if this is our first time procesing them. But since we don't
get explicit deletion events for kernel routes anymore, we
have to be prepared to process them if the nexthop becomes
unreachable for instance. Therefore, if the route is not NEW,
then don't assume its valid.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Thu, 17 Oct 2019 19:38:54 +0000 (15:38 -0400)]
zebra: Handle rib updates as a thread event
If we need to batch process the rib (all tables or specific
vrf), do so as a scheduled thread event rather than immediately
handling it. Further, add context to the events so that you
narrow down to certain route types you want to reprocess.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Donald Sharp [Wed, 16 Oct 2019 17:19:09 +0000 (13:19 -0400)]
*: Allow disabling of `getrusage` calls
getrusage, in a heavily stressed system, can account for
signficant running time due to process switching to the kernel.
Allow the end-operator to specify `--disable-cpu-time` to
avoid this call. Additionally we cause `show thread cpu` to
not show up if this is selected.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Mark Stapp [Wed, 16 Oct 2019 12:51:43 +0000 (08:51 -0400)]
nhrpd: be more careful with linked lists
NHRPD has its own linked-list implementation, and one of the
apis is a little free and easy with pointers. Also be safer
with one list iteration operation.
GalaxyGorilla [Tue, 15 Oct 2019 11:15:22 +0000 (11:15 +0000)]
lib: Let libyang log everything possible
Currently libyang logs errors only (LY_LLERR by default), independent of
FRR's log level. This commit lets libyang log everything including all
sorts of debug logs (when libyang is built in 'Debug' mode). FRR's
logging infrastructure filters logs out according to the configured log
level.
There is a very small performance overhead involved, even when libyang
is build in 'Release' mode. This overhead is mainly affecting config
processing and barely measurable being around 0-3% of the processing
time without this change.
Stephen Worley [Tue, 15 Oct 2019 19:39:49 +0000 (15:39 -0400)]
zebra: Don't bother ref'ing ifp in zebra_pbr_rule
If we only really use the ifp for the name, then
don't bother referencing the ifp. If that ifp is
freed, we don't expect zebra to handle the rules that
use it (that's pbrd's job), so it is going to be
pointing to unintialized memory when we decide to remove
that rule later. Thus, just keep the name in the data
and dont mess with pointer refs.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Tue, 15 Oct 2019 18:50:10 +0000 (14:50 -0400)]
zebra: Use the rule ifindex as a hash key, not ifp
Use the ifindex value as a primary hash key/identifier, not
the ifp pointer. It is possible for that data to be freed
and then we would not be able to hash and find the rule entry
anymore. Using the ifindex, we can still find the rule even
if the interface is removed.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Stephen Worley [Tue, 15 Oct 2019 17:42:15 +0000 (13:42 -0400)]
zebra: Only free if rule was found/release in table
We were seeing a double free on shutdown if the
hash release fails here due to the interface state
changing. We probably shouldn't free the data if its
still being handled in the table so adding a check there
and a debug message.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Zebra tracked the last command sent to it's peer via peeking
into the data it was sending to each client ( since we had
lost the idea of what the command was when it was time to track
the data ).
Add a define to track this and add a bit of verbiage
to the code to allow us to notice when we screw with
the header again so that this is just fixed correctly
when it happens again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 15 Oct 2019 12:27:22 +0000 (08:27 -0400)]
bgpd: Soft reconfig-in should find the right bgp_path_info
When using soft reconfiguration inbound we are storing packet
data on the side for replaying when necessary. The problem here
is that we are just grabbing the first bgp_path_info and using
that as the base. What happens when we have soft-reconfig turned
on with multiple bgp_path_info's for a path? This was introduced
in commit 8692c506520f6b268525b80890702432c95f13c4, yes back
in 2012! I would argue, though, that it was just broken
in a different way before this.
Choose the correct bgp_path_info that corresponds to the peer
we received the data from for rethinking.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / matthieu / frr.git / log