MTYPE definitions should be local to the file using them whereever
possible. Also remove some superfluous ;
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The "static struct mtype * const MTYPE_FOO" doesn't quite make a
"constant" that is usable for initializers. An 1-element array works
better.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Position of address family and encoding type is defined wrongly in the
packed structure. This will correct the position as per RFC 4601 4.9.1
Signed-off-by: Saravanan K <saravanank@vmware.com>
Add a note in the fedora build guide on how to disable
firewalld and clear iptables that come by default.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
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.
This showed up because of commit:0ab16492d2d9fcc6cba7e001227deed6765ed261
where we re-arranged some debugs to combine them being turned on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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)
Signed-off-by: Visakha Erina visakha.erina@broadcom.com
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>
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>
The `bgp multiple-instance` command has been deprecated and
removed. Finish off this by removing it from topotests too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `bgp multiple-instance` command has been removed but
we did not properly update the documentation. Let's do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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>
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>
Add a bit of extra code to indicate to the operator why
we intentionally rejected a kernel route from being used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
