Add the initial step of passing in a dplane context
to reading route netlink messages. This code
will be run in two contexts:
a) The normal pthread for reading netlink messages from
the kernel
b) The dplane_fpm_nl pthread.
The goal of this commit is too just allow a) to work
b) will be filled in in the future. Effectively
everything should still be working as it should
pre this change. We will just possibly allow
the passing of the context around( but not used )
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In order for a future commit to abstract the dplane_ctx_route_init
so that the kernel can use it, let's move some stuff around
and add a dplane_ctx_route_init_basic that can be used by multiple
different paths
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
create a dplane_ctx_route_init_basic so it can be used
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Zebra needs the ability to pass this data around.
Add it to the dplanes ability to pass.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
zebra: Add a dplane_ctx_set_flags
The dplane_ctx_set_flags call is missing, we will need it. Add it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we have this semantics:
int ret = FAILURE;
if (foo)
goto done;
....
done:
return ret;
This pattern does us no favors and makes it harder to figure out what is going
on. Let's remove.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Volta submitted notification changes for the dplane that had a
special use case for their system. Volta is no more, the code
is not being actively developed and from talking with ex-Volta
employees there is no current plans to even maintain this code.
Wrap the special handling of nexthops that their asic-dataplane
did in a bit of code to isolate it and allow for future removal,
as that I do not actually believe anyone else is using this code.
Add a CPP_NOTICE several years into the future that will tell us
to remove the code. If someone starts using it then they will
have to notice this variable to set it and hopefully they will
see my CPP_NOTICE to come talk to us. If this is being used then
we can just remove this wrapper.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Don't let `zprivs_caps_init` allocate resources without checking if
there were other caps previously allocated.
This fixes a memory leak that happens on daemons that `fork()` and reuse
the `<daemon>_di` (see `ldpd`/`lde`/`ldpe` code).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This series of events will crash BGP prior to the prior commit:
a) Configure an interfaced based peering
b) Shut the interface the peering is over
c) remove the peering from bgp
Show that this no longer happens
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In case of BGP unnumbered, BGP fails to free the nexthop
node for peer if the interface is shutdown before
unconfiguring/deleting the BGP neighbor.
This is because, when the interface is shutdown,
peer's LL neighbor address will be cleared. Therefore,
during neighbor deletion, since the peer's neighbor
address is not available, BGP will skip freeing the
nexthop node of this peer. This results in a stale
nexthop node that points to a peer that's already
been freed.
Ticket: 3191547
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
The command of "show ip ospf" is incomplete. But "show ipv6 ospf" is fine.
Just complete it with actual parameters.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
```
Direct leak of 112 byte(s) in 1 object(s) allocated from:
0 0x7feb66337a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
1 0x7feb660cbcc3 in qcalloc lib/memory.c:116
2 0x55cc3cba02d1 in info_make bgpd/bgp_route.c:3831
3 0x55cc3cbab4f1 in bgp_update bgpd/bgp_route.c:4733
4 0x55cc3cbb0620 in bgp_nlri_parse_ip bgpd/bgp_route.c:6111
5 0x55cc3cb79473 in bgp_update_receive bgpd/bgp_packet.c:2020
6 0x55cc3cb7c34a in bgp_process_packet bgpd/bgp_packet.c:2929
7 0x7feb6610ecc5 in thread_call lib/thread.c:2006
8 0x7feb660bfb77 in frr_run lib/libfrr.c:1198
9 0x55cc3cb17232 in main bgpd/bgp_main.c:520
10 0x7feb65ae5082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 112 byte(s) leaked in 1 allocation(s).
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The LISTNODE_ATTACH|DELETE macros are only used in
linklist.c. Let's remove temptation from people
to use them.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Check if we advertise more routes when an additional path comes up, and
if we withdraw if dissapears.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
To verify previous changes, this PR introduces topotest to verify
whether imported routes learnt from BGP unnumbered peers will be active
on VPN RIB and other VRF RIB.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
The existing EVPN documentation in bgp.rst does not provide a holistic
configuration, just examples of individual features, and doesn't give
an operator any idea of what a compatible Linux netdev configuration
might look like. This introduces evpn.rst which includes a sample
frr.conf and corresponding Linux interface config (via iproute2) that
an operator can use to setup a basic EVPN topology and model their
interface manager's config from.
This initial version of evpn.rst shows Linux netdev config for
traditional bridges (vlan_filtering=0) and traditional vxlan devices
(single VNI). Later changes to this file will cover the use of
VLAN-aware bridges (vlan_filtering=1), single VXLAN devices
(multi VNI), and eventually bonds (for EVPN-MH).
Eventually the plan is to move the existing EVPN content from bgp.rst
into evpn.rst, but for now let's get some user-facing documentation in
place for interface configs.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
With a dead interval of 40 seconds, each tests is waiting 40+
seconds for ospf convergence to occurr because the DR is re-elected
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The idea here is to pass "non-code agreements" through the PR review
mechanism, and have them visible in the git tree.
Two "example" (but real) accords are included, mostly to illustrate the
idea. Both of these should be non-controversial and have had some
previous discussion in random places.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
