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>
If there happens to be a entry in the zebra rib
that has a lower admin distance then a newly received
re, zebra would not notify the upper level protocol
about this happening. Imagine a case where there
is a connected route for say a /32 and bgp receives
a route from a peer that is the same route as the
connected. Since BGP has no network statement and
perceives the route as being `good` bgp will install
the route into zebra. Zebra will look at the new
bgp re and correctly identify that the re is not
something that it will use and do nothing. This
change notices this and sends up a BETTER_ADMIN_WON
route notification.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Configure hash table cleanup with specific free functions for `zrouter.filter_hash`, `zrouter.qdisc_hash`, and `zrouter.class_hash`.
This ensures proper memory cleanup, addressing memory leaks.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in tc_basic.test_tc_basic/r1.asan.zebra.15495
=================================================================
==15495==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c9e in tc_filter_alloc_intern zebra/zebra_tc.c:389
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c7c74 in zebra_tc_filter_add zebra/zebra_tc.c:409
#5 0x55645210755a in zread_tc_filter zebra/zapi_msg.c:3428
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c6e in tc_class_alloc_intern zebra/zebra_tc.c:239
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c784f in zebra_tc_class_add zebra/zebra_tc.c:293
#5 0x556452107ce5 in zread_tc_class zebra/zapi_msg.c:3315
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c3e in tc_qdisc_alloc_intern zebra/zebra_tc.c:128
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c753b in zebra_tc_qdisc_install zebra/zebra_tc.c:184
#5 0x556452108203 in zread_tc_qdisc zebra/zapi_msg.c:3286
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 228 byte(s) leaked in 3 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
a) Rename rib_init to zebra_rib_init() to better follow how
things are named
b) on shutdown cycle through the rib_dplane_q and free
up any contexts sitting in it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
INTERFACE_NAMSIZ is just a redefine of IFNAMSIZ and IFNAMSIZ
is the standard for interface name length on all platforms
that FRR currently compiles on.
Signed-off-by: Donald Sharp <sharpd@nvidia.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>
Fix memory leaks by allocating `json_segs` conditionally on `nexthop->nh_srv6->seg6_segs`.
The previous code allocated memory even when not in use or attached to the JSON tree.
The ASan leak log for reference:
```
Direct leak of 3240 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de9e6f in json_object_new_array (/lib/x86_64-linux-gnu/libjson-c.so.3+0x3e6f)
#2 0x564dcab5c1a6 in vty_show_ip_route zebra/zebra_vty.c:705
#3 0x564dcab5cc71 in do_show_route_helper zebra/zebra_vty.c:955
#4 0x564dcab5d418 in do_show_ip_route zebra/zebra_vty.c:1039
#5 0x564dcab63ee5 in show_route_magic zebra/zebra_vty.c:1878
#6 0x564dcab63ee5 in show_route zebra/zebra_vty_clippy.c:659
#7 0x7f6e843b6fb1 in cmd_execute_command_real lib/command.c:978
#8 0x7f6e843b7475 in cmd_execute_command lib/command.c:1036
#9 0x7f6e843b78f4 in cmd_execute lib/command.c:1203
#10 0x7f6e844dfe3b in vty_command lib/vty.c:594
#11 0x7f6e844e02e6 in vty_execute lib/vty.c:1357
#12 0x7f6e844e8bb7 in vtysh_read lib/vty.c:2365
#13 0x7f6e844d3b7a in event_call lib/event.c:1965
#14 0x7f6e844172b0 in frr_run lib/libfrr.c:1214
#15 0x564dcaa50e81 in main zebra/main.c:488
#16 0x7f6e837f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 11520 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de88c0 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x28c0)
Indirect leak of 1080 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de8897 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x2897)
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
a) nl_batch_tx_buf was not being freed
b) the mlag_fifo was not being freed
c) the vrf->ns_ctxt was not being freed
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We cannot build on apple machines at all due
to our usage of some gcc extensions that will
probably never see the light of day again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
The v6_rr_semantics variable was being set but never
reported and had to be inferred from watching netlink
messages to the kernel. Let's add a bit of code
to `show zebra` so that we can know how it is being
used.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Without this patch, static ARP entries remain active even if the interface is
down, but the kernel already removed them.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Recent Changes added the -Wimplicit-fallthrough flag
to FRR's compilation. Implementor does not build with
lua support and as such this one was missed in the compilation
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
A dead code. When `is_table_direct` is true, vrf_id is always VRF_DEFAULT.
So this block is never called.
CID 1570863.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is addressing remaining places returning
empty dict, earlier PR-13214 addressed few places.
Code has been changed to return {} for all the evpn clis
when evpn is disabled or no entry available.
```
cumulus@r2:mgmt:~$ sudo vtysh -c "show evpn json"
cumulus@r2:mgmt:~$
```
After Fix:-
```
cumulus@r1:mgmt:~$ sudo vtysh -c "show evpn json"
{
}
cumulus@r1:mgmt:~$
```
Ticket:#3417955
Issue:3417955
Testing: UT done
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
Signed-off-by: Chirag Shah <chirag@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>
Zebra currently does a shortest prefix match for
resolving nexthops for a prefix. This is typically
an ok thing to do but fails in several specific scenarios.
If a nexthop matches to a route that is not usable, nexthop
resolution just gives up and refuses to use that particular
route. For example if zebra currently has a covering prefix
say a 10.0.0.0/8. And about the same time it receives a
10.1.0.0/16 ( a more specific than the /8 ) and another
route A, who's nexthop is 10.1.1.1. Imagine the 10.1.0.0/16
is processed enough to know we want to install it and the
prefix is sent to the dataplane for installation( it is queued )
and then route A is processed, nexthop resolution will fail
and the route A will be left in limbo as uninstallable.
Let's modify the nexthop resolution code in zebra such that
if a nexthop's most specific match is unusable, continue looking
up the table till we get to the 0.0.0.0/0 route( if it's even
installed ). If we find a usable route for the nexthop accept
it and use it.
The bgp_default_originate topology test is frequently failing
with this exact problem:
B>* 0.0.0.0/0 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 1.0.1.17/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 1.0.2.17/32 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
C>* 1.0.3.17/32 is directly connected, lo, 00:02:00
B>* 1.0.5.17/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B>* 192.168.0.0/24 [200/0] via 192.168.1.1, r2-r1-eth0, weight 1, 00:00:21
B 192.168.1.0/24 [200/0] via 192.168.1.1 inactive, weight 1, 00:00:21
C>* 192.168.1.0/24 is directly connected, r2-r1-eth0, 00:02:00
C>* 192.168.2.0/24 is directly connected, r2-r3-eth1, 00:02:00
B>* 192.168.3.0/24 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
B 198.51.1.1/32 [200/0] via 192.168.0.1 inactive, weight 1, 00:00:21
B>* 198.51.1.2/32 [20/0] via 192.168.2.2, r2-r3-eth1, weight 1, 00:00:32
Notice that the 1.0.1.17/32 route is inactive but the nexthop
192.168.0.1 is covered by both the 192.168.0.0/24 prefix( shortest match )
*and* the 0.0.0.0/0 route ( longest match ). When looking at the logs
the 1.0.1.17/32 route was not being installed because the matching
route was not in a usable state, which is because the 192.168.0.0/24
route was in the process of being installed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Redistributing routes from a specific routing table to a particular routing
protocol necessitates copying route entries to the main routing table using the
"ip import-table" command. Once copied, these routes are assigned a distinct
"table" route type, which the "redistribute table" command of the routing
protocol then picks up.
For illustration, here is a configuration that showcases the use of
"import-table" and "redistribute":
> # show running-config
> [..]
> ip route 172.31.0.10/32 172.31.1.10 table 100
> router bgp 65500
> address-family ipv4 unicast
> redistribute table 100
> exit-address-family
> exit
> ip import-table 100
>
> # show ip route vrf default
> [..]
> T[100]>* 172.31.0.10/32 [15/0] via 172.31.1.10, r2-eth1, weight 1, 00:00:05
However, this method has inherent constraints:
- The 'import-table' parameter only handles route table id up to 252. The
253/254/255 table ids are reserved in the linux system, and adding other table
IDs above 255 leads to a design issue, where the size of some tables is directly
related to the maximum number of table ids to support.
- Duplicated route entries might interfere with original default table routes,
leading to potential conflicts. There is no guarantee that the zebra RIB will
favor these duplicated entries during redistribution.
- There are cases where the table ID can be checked independently of the default
routing table, as seen in Linux where the "ip rule" command is able to divert
traffic to that routing table. In that case, there is no need to duplicate route
entries in the default routing table.
To overcome these issues, a new redistribution type is proposed to redistribute
route entries directly from a specified routing table, eliminating the need for
an initial import into the default table.
Add a 'ZEBRA_ROUTE_TABLE_DIRECT' type to the 'REDISTRIBUTE' ZAPI messages. It
allows sending routes from a given non default table ID from zebra to a routing
daemon. The destination routing protocol table must be the default table.
The redistributed route inherit from the default distance value of 14: this is
the distance value reserved for routes redistributed via ROUTE_TABLE_DIRECT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A static label allocation should not be accepted if the desired range
conflicts with the configured dynamic-block configuration.
Do not accept such label requests, only when dynamic blocks are
configured.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit adds support for the label chunk allocation in
the configured dynamic block range.
An additional check ensures the upper bound does not go
over the upper bound of the dynamic-block.
Otherwise, a chunk is created with the lower bound set
to the first label element available in the defined
range.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label chunk algorithm needs to be revisited to support a
configured dynamic-block or the default one.
Reuse the 'lbl_mgr.dynamic_block_[start/end]' variables,
whereever needed, and simplify the algorithm.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Hardset label values (eg. ISIS Segment-routing label blocks,
hardset BGP L3VPN service label) may conflict with label chunks
dynamically allocated by zebra.
Add an optional 'mpls label dynamic-block' command to let the user
define a range that is not in conflict with the hardset values.
Restarting control planes is recommended when dynamic label
chunks are already allocated. Command is aborted when any hardset
label chunks conflict with the dynamic block.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
After ISIS first allocates a label chunk at [1000;2000],
the '16' label value is not used when BGP tries to
allocate a label chunk in auto mode. This does not happen
when BGP is the only one to do the label allocation.
When a label chunk has been accepted, the next label
request checks if there is room space before the existing
label chunk, and uses the lower label value to 17, and not
16.
Fix this by changing the previous range end 'prev_end' label
value to 15 which is the end of the reserved MPLS label
range.
Fixes: 3c84497943 ("zebra: label manager should never return a reserved block")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The zebra label manager stores the mpls label chunks,
but does not record if the label request was for a
dynamic or a static chunk.
For all label requests accepted, mark the label chunk
if the 'base' parameter is set to MPLS_LABEL_BASE_ANY,
unmark it otherwise.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When the label manager is unable to provide a label chunk to
a routing service, an error message is displayed:
> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk to bgp instance 0
There is missing information on the range that was requested.
Add this information in the log message.
> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk 60 - 60 to bgp instance 0
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This function lm_get_chunk_response() is only called
by label_manager_get_chunk(). Let us move the code of
the function in the caller.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
The weight scale value might be useful to have it
change it's behavior at a later time or controlled
by something depending on how FRR is compiled/ran.
Let's start that process
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently underlying asics get into a bit of trouble when the
nexthop weight passed down varies wildly between the different
numbers. Let's normalize the weight values between 1 and 255
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Separate commit for clang-format cleanup of string
messages because I felt it would hide the actual
changes being made to the system.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We may receive some xxxCHAIN netlink messages, but we ignore
them (currently). Add them to the basic handler callback so
that we don't log errors about them.
Signed-off-by: Mark Stapp <mjs@labn.net>
`ng` was not properly freed, leading to a memory leak.
The commit calls `nexthop_group_delete` to free memory associated with `ng`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308
=================================================================
==24308==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
#2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270
#3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681
#4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
#5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
#6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
#7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
#8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
#9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
#10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
#11 0x7f4f475dc7f2 in event_call lib/event.c:1969
#12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
#13 0x562ded69e818 in main zebra/main.c:486
#14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
#0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
#2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376
#3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914
#4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444
#5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682
#6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
#7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
#8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
#9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
#10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
#11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
#12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
#13 0x7f4f475dc7f2 in event_call lib/event.c:1969
#14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
#15 0x562ded69e818 in main zebra/main.c:486
#16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
When netlink_link_change() errors out for a new link for
interface without MTU set, the allocated ctx is not freed..
Adding code for correctness
Ticket# 3628313
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Include a zclient value in the hash and tree key computations
for iprules in zebra: clients may collide without this.
Signed-off-by: Mark Stapp <mjs@labn.net>
The iprule/pbr rule object has a vrf id, and zebra uses
that internally, but the vrf id isn't returned to clients
who install rules and are waiting for results. Include the
vrf_id sent by the client in the zapi result notification
message; update the existing clients so they decode the id.
Signed-off-by: Mark Stapp <mjs@labn.net>
When interface addresses change, we examine nhgs associated
with the interface in case they need to be reinstalled. As
part of that, we may need to reinstall ecmp nhgs that use the
interface being examined - but not always.
Signed-off-by: Mark Stapp <mjs@labn.net>
