Introduce the End.B6.Encaps in the rt_netlink code.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This leak is happening:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
0 0x7f6922eb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7f6922a38ebb in qcalloc lib/memory.c:106
2 0x7f6922a553d6 in nexthop_add_srv6_seg6 lib/nexthop.c:652
3 0x562825e56b38 in parse_nexthop_unicast zebra/rt_netlink.c:589
4 0x562825e58c4a in netlink_route_change_read_unicast_internal zebra/rt_netlink.c:1291
5 0x562825e58eef in netlink_route_change_read_unicast zebra/rt_netlink.c:1321
6 0x562825e64921 in netlink_route_change zebra/rt_netlink.c:1494
7 0x562825e43407 in netlink_information_fetch zebra/kernel_netlink.c:407
8 0x562825e439b5 in netlink_parse_info zebra/kernel_netlink.c:1148
9 0x562825e44060 in kernel_read zebra/kernel_netlink.c:510
10 0x7f6922aeca72 in event_call lib/event.c:1984
11 0x7f6922a19e01 in frr_run lib/libfrr.c:1246
12 0x562825e4b0b9 in main zebra/main.c:543
13 0x7f692250c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Just check to see if it has been allocated. The nexthop is a stack
variable so it's a bit odd.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The Linux kernel doesn't support dst-src routes with NHGs as nexthop,
for some (rather dubious) caching reasons.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The netlink route message encode function accessed and used
zebra vrfs to produce debug output. That's not thread-safe, and
that encode code needs to run in (at least) the dplane pthread
and the FPM plugin pthread.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Separate core netlink route message parsing into a new api that
uses a dplane ctx to hold the parsed attribute data. Use the new
api in two paths: the normal netlink update message parsing path,
and in the FPM plugin, which also uses netlink encoding. The FPM
route-notificatin code runs in its own pthread, and only needs
a subset of the route info that zebra ordinarily develops. This
change stops that pthread from accessing zebra's internal
data, such as vrfs and ifps, that are not thread-safe.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Currently the mroute code was not allowing the mroute
to be sent to the dataplane. This leaves us with a
situation where the routes being installed where never
being set as installed and additionally nht against
the mrib would not work if the route came into existence
after the nexthop tracking was asked for.
Turns out all the pieces where there to let this work.
Modify the code to pass it to the dplane and to send
it back up as having worked.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently FRR is limiting the nexthop count to a uint8_t not a
uint16_t. This leads to issues when the nexthop count is 256
which results in the count to overflow to 0 causing problems
in the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current code intentionally ignores kernel routes. Modify
zebra to allow these routes to be read in on linux. Also
modify zebra to look to see if a route should be treated
as a connected and mark it as such.
Additionally this should properly handle some of the issues
being seen with NOPREFIXROUTE.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
All routes received by zebra from upper level protocols have a weight
of 1. Let's just make everything extremely consistent in our code.
Lot's of tests needed to be fixed up to make this work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Include the prefix source address when set by a route-map in
show output for routes, in various formats.
Add some debugs when encoding netlink route messages with
a source address.
Signed-off-by: Mark Stapp <mjs@cisco.com>
The fpm code path for the dplane_fpm_nl module was improperly
encoding the multipath nexthop data for vxlan type routes.
Move this into the embedded nexthop encoding where it belongs.
This change makes it so that the usage of `-M dplane_fpm_nl`
is now producing the same netlink messages that `-M fpm`
produces when using vxlan based nexthops.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the support for adding DX6 behavior into netlink layer of zebra.
Add the necessary test in sharpd.
> ubuntu2204# sharp install seg6local-routes 1:1::1:2 nexthop-seg6local loop1 End_DX6 4:4::4:6 1
> ubuntu2204# do show ipv6 route
> [..]
> D>* 1:1::1:2/128 [150/0] is directly connected, loop1, seg6local End.DX6 nh6 4:4::4:6, weight 1, 00:00:03
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When configuring a SID list by vtysh, the segment list
obtained in iproute2 is the exact opposite:
>
>vtysh:
>ipv6 route 2005::/64 eth0 segments 2001:db8:aaaa::7/2002::2/2003::3/2004::4
>
>root@r1:/# ip -6 route
>2005::/64 nhid 6 encap seg6 mode encap segs 4 [ 2004::4 2003::3 2002::2 2001:db8:aaaa::7 ] dev dummy0 proto 196 metric 20 pref medium
>
Fix this by keeping the same vtysh config and swap the
segment's order of the list in the rt_netlink.c
>
>root@r1:/# ip -6 route
>2005::/64 nhid 6 encap seg6 mode encap segs 4 [ 2001:db8:aaaa::7 2002::2 2003::3 2004::4 ] dev dummy0 proto 196 metric 20 pref medium
>
Fixes: f20cf14 ("bgpd,lib,sharpd,zebra: srv6 introduce multiple segs/SIDs in nexthop")
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
The route entry created when using a ctx to pass route
entry data backup to the master pthread in zebra is
being leaked. Prevent this from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When allocating big protocol level identifiers, the number range is
big, and when pushing to netlink messages, the first nexthop group
is truncated, whereas the nexthop has been installed on the kernel.
> ubuntu2204(config)# nexthop-group A
> ubuntu2204(config-nh-group)# group 1
> ubuntu2204(config-nh-group)# group 2
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 1
> ubuntu2204(config-nh-group)# nexthop 192.0.2.130 loop1 enable-proto-nhg-control
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 2
> ubuntu2204(config-nh-group)# nexthop 192.0.2.131 loop1 enable-proto-nhg-control
> [..]
> 2023/11/24 16:47:40 ZEBRA: [VNMVB-91G3G] _netlink_nexthop_build_group: ID (179687500): group 17968/179687502
> # ip nexthop ls
> id 179687500 group 179687501/179687502 proto 194
Fix this by increasing the buffer size when appending the first number.
Fixes: 8d03bc501b ("zebra: Handle nhg_hash_entry encaps/more debugging")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The fpm code path in building a ecmp route for evpn has
a bug that caused it to not add the encap attribute to
the netlink message. See #f0f7b285b99dbd971400d33feea007232c0bd4a9
for the single path case being fixed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Replace several switch blocks that contain every dplane opcode
with simpler sets of if()s. In these cases the code only
uses a couple of opcodes.
Signed-off-by: Mark Stapp <mjs@labn.net>
The nexthop group route replace operation was made consistent
across all versions of the kernel. A v6 route replacement
does not need to do a delete than add when using nexthop
groups
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Create Local routes in FRR:
S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51
O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51
L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51
O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46
C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46
Create ability to redistribute local routes.
Modify tests to support this change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently in the single nexthop case w/ evpn sending
down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the
nexthop happened but the fpm failed to be accounted for.
Let's just move the encap type encoding to where it
will happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Append zebra and lib to use muliple SRv6 segs SIDs, and keep one
seg SID for bgpd and sharpd.
Note: bgpd and sharpd compilation relies on the lib and zebra files,
i.e if we separate this: lib or zebra or bgpd or sharpd in different
commits - this will not compile.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Extend the `parse_encap_seg6local` function to parse SRv6 flavors
information contained in the Netlink message.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
1) Add a bunch of get/set functions and associated data
structure in zebra_dplane to allow the setting and retrieval
of interface netlink data up into the master pthread.
2) Add a bit of code to breakup startup into stages. This is
because FRR currently has a mix of dplane and non dplane interactions
and the code needs to be paused before continuing on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Rename the vrf_lookup_by_id function to zebra_vrf_lookup_by_id
and move to zebra_vrf.c where it nominally belongs, as that
we need zebra specific data to find this vrf_id and as such
it does not belong in vrf.c
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
