Preexisting code to detect commands targeted at wrong instance didn't
work because a command applied to a disconnected vtysh_client counted as
a successful run overriding wrong instance error message
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
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.
sharpd@robot ~> sudo vtysh -c "show ip mroute fill"
Source Group Proto Input Output TTL Uptime
* 229.1.1.1 STATIC dum0 enp3s0 1 00:11:07 Default-IP-Routing-Table
* 229.1.1.1 STATIC dum0 virbr0 1 00:01:47 Default-IP-Routing-Table
sharpd@robot ~>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
when warning about daemons that are not running, make sure to handle the
multi instance case
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
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>
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>
irdp is crashing because it assumes that people have
configured it in a certain way. Ensure that this
'way' is honored at least enough so that we don't
crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
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>
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>
This is a continuation of 915902cb82. 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>
While u_char is technically a uint8_t in size I would
like to treat and think about the admin distance
as an actual integer value from 0-255, instead
of a char.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For ZEBRA_ROUTE_KERNEL types:
The metric/priority of the route received from the kernel
is a 32 bit number. We are going to interpret the high
order byte as the Admin Distance and the low order 3 bytes
as the metric.
This will allow us to do two things:
1) Allow the creation of kernel routes that can be
overridden by zebra.
2) Allow the old behavior for 'most' kernel route types
if a user enters 'ip route ...' v4 routes get a metric
of 0 and v6 routes get a metric of 1024. Both of these
values will end up with a admin distance of 0, which
will cause them to win for the purposes of zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
