SA has decided that old_re could be a NULL pointer
even though the zebra_redistribute_check function
checks for NULL and returns false that would
not allow a NULL pointer deref.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Practically no-one uses this and ioctls are pretty much
wrappered. Further wrappering could make this even better.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix the following coverity issue:
*** CID 1575079: Null pointer dereferences (REVERSE_INULL)
/zebra/zebra_dplane.c: 5950 in dplane_srv6_encap_srcaddr_set()
5944 if (ret == AOK)
5945 result = ZEBRA_DPLANE_REQUEST_QUEUED;
5946 else {
5947 atomic_fetch_add_explicit(&zdplane_info
5948 .dg_srv6_encap_srcaddr_set_errors,
5949 1, memory_order_relaxed);
CID 1575079: Null pointer dereferences (REVERSE_INULL)
Null-checking "ctx" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
5950 if (ctx)
5951 dplane_ctx_free(&ctx);
5952 }
5953 return result;
5954 }
5955
Remove the pointer check for `ctx`. At this point in the
function it has to be non null since we deref'ed it.
Additionally the alloc function that creates it cannot
fail.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Despite if it's managed by FRR or the kernel, show it. If the system has only
link-local addresses, we should show it unless it's a secondary one.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Let's say we this:
```
$ ip link set down dev r1-eth0
$ ip link set up dev r1-eth0
```
But at the same time we have this interface configured by the FRR too:
```
interface r1-eth0
ipv6 address fe80:1::1/64
exit
```
We never re-add fe80:1::1/64, when the interface comes up, and we have a
strange situation where NHT stops working and other stuff depending on NHT
stops too (BGP peering, etc.).
Closes: https://github.com/FRRouting/frr/issues/15050
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The t_dequeue was being enqueued with a timer of 0
this is really an event instead of a timer. Let's
use that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
An operator is reporting that the dplane_fpm_nl connection has
started to accumulate contexts. One such path that could cause
this is that the obuf used is full and stays full. This would
imply that what ever is on the receiving end has gotten wedged
and is not reading from the stream of data being sent it's way.
If after 15 seconds of no response, let's declare the connection
dead and reset it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When zebra is started, someone may have configured an SRv6 encap source
address different from the default address ( :: ) in the kernel.
On startup, zebra should not assume that the actual SRv6 encap source
address is the default address ( :: ), but should retrieve the actual
source address from the kernel and put it in zebra configuration. In
other words, on startup we expect the actual SRv6 encap source
address and the configured one to be the same.
This commit makes the necessary changes to support the above.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
When writing the SRv6 config from zebra, we must also include the source
address of outer encapsulating IPv6 header.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Add a new CLI command `show segment-routing srv6 manager [json]` to
verify the overall SRv6 state. The current output displays only the
configured source address of outer encapsulating IPv6 header. The output
can be extended in the future to show more information, including
summary SRv6 information and supported capabilities.
Example:
```
r1# show segment-routing srv6 manager
Parameters:
Encapsulation:
Source Address:
Configured: fc00:0:1::1
r1# show segment-routing srv6 manager json
{
"parameters":{
"encapsulation":{
"sourceAddress":{
"configured":"fc00:0:1::1"
}
}
}
}
```
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
- Add a new node `SRV6_ENCAP_NODE` to the CLI graph. This node allows
users to configure encapsulation parameters for SRv6, including the
source address of the outer encapsulating IPv6 header.
- Install a new CLI command `source-address` under the
`SRV6_ENCAP_NODE` node. This command is used to configure the source
address of the outer encapsulating IPv6 header.
- Install a new CLI command `no source-address` under the
`SRV6_ENCAP_NODE` node. This command is used to unset the
source address of the outer encapsulating IPv6 header and restore the
default source address.
Examples:
```
router# segment-routing
router(sr)# srv6
router(srv6)# encapsulation
router(srv6-encap)# source-address fc00:0:1::1
```
```
router# segment-routing
router(sr)# srv6
router(srv6)# encapsulation
router(srv6-encap)# no source-address
```
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Add a bunch of set functions and associated data structure in
zebra_dplane to allow the configuration of the source address for SRv6
encap in the data plane.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Generic Netlink is an extension of Netlink meant for kernel-user space
communications. It supports the dynamic allocation of communication
channels. Kernel and user space applications register their services
with a Generic Netlink controller. The Generic Netlink controller is
responsible for assigning a unique channel number with each service.
Clients who want to use a service query the controller to see if
the service exists and to determine the correct channel number. The
channel number is used to access the requested service.
This commit adds the base functionality to get the channel number
assigned to a specific service. More precisely, this commit adds a
function `genl_resolve_family()` that takes the service name (called
family in the Generic Netlink terminology) as an input parameter and
queries the Generic Netlink controller to get the channel number
assigned with the requested service.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
zebra already supports several Netlink sockets which allow it to
communicate with the kernel. Each Netlink socket has a specific purpose:
we have a socket for incoming events from the kernel, a socket for
programming the dataplane, a socket for the kernel messages, a socket
used as the command channel. All the currently supported sockets are
based on the `NETLINK_ROUTE` protocol.
This commit adds a new Netlink socket that allows zebra to send
commands to the kernel using the `Generic Netlink` protocol.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
The `netlink_socket()` function is used in many places to create and
initialize Netlink sockets. Currently, it can only create
`NETLINK_ROUTE` Netlink sockets.
This commit generalizes the behavior of the `netlink_socket()` function,
enabling it to generate Netlink sockets of any type. Specifically, it
extends the `netlink_socket()` function with a new argument `nl_family`,
which allows developers to specify the Netlink family of the socket to
be created.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
The adata variable was being leaked on shutdown since
it was calloc'ed. There is no need to make this dynamic
memory. Just choose a size and use that. Add a bit
of code to ensure that if it's not large enough,
it will just stop and the developer will fix it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
the zebra pseudo wire code was registering a callback
per vrf. These callbacks are not per vrf based. They
are vrf agnostic so this was a mistake. Modify the code
to on startup register once and on shutdown unregister once.
Finally rename the zebra_pw_init and zebra_pw_exit functions
to more properly reflect when they are called.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
The NHG_DEL operation is done directly from ZAPI call, whereas
the NHG_ADD operation is done in the rib_nhg meta queue.
This may be problematic when ADD is followed by DEL. Imagine a
scenarion with two protocol NHIDs. <NH1> depends of <NH2> and
<NH3>. The deletion of <NH3> at the protocol level will trigger
2 messages to ZEBRA: NHG_ADD(<NH1>) and NHG_DEL(<NH3>).
Those operations are properly enqueued in ZAPI, but in the end,
the NHG_DEL is executed first. This causes NHG_ADD to unlink an
already freed NHG.
Fix this by consistently enqueuing NHG_DEL and NHG_ADD operations.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add ability for the connected routes to know
if they are a prefix route or not.
sharpd@eva:/work/home/sharpd/frr1$ ip addr show dev dummy1
13: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether aa:93:ce:ce:3f:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.55.1/24 scope global noprefixroute dummy1
valid_lft forever preferred_lft forever
inet 192.168.56.1/24 scope global dummy1
valid_lft forever preferred_lft forever
inet6 fe80::a893:ceff:fece:3f62/64 scope link
valid_lft forever preferred_lft forever
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show int dummy1"
Interface dummy1 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 13 metric 0 mtu 1500 speed 0 txqlen 1000
flags: <UP,BROADCAST,RUNNING,NOARP>
Type: Ethernet
HWaddr: aa:93:ce:ce:3f:62
inet 192.168.55.1/24 noprefixroute
inet 192.168.56.1/24
inet6 fe80::a893:ceff:fece:3f62/64
Interface Type Other
Interface Slave Type None
protodown: off
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show ip route"
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:00:08
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr2 linkdown, 00:00:08
L>* 192.168.44.1/32 is directly connected, dummy2, 00:00:08
L>* 192.168.55.1/32 is directly connected, dummy1, 00:00:08
C>* 192.168.56.0/24 is directly connected, dummy1, 00:00:08
L>* 192.168.56.1/32 is directly connected, dummy1, 00:00:08
L>* 192.168.119.205/32 is directly connected, enp13s0, 00:00:08
sharpd@eva:/work/home/sharpd/frr1$ ip route show
default via 192.168.119.1 dev enp13s0 proto dhcp metric 100
169.254.0.0/16 dev virbr2 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.45.0/24 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
192.168.56.0/24 dev dummy1 proto kernel scope link src 192.168.56.1
192.168.119.0/24 dev enp13s0 proto kernel scope link src 192.168.119.205 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
sharpd@eva:/work/home/sharpd/frr1$ ip route show table 255
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
local 192.168.44.1 dev dummy2 proto kernel scope host src 192.168.44.1
broadcast 192.168.44.255 dev dummy2 proto kernel scope link src 192.168.44.1
local 192.168.45.1 dev virbr2 proto kernel scope host src 192.168.45.1
broadcast 192.168.45.255 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
local 192.168.55.1 dev dummy1 proto kernel scope host src 192.168.55.1
broadcast 192.168.55.255 dev dummy1 proto kernel scope link src 192.168.55.1
local 192.168.56.1 dev dummy1 proto kernel scope host src 192.168.56.1
broadcast 192.168.56.255 dev dummy1 proto kernel scope link src 192.168.56.1
local 192.168.119.205 dev enp13s0 proto kernel scope host src 192.168.119.205
broadcast 192.168.119.255 dev enp13s0 proto kernel scope link src 192.168.119.205
local 192.168.122.1 dev virbr0 proto kernel scope host src 192.168.122.1
broadcast 192.168.122.255 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Fixes: #14952
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The linux kernel can send up a flag that tells us that the
connected address is not a PREFIXROUTE. Add the ability
to note this and pass it up from the data plane.
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>
Add three counters that account for the nhg operations
that are using the zebra API with the NHG_ADD and NHG_DEL
commands.
> # show zebra client
> [..]
> Type Add Update Del
> ==================================================
> IPv4 100 0 0
> IPv6 0 0 0
> Redist:v4 0 0 0
> Redist:v6 0 0 0
> NHG 1 1 1
> VRF 3 0 0
> [..]
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
