Rafael Zalamena [Wed, 29 May 2019 20:17:37 +0000 (17:17 -0300)]
bfdd: fix northbound remote-discriminator display
When the remote discriminator hasn't been assigned yet, then we can't
return a value of 0. The value '0' is an invalid discriminator and the
yang handlers will complain about it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Rafael Zalamena [Thu, 23 May 2019 19:09:24 +0000 (16:09 -0300)]
bfdd: migrate session commands to northbound
Lets start using the new BFD yang model and translate the BFD session
configuration commands to use the northbound.
One important change: all sessions will default to use
`VRF_DEFAULT_NAME` (usually "default") when no VRF is configured. All
places which search for BFD sessions must now take this into account.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
projects / mirror_frr.git / log