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>
Spantik [Mon, 14 Oct 2019 12:17:29 +0000 (05:17 -0700)]
lib: Clean up the index that is being used for storing FD and events.
When POLLNVAL is received for a FD then that FD is removed from the
pfd array and also array is rearranged using memmove. When memmove
is used then unused index are not cleanedup. When a new FD takes
up that index then it ends up using stale events without any handler
set for the same.
Renato Westphal [Tue, 15 Oct 2019 01:20:24 +0000 (22:20 -0300)]
lib: fix harmless lyd_schema_sort() warning
The dnode member of the nb_config structure can be null on
daemons that don't implement any YANG module. As such, update
the nb_cli_show_config_prepare() function to always check if the
libyang data node that is going to be displayed is null or not
before operating on it.
This fixes the following warning (introduced by commit 5e6a9350c1):
libyang: Invalid arguments (lyd_schema_sort())
Reported-by: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Donald Sharp [Tue, 15 Oct 2019 01:09:55 +0000 (21:09 -0400)]
bgpd: Be careful about displaying vni's as labels.
When a type 2/3 or 5 route is received, verified and the
resulting route generated is pushed into the appropriate vrf
the vni's associated with the route are also passed in.
This is showing up as a Remote label when you dump
the route in bgp:
BGP routing table entry for 0.0.0.0/0^M
Paths: (1 available, best #1, table third)
Advertised to non peer-group peers:
10.10.120.22
42001 42005 42006 42055
10.10.120.22 from 10.10.120.22 (10.10.255.193)
Origin IGP, valid, external, bestpath-from-AS 42001, best
Remote label: 62750
AddPath ID: RX 0, TX 2
Last update: Fri Oct 11 12:59:56 2019
The `Remote label: 62750` is the mpls label version of the
vni passed in. This is meaningless and confusing to the end
user. Do not display this information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 15 Oct 2019 00:44:56 +0000 (20:44 -0400)]
bgpd: Properly lock parent node for type4 routes
When creating a bgp_path_info for a type 4 route the pi->extra->parent
and the route node for the originating table were not being locked
properly. This will prevent BGP from not properly cleaning up
the data structures on cleanup.
Possibly every one of the functions that we use to create the
new bgp_path_info's should use an abstracted version of this code,
but I am unsure at this point in time if a type 4 should use the same
or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / mirror / frr.git / log