Donald Sharp [Mon, 2 Oct 2017 14:45:30 +0000 (10:45 -0400)]
zebra: Properly initialize memory for rtadv
The adata pointer was not properly being set to
0 before being used. In addition notice malloc
failure and hard exit. If we have no memory on
startup something terrible has gone wrong and
we were going to crash shortly here anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 28 Sep 2017 12:05:20 +0000 (08:05 -0400)]
pimd: Add 'show ip mroute fill' command
When displaying the mroute table, add ability to fill
in all the missing data that for human eyes can be assumed.
This will allow people using grep over the command
can get more information.
Quentin Young [Wed, 27 Sep 2017 02:41:47 +0000 (22:41 -0400)]
vtysh: remove extra / in config path
before:
frrdev# do wr
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr//frr.conf
[OK]
frrdev#
after:
frrdev# do wr
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
frrdev#
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Wed, 27 Sep 2017 00:06:13 +0000 (20:06 -0400)]
bgpd: Reduce multiaccess_check_v4 overhead for subgroups
Perf results at scale( >1k peers) showed a non-trivial
amount of time spent in bgp_multiaccess_check_v4. Upon
function examination we are looking up the nexthops
connected node in each call as well as having to unlock
it after each iteration. Rewrite to lookup the nexthop
node once.
This should reduce the node lookup by aproximately 1/2
which should yield some performance results. There are
probably better things to do here but would require
deeper thought.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 26 Sep 2017 20:28:08 +0000 (16:28 -0400)]
vtysh: Remove double display of daemon info for 'show debugging'
When entering 'show debugging' we were outputting a line
from vtysh and a line from an individual daemon to show
the fact we were debugging. A bit overkill.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Fri, 1 Sep 2017 18:33:00 +0000 (14:33 -0400)]
pimd: add support for boundaries
Adds the ability to filter PIM Joins & IGMP reports on an interface.
Enabling a multicast boundary on an interface for a particular group
will prevent the interface from appearing in the group's OIL.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Mon, 25 Sep 2017 19:41:28 +0000 (15:41 -0400)]
lib: Set pointer to NULL after free
list_delete does not set the list pointer to NULL
Thus when we accidently use it later we happily write
off into lala land instead of crashing imediately
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Thu, 21 Sep 2017 20:03:17 +0000 (16:03 -0400)]
ospf6d: fix heap use after free
During the loop we save a pointer to the next route in the table in case
brouter is deleted during the course of the loop iteration. However when
we call ospf6_route_remove this can trigger ospf6_route_remove on other
routes in the table, one of which could be pointed at by said pointer.
Since ospf6_route_next locks the route that it returns, it won't
actually be deleted, instead the refcount will go to 1. In the next loop
iteration, nbrouter becomes brouter, and calling ospf6_route_next on
this one will finally decrement the refcount to 0, resulting in a free,
which causes subsequent reads on brouter to be UAF. Since the route will
have OSPF6_ROUTE_WAS_REMOVED set, provided the memory was not
overwritten before we got there, we'll continue on to the next one so it
is unlikely this will cause a crash in production.
Solution implemented is to check if we've deleted the route and continue
if so.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Mon, 25 Sep 2017 16:28:39 +0000 (12:28 -0400)]
zebra: Do not allow delete of route from kernel in non-startup case
This is a continuation of 915902cb82cfd. Basically the netlink
read of messages up from the kernel is now noticing the proper
owner of the route. As such when rib_delete was being called
as part of the upcall from the kernel we were not noticing that
we were the originator and not diss-allowing the rib_delete
from happening. This restores this behavior that we were getting
pre-915902cb82cfd
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 25 Sep 2017 12:10:24 +0000 (08:10 -0400)]
zebra: Do not allow same rib_dest_t be queued multiple times to meta queue
If we have already scheduled a node to be on the meta_queue, there is no
need to schedule it up again.
On startup we are calling rib_update() multiple times per connected route.
Due to the multiple ways we can get callbacks for adding a connected route
I decided it was best to just improve meta_queue performance as opposed
to trying to figure out all the different ways across all the platforms
that we can decide that a connected route has changed. This appears
to solve the issue with a very large # of interfaces coming up
at the same time on startup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Christian Franke [Sat, 23 Sep 2017 18:01:43 +0000 (20:01 +0200)]
isisd: ensure fragments get always linked
When we receive or generate new versions of fragments which are
curently pending for age out, we need to ensure that they are correctly
linked to their lsp0.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Sat, 23 Sep 2017 17:28:48 +0000 (19:28 +0200)]
isisd: always trigger spf run asynchronously
isis_spf_schedule gets called in states where an immediate spf run
will lead to crashes, e.g. from lsp_destroy. Delay the spf execution
until the event calling isis_spf_schedule has run to completion to
avoid this.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Sat, 23 Sep 2017 17:27:29 +0000 (19:27 +0200)]
isisd: use only one IP of neighbor as nexthop
There is no point in building a multipath route via one neighbor
if there is only one link to the neighbor, but the neighbor has
multiple IPs on that link. So only create one nexthop per link.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Christian Franke [Fri, 22 Sep 2017 20:17:20 +0000 (22:17 +0200)]
isisd: Don't corrupt generated LSPs if information exceeds capacity
Standard IS-IS only supports up to 256 fragments per router. Recognize
when the information we want to advertise exceeds 256 fragments and
print a warning in this case instead of overflowing the fragment counter
and overwriting existing LSP fragments.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
zebra: make rib_add() a simple wrapper for rib_add_multipath()
Both function were very similar, and as we know code duplication is not
good. As an example, in the past couple of weeks some fixes were made
on rib_add() but not on rib_add_multipath(), causing known bugs to still
exist in a different form.
Instead of merging the two functions into one, let's make rib_add()
call rib_add_multipath() with the appropriate parameters. This way we
remove the code duplication but still keep the easy-to-use rib_add()
function for single-path routes.
zebra: fix detection of duplicate kernel routes (ECMP version)
Fixes the following bug:
% ip route add 50.0.0.0/8 nexthop via 10.0.1.2 nexthop via 10.0.2.2
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.3 nexthop via 10.0.2.3
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.4 nexthop via 10.0.2.4
%
% vtysh -c "show ip route"
[snip]
K * 50.0.0.0/8 [0/0] via 10.0.1.4, rt1-eth1, 00:00:00
* via 10.0.2.4, rt1-eth2, 00:00:00
K * 50.0.0.0/8 [0/0] via 10.0.1.3, rt1-eth1, 00:00:10
* via 10.0.2.3, rt1-eth2, 00:00:10
K>* 50.0.0.0/8 [0/0] via 10.0.1.2, rt1-eth1, 00:00:24
* via 10.0.2.2, rt1-eth2, 00:00:24
Commit a3d18ce6 fixed a similar problem for single-path routes.
*: fix segfault when sending more than MULTIPATH_NUM nexthops
This is a fallout from PR #1022 (zapi consolidation). In the early days,
the client daemons would allocate enough memory to send all nexthops
to zebra. Then zebra would add all nexthops to the RIB and respect
MULTIPATH_NUM only when installing the routes in the kernel. Now things
are different and the client daemons can send at most MULTIPATH_NUM
nexthops to zebra, and failure to respect that will result in a buffer
overflow. The MULTIPATH_NUM limit in the new zebra API is a small price
we pay to avoid allocating memory for each route sent to zebra.
Daniel Walton [Tue, 19 Sep 2017 13:38:35 +0000 (13:38 +0000)]
bgpd: debugs on subnets need to use apply_mask()
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
You could configure something bogus like "debug bgp updates prefix
10.1.1.1/16", this needs to be converted to "10.1.0.0/16"