This commit implements a new callback called `cli_show_end` which
complements `cli_show` and is only called at the end of processing the
yang configuration node. It will be used to write the configuration
node termination like: "!" or "exit-address-family".
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Philippe Guibert [Mon, 17 Jun 2019 13:17:20 +0000 (15:17 +0200)]
bfdd: avoid double socket initialisation on same netns
when working with a standard vrf backend, bfdd ignores that and tries to
create and configure bfd sockets for each vrf, which will fail for the
second vrf discovered, since the network namespace used is the same, and
it is not possible to use same socket settings twice. Handle this case,
and avoids to reinitialise sockets.
This patch however does not leverage bfd support for vrf-lite.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Thu, 20 Jun 2019 08:37:57 +0000 (04:37 -0400)]
pimd: Remove output of `debug igmp trace detail` from show commands
There has never been a `debug igmp trace detail` but we have
had code to display this when we had the appropriate flags
set. Since we never can accept this, let's remove this.
Visakha Erina [Wed, 19 Jun 2019 13:38:31 +0000 (06:38 -0700)]
lib: Keep proper count of prefix-list hit-count when used
When a prefix-list is applied to a BGP neighbor to deny the learning
of specific routes, the hit count is showing 0 for BGP even though
the routes are being filtered correctly due
to the configured prefix-list.
Before fix:
c1# show ip prefix-list nag seq 10
ZEBRA: seq 10 permit any (hit count: 0, refcount: 0)
BGP: seq 10 permit any (hit count: 0, refcount: 0)
c1# show ip prefix-list nag seq 5
ZEBRA: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
BGP: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
Fix: Increment the prefix-list's hit count whenever a rule match occurs.
After Fix:
c1# show ip prefix-list nag seq 10
ZEBRA: seq 10 permit any (hit count: 0, refcount: 0)
BGP: seq 10 permit any (hit count: 6, refcount: 0)
c1# show ip prefix-list nag seq 5
ZEBRA: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
BGP: seq 5 deny 1.0.1.0/24 (hit count: 1, refcount: 0)
Don Slice [Wed, 19 Jun 2019 11:22:21 +0000 (11:22 +0000)]
zebra: resolve issue with rnh not evaluating nexhops correctly
Problem discovered in testing that occasionally when an interface
address was flushed, the corresponding route would be removed from
the kernel and zebra but remain in the bgp table and be advertised
to peers. Discovered that when zebra_rib_evaluate_nexthops spun
thru the tree list of rns, if the timing and circumstances were
right, it would move elements and miss evaluating some. Changed
from frr_each to frr_each_safe and the problem is now gone.
Ticket: CM-25301 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Tue, 18 Jun 2019 19:47:10 +0000 (15:47 -0400)]
zebra: Display a bit better debugging for rnh tracking
Add a expected count for the route node we will be processing
as part of nexthop resolution and modify the type to display
a useful string of what the type is instead of a number.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 18 Jun 2019 13:21:49 +0000 (09:21 -0400)]
bgpd: BGP_ERR_MULTIPLE_INSTANCE_NOT_SET is an impossible condition
This code is not returned anywhere in the system as that bgp
is by default multiple-instance 'only' now. So remove
the last remaining bits of it from the code base.
Remove BGP_ERR_MULTIPLE_INSTANCE_USED too.
Make bgp_get explicitly return BGP_SUCCESS
instead of 0.
Remove the multi-instance error code too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 6 Jun 2019 00:59:02 +0000 (20:59 -0400)]
bgpd: Fix crash when rd has no data
There exists a state where we may have a rd node but no individual
evpn prefix nodes in the two level table:
(gdb) bt
at bgpd/bgp_evpn_vty.c:1190
filter=FILTER_RELAXED) at lib/command.c:1060
at lib/command.c:1119
vtysh=vtysh@entry=0) at lib/command.c:1273
(gdb) f 5
at bgpd/bgp_evpn_vty.c:1190
1190 bgpd/bgp_evpn_vty.c: No such file or directory.
(gdb) p buf
$1 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb) p json_nroute
$2 = (json_object *) 0x0
(gdb) p rd_header
$3 = 1
(gdb) p buf
$4 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb)
I'm not entirely sure that this is not a `different` problem in that the
rd node should have been removed. But I think preventing the crash
in a show command is probably the right thing to do here.
Fixes: #4501 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 6 Jun 2019 00:53:01 +0000 (20:53 -0400)]
bgpd: Mac rescan on interface up/down efficency improvements
On interface up/down, bgp stores the mac address of the interface
in a bgp_mac_hash table entry and then initiates a rescan
of the evpn l2vpn table. The problem with this scan is that
it is looking at every item in the table when only 1 mac
has changed. So every up/down event causes some major trauma
in the bgp_update processing.
Modify the mac scanning such that we know the mac that is changed
and as such we should reprocess those entries only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 18 Jun 2019 00:16:30 +0000 (20:16 -0400)]
bgpd: Fix memleak of Mac Hash String upon insertion
If we get a callback for a interface change but we do not
actually have to move the mac entry in the hash then
we were accidently leaking the Mac Hash String all over
ourselves. Messy Messy!
Ticket: CM-25351 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sat, 15 Jun 2019 01:47:27 +0000 (21:47 -0400)]
zebra: Handle 5549 neighbor entry failure state
If we get a neighbor entry for 5549 failure notice
from the kernel that means that something has probably
gone terribly wrong. Let's notice and not reinstall.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 13 Jun 2019 02:27:29 +0000 (22:27 -0400)]
lib: Add check for non-preexisting thread
When adding a read/write poll event and we are using a developmental
build add a bit of code to ensure that we do not already have an read
or write event scheduled.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 13 Jun 2019 01:13:18 +0000 (21:13 -0400)]
lib: Prevent infinite loop in fd handling
If we have a case where have created a fd for i/o and we have
removed the handling thread but still have the fd in the poll
data structure, there existed a case where we would get
the handle this fd return from poll but we would immediately
do nothing with it because we didn't have a thread to hand
the event to.
This leads to an infinite loop. Prevent the infinite loop
from happening and log the problem.
We still need to find the cause of this happening. But
let's prevent the system from melting down in the mean time.
Fixes: #2796 Signed-off-by: David Lamparter <equinox@diac24.net> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
projects / mirror / frr.git / log