The "declare -p watchfrr_options" call is just to support backwards
compatibility. If it fails, silently ignore that.
Signed-off-by: David Lamparter <equinox@diac24.net>
Drop the special versions of frr.init/frr.service/daemons from redhat/
and use the generic versions instead.
Tested-by: Liam McBirnie <liam.mcbirnie@boeing.com>
Signed-off-by: David Lamparter <equinox@diac24.net>
Running valgrind w/ bfdd and shut/no shuting interfaces
can result in this valgrind issue:
==20279== Conditional jump or move depends on uninitialised value(s)
==20279== at 0x115848: bfdd_sessions_enable_address (ptm_adapter.c:644)
==20279== by 0x115848: bfdd_interface_address_update (ptm_adapter.c:674)
==20279== by 0x48D8CAB: zclient_read (zclient.c:2698)
==20279== by 0x48CCEE3: thread_call (thread.c:1603)
==20279== by 0x48A84EF: frr_run (libfrr.c:1011)
==20279== by 0x10DAC3: main (bfdd.c:236)
==20279==
When creating the bso data structure set the bso_isaddress to false
as a default value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a bgp-peer comes up prior to l3vnis are up in bgpd.
The EVPN routes (type-2/type-5) are learnt via peer.
The routes can have one of interface's MAC in rmac attribute.
The self rmac check would bypass as l3vni is not present.
Once l3vni has come up in bgpd, while installing evpn
routes in vrf table, perform rmac attribute check against self mac.
The routes with rmac of ours will be removed via re-scan
of routes during bgp_mac_rescan_all_evpn_tables when
interface mac is added to bgp.
Ticket:CM-24224
Reviewed By:CCR-8423
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulunetworks.com>
Add the address family to the sockaddr structure otherwise `sendmsg`
will fail with `EAFNOSUPPORT`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The topotests docker image has moved from frrouting/frr to
frrouting/topotests. Update accordingly.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Duplicate address detection and recovery was relying on the l2-vni backptr
in the neighbor entry which was simply not initialized resulting in
a NULL pointer access in a setup with dup-addressed VMs -
VM1:{IP1,M1} and VM2:{IP1,M2}
Call stack:
(gdb) bt 6
at lib/sigevent.c:249
nbr=nbr@entry=0x559347f901d0, vtep_ip=..., vtep_ip@entry=..., do_dad=do_dad@entry=true,
is_dup_detect=is_dup_detect@entry=0x7ffc7f6be59f, is_local=is_local@entry=true)
at ./lib/ipaddr.h:86
ip=0x7ffc7f6be6f0, ifp=0x559347f901d0, zvni=0x559347f86800) at zebra/zebra_vxlan.c:3152
(More stack frames follow...)
(gdb) p nbr->zvni
$8 = (zebra_vni_t *) 0x0 <<<<<<<<<<<<<<<<<<<<
(gdb)
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
System Routes if received over the netlink bus in a
specific pattern that causes an update operation for that
route in zebra can leave the dest->selected_fib pointer NULL,
while having the ZEBRA_FLAG_SELECTED flag set. Specifically
one way to achieve this is to do this:
`ip addr del 4.5.6.7/32 dev swp1 ; ip addr add 4.5.6.7/32 dev swp1 metric 9`
Why is this a big deal?
Because nexthop tracking is looking at ZEBRA_FLAG_SELECTED to
know if we can use a route, while nexthop active checking uses
dest->selected_fib.
So imagine we have bgp registering a nexthop. nexthop tracking in
the above case will be able to choose the 4.5.6.7/32 route
if that is what the nexthop is, due to the ZEBRA_FLAG_SELECTED being
properly set. BGP then allows the peers connection to come up and we
install routes with a 4.5.6.7 nexthop. The rib processing for route
installation will then look at the 4.5.6.7 route see no
dest->selected_fib and then start walking up the tree to resolve
the route. In our case we could easily hit the default route and be
unable to resolve the route. Which then becomes inactive in the
rib so we never attempt to install it.
This commit fixes this problem because when the rib_process decides
that we need to update the fib( ie replace old w/ new ), the
replacement with new was not setting the `dest->selected_fib` pointer
to the new route_entry, when the route was a system route.
Ticket: CM-24203
Signed-off-by: Donald Sharp <sharpd@cumulusnetworkscom>
When we are shutting down, delay the zlookup free to as
late as possible since we may need it still
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Found that previous fix for this issue caused collatoral damage and
reverted that fix. This fix clears the vrf_bitmaps when the vrf is
disabled/deleted and then re-applies the redist config when the vrf
is re-enabled.
Ticket: CM-24231
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Fix a few json output values: a few are in seconds, not msecs,
and one is a number-per-second, not a duration.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
New BFD topology using IPv6 and multi hop peer to cover more daemon
features. This topology also tests BFD integration with BGP, OSPF and
OSPF6.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When the local-address configured by the peer doesn't exist, then we
must observe the session until the mentioned address comes up.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Use simplier data structure key to avoid having to do complex and
error-prone key building (e.g. avoid expecting caller to know IPv6
scope id, interface index, vrf index etc...).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
