bgpd: backpressure - Improve debuggability

Improve debuggability in backpressure code.

Ticket :#3980988

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 186db96c06e4f44b4450fcba88f0fa680ee0b92d)

bgpd: backpressure - fix to properly remove dest for bgp under deletion

In case of imported routes (L3vni/vrf leaks), when a bgp instance is
being deleted, the peer->bgp comparision with the incoming bgp to remove
the dest from the pending fifo is wrong. This can lead to the fifo
having stale entries resulting in crash.

Two changes are done here.
 - Instead of pop/push items in list if the struct bgp doesnt match,
   simply iterate the list and remove the expected ones.

 - Corrected the way bgp is fetched from dest rather than relying on
   path_info->peer so that it works for all kinds of routes.

Ticket :#3980988

Signed-off-by: Chirag Shah <chirag @nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 4395fcd8e120958a91d3a11f918e9071b1cb5619)

Merge pull request #16387 from FRRouting/mergify/bp/dev/10.1/pr-16373

staticd: fix missing static routes (backport #16373)

zebra: fix missing static routes

Use `vtysh` with this input file:
```
ip route A nh1
ip route A nh2
ip route B nh1
ip route B nh2
```

When running "ip route B" with "nh1" and "nh2", the procedure maybe is:
1) Create the two nexthops: "nh1" and "nh2".
2) Register "nh1" with `static_zebra_nht_register()`, then the states of both
   "nh1" and "nht2" are set to "STATIC_SENT_TO_ZEBRA".
3) Register "nh2" with `static_zebra_nht_register()`, then only the routes with
   nexthop of "STATIC_START" will be sent to zebra.

So, send the routes with the nexthop of "STATIC_SENT_TO_ZEBRA" to zebra.

Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit 4518d386f7683289b079708fcdb0c42ced4754d9)

Merge pull request #16378 from FRRouting/mergify/bp/dev/10.1/pr-16363

tests: tweak timers to avoid frequent failures on slow CI hardware (backport #16363)

tests: tweak timers to avoid frequent failures on slow CI hardware

Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
(cherry picked from commit ad7a1f9487edc75fbfaf932e929a008c8bcbc4f9)

Merge pull request #16335 from FRRouting/mergify/bp/dev/10.1/pr-16226

ldpd: fix wrong gtsm count (backport #16226)

Merge pull request #16328 from FRRouting/mergify/bp/dev/10.1/pr-16303

isisd: fix crash when obtaining the next hop to calculate LFA on LAN links (backport #16303)

ldpd: fix wrong gtsm count

In linux networking stack, the received mpls packets will be processed
by the host *twice*, one as mpls packet, the other as ip packet, so
its ttl decreased 1.

So, we need release the `IP_MINTTL` value if gtsm is enabled, it is for the
mpls packets of neighbor session caused by the command:
`label local advertise explicit-null`.

This change makes the gtsm mechanism a bit deviation.

Fix PR #8313

Signed-off-by: anlan_cs <vic.lan@pica8.com>
(cherry picked from commit 1919df3a64d3fe6d4084c1d0b050b3e368860170)

isisd: fix crash when obtaining the next hop to calculate LFA on LAN links

When a neighbor connection is disconnected, it may trigger LSP re-generation as a timer task, but this process may be delayed. As a result, the list of neighbors in area->adjacency_list may be inconsistent with the neighbors in lsp->tlvs->oldstyle_reach/extended_reach. For example, the area->adjacency_list may lack certain neighbors even though they are present in the LSP. When computing SPF, the call to isis_spf_build_adj_list() generates the spftree->sadj_list, which reflects the real neighbors in the area->adjacency_list. However, in the case of LAN links, spftree->sadj_list may include additional pseudo neighbors.
The pre-loading of tents through the call to isis_spf_preload_tent involves two steps:
1. isis_spf_process_lsp() is called to generate real neighbor vertices based on the root LSP and pseudo LSP.
2. isis_spf_add_local() is called to add corresponding next hops to the vertex->Adj_N list for the real neighbor vertices.
In the case of LAN links, the absence of corresponding real neighbors in the spftree->sadj_list prevents the execution of the second step. Consequently, the vertex->Adj_N list for the real neighbor vertices lacks corresponding next hops. This leads to a null pointer access when isis_lfa_compute() is called to calculate LFA.
As for P2P links, since there are no pseudo neighbors, only the second step is executed, which does not create real neighbor vertices and therefore does not encounter this issue.
The backtrace is as follows:
(gdb) bt
#0  0x00007fd065277fe1 in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007fd065398972 in core_handler (signo=11, siginfo=0x7ffc5c0636b0, context=0x7ffc5c063580) at ../lib/sigevent.c:261
#2  <signal handler called>
#3  0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134
#4  0x00005564d82f8d78 in isis_spf_run_lfa (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_lfa.c:2344
#5  0x00005564d8315964 in isis_run_spf_with_protection (area=0x5564d8b143f0, spftree=0x5564d8b06bf0) at ../isisd/isis_spf.c:1827
#6  0x00005564d8315c15 in isis_run_spf_cb (thread=0x7ffc5c064590) at ../isisd/isis_spf.c:1889
#7  0x00007fd0653b1f04 in thread_call (thread=0x7ffc5c064590) at ../lib/thread.c:1990
#8  0x00007fd06534a97b in frr_run (master=0x5564d88103c0) at ../lib/libfrr.c:1198
#9  0x00005564d82e7d5d in main (argc=5, argv=0x7ffc5c0647b8, envp=0x7ffc5c0647e8) at ../isisd/isis_main.c:273
(gdb) f 3
#3  0x00005564d82f8408 in isis_lfa_compute (area=0x5564d8b143f0, circuit=0x5564d8b21d10, spftree=0x5564d8b06bf0, resource=0x7ffc5c064410) at ../isisd/isis_lfa.c:2134
2134    ../isisd/isis_lfa.c: No such file or directory.
(gdb) p vadj_primary
$1 = (struct isis_vertex_adj *) 0x0
(gdb) p vertex->Adj_N->head
$2 = (struct listnode *) 0x0
(gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->data
$8 = (struct isis_vertex *) 0x5564d8b5b240
(gdb) p $8->type
$9 = VTYPE_NONPSEUDO_TE_IS
(gdb) p $8->N.id
$10 = "\000\000\000\000\000\002"
(gdb) p $8->Adj_N->count
$11 = 0
(gdb) p (struct isis_vertex *)spftree->paths->l.list->head->next->next->next->next->next->data
$12 = (struct isis_vertex *) 0x5564d8b73dd0
(gdb) p $12->type
$13 = VTYPE_NONPSEUDO_TE_IS
(gdb) p $12->N.id
$14 = "\000\000\000\000\000\003"
(gdb) p $12->Adj_N->count
$15 = 0
(gdb) p area->adjacency_list->count
$16 = 0
The backtrace provided above pertains to version 8.5.4, but it seems that the same issue exists in the code of the master branch as well.
The scenario where a vertex has no next hop is normal. For example, the "clear isis neighbor" command invokes isis_vertex_adj_del() to delete the next hop of a vertex. Upon reviewing all the instances where the vertex->Adj_N list is used, I found that only isis_lfa_compute() lacks a null check. Therefore, I believe that modifying this part will be sufficient. Additionally, the vertex->parents list for IP vertices is guaranteed not to be empty.
Test scenario:
Setting up LFA for LAN links and executing the "clear isis neighbor" command easily reproduces the issue.

Signed-off-by: zhou-run <zhou.run@h3c.com>
(cherry picked from commit a970bb51b5fe32335c783860a03bb02ce74a49aa)

Merge pull request #16312 from FRRouting/mergify/bp/dev/10.1/pr-16305

bgpd: Ignore RFC8212 for BGP Confederations (backport #16305)

Merge pull request #16318 from FRRouting/mergify/bp/dev/10.1/pr-16233

ripd/ripd.c - rip_auth_md5 : Change the start value of sequence 1 to 0 (backport #16233)

ripd: Change the start value of sequence 1 to 0

Signed-off-by: T-Nicolas <github@toselli.email>
(cherry picked from commit 1a64fe4254759245a67fb279d67478922e00255e)

tests: Test if RFC 8212 is not involved for BGP confederations

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit dd6a679e3a0e9415827643942bcc103c48a89adb)

bgpd: Ignore RFC8212 for BGP Confederations

RFC 8212 should be restricted for eBGP peers.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit fa2cc09d45d3f843564f7bd1e02346373c5741a8)

Merge pull request #16306 from FRRouting/mergify/bp/dev/10.1/pr-16068

bgpd: Ignore routes from evpn if VRF is unknown (backport #16068)

bgpd: Ignore routes from evpn if VRF is unknown

Fix for a bug, where FRR fails to install route received for an unknown but later-created VRF - detailed description can be found here https://github.com/FRRouting/frr/issues/13708

Signed-off-by: Piotr Suchy <psuchy@akamai.com>
(cherry picked from commit 8044d733009dd428c291460eb8b0e539b53b78fa)

Merge pull request #16302 from FRRouting/mergify/bp/dev/10.1/pr-16271

bgpd: avoid clearing routes for peers that were never established (backport #16271)

bgpd: avoid clearing routes for peers that were never established

Under heavy system load with many peers in passive mode and a large
number of routes, bgpd can enter an infinite loop. This occurs while
processing timeout BGP_OPEN messages, which prevents it from accepting
new connections. The following log entries illustrate the issue:
>bgpd[6151]: [VX6SM-8YE5W][EC 33554460] 3.3.2.224: nexthop_set failed, resetting connection - intf 0x0
>bgpd[6151]: [P790V-THJKS][EC 100663299] bgp_open_receive: bgp_getsockname() failed for peer: 3.3.2.224
>bgpd[6151]: [HTQD2-0R1WR][EC 33554451] bgp_process_packet: BGP OPEN receipt failed for peer: 3.3.2.224
... repeating

The issue occurs when bgpd handles a massive number of routes in the RIB
while receiving numerous BGP_OPEN packets. If bgpd is overloaded, it
fails to process these packets promptly, leading the remote peer to
close the connection and resend BGP_OPEN packets.

When bgpd eventually starts processing these timeout BGP_OPEN packets,
it finds the TCP connection closed by the remote peer, resulting in
"bgp_stop()" being called. For each timeout peer, bgpd must iterate
through the routing table, which is time-consuming and causes new
incoming BGP_OPEN packets to timeout, perpetuating the infinite loop.

To address this issue, the code is modified to check if the peer has
been established at least once before calling "bgp_clear_route_all()".
This ensures that routes are only cleared for peers that had a
successful session, preventing unnecessary iterations over the routing
table for peers that never established a connection.

With this change, BGP_OPEN timeout messages may still occur, but in the
worst case, bgpd will stabilize. Before this patch, bgpd could enter a
loop where it was unable to accpet any new connections.

Signed-off-by: Loïc Sang <loic.sang@6wind.com>
(cherry picked from commit e0ae285eb8beeef7b43bdadc073d8ae346eaeb6c)

Merge pull request #16285 from FRRouting/mergify/bp/dev/10.1/pr-15838

 bgpd: fix "bgp as-pah access-list" with "set aspath exclude" set/unset issue (backport #15838)

Merge pull request #16284 from FRRouting/mergify/bp/dev/10.1/pr-16261

zebra: clear evpn dup-addr return error-msg when there is no vni (backport #16261)

Merge pull request #16291 from FRRouting/mergify/bp/dev/10.1/pr-16214

bgpd: A couple more fixes for Tunnel encapsulation handling (backport #16214)

Merge pull request #16289 from FRRouting/mergify/bp/dev/10.1/pr-16273

bgpd: Relax OAD (One-Administration-Domain) for RFC8212 (backport #16273)

bgpd: Check if we have real stream data for tunnel encapsulation sub-tlvs

When the packet is malformed it can use whatever values it wants. Let's check
what the real data we have in a stream instead of relying on malformed values.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 9929486d6bdb28469a5b626a17d5bc9991c83ce3)

bgpd: Adjust the length of tunnel encap sub-tlv by sub-tlv type

Fixes: 79563af564ad0fe5b9c8d95bf080d570f87b1859 ("bgpd: Get 1 or 2 octets for Sub-TLV length (Tunnel Encap attr)")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 34b209f0ae2caca0d1ebcde9d4095375ac31b562)

bgpd: Relax OAD (One-Administration-Domain) for RFC8212

RFC 8212 defines leak prevention for eBGP peers, but BGP-OAD defines a new
peering type One Administrative Domain (OAD), where multiple ASNs could be used
inside a single administrative domain. OAD allows sending non-transitive attributes,
so this prevention should be relaxed too.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 3b98ddf5018cf7526b50c15018cbaf71a38fa752)

Merge pull request #16281 from FRRouting/mergify/bp/dev/10.1/pr-16213

bgpd: Check if we have really enough data before doing memcpy for FQDN capability (backport #16213)

Merge pull request #16278 from FRRouting/mergify/bp/dev/10.1/pr-16211

bgpd: Check if we have really enough data before doing memcpy for software version (backport #16211)

Merge pull request #16239 from FRRouting/mergify/bp/dev/10.1/pr-16224

zebra: Prevent starvation in dplane_thread_loop (backport #16224)

Merge pull request #16274 from FRRouting/mergify/bp/dev/10.1/pr-16242

bgpd: Set last reset reason to admin shutdown if it was manually (backport #16242)

tests: improve tests for aspath exclude and bgp access list

add some match in route map rules
add some set unset bgp access path list
add another prefix for better tests discrimination
update expected results

Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit 0df2e149970beff39915d0095614d56d5859f3ff)

bgpd: fix "bgp as-pah access-list" with "set aspath exclude" set/unset issues

whith the following config

router bgp 65001
 no bgp ebgp-requires-policy
 neighbor 192.168.1.2 remote-as external
 neighbor 192.168.1.2 timers 3 10
 !
 address-family ipv4 unicast
  neighbor 192.168.1.2 route-map r2 in
 exit-address-family
exit
!
bgp as-path access-list FIRST seq 5 permit ^65
bgp as-path access-list SECOND seq 5 permit 2$
!
route-map r2 permit 6
 match ip address prefix-list p2
 set as-path exclude as-path-access-list SECOND
exit
!
route-map r2 permit 10
 match ip address prefix-list p1
 set as-path exclude 65003
exit
!
route-map r2 permit 20
 match ip address prefix-list p3
 set as-path exclude all
exit

making some
no bgp as-path access-list SECOND permit 2$
bgp as-path access-list SECOND permit 3$

clear bgp *

no bgp as-path access-list SECOND permit 3$
bgp as-path access-list SECOND permit 2$

clear bgp *

will induce some crashes

thus  we rework the links between aslists and aspath_exclude

Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
(cherry picked from commit 094dcc3cdac19d3da65b38effc45aa88d960909f)

zebra: clear evpn dup-addr return error-msg when there is no vni

clear evpn dup-addr cli returns error-msg for below conditions,

 - If evpn is not enabled &
 - If there is no VNI exists.

supported command:

```
clear evpn dup-addr vni <vni-id>
```

Ticket: #3495573

Testing:

bharat# clear evpn dup-addr vni all
Error type: validation
Error description: % EVPN not enabled

bharat# clear evpn dup-addr vni 20
Error type: validation
Error description: % VNI 20 does not exist

Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit 56c16ee529b546058c8d1fabbb701d8ed2fded75)

bgpd: Check if we have really enough data before doing memcpy for FQDN capability

We advance data pointer (data++), but we do memcpy() with the length that is 1-byte
over, which is technically heap overflow.

```
==411461==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50600011da1a at pc 0xc4f45a9786f0 bp 0xffffed1e2740 sp 0xffffed1e1f30
READ of size 4 at 0x50600011da1a thread T0
    0 0xc4f45a9786ec in __asan_memcpy (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x3586ec) (BuildId: e794c5f796eee20c8973d7efb9bf5735e54d44cd)
    1 0xc4f45abf15f8 in bgp_dynamic_capability_fqdn /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3457:4
    2 0xc4f45abdd408 in bgp_capability_msg_parse /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3911:4
    3 0xc4f45abdbeb4 in bgp_capability_receive /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3980:9
    4 0xc4f45abde2cc in bgp_process_packet /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:4109:11
    5 0xc4f45a9b6110 in LLVMFuzzerTestOneInput /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_main.c:582:3
```

Found by fuzzing.

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b685ab5e1bdec0848502c20e9596b9716b236639)

bgpd: Check if we have really enough data before doing memcpy for software version

If we receive CAPABILITY message (software-version), we SHOULD check if we really
have enough data before doing memcpy(), that could also lead to buffer overflow.

(data + len > end) is not enough, because after this check we do data++ and later
memcpy(..., data, len). That means we have one more byte.

Hit this through fuzzing by

```
    0 0xaaaaaadf872c in __asan_memcpy (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x35872c) (BuildId: 9c6e455d0d9a20f5a4d2f035b443f50add9564d7)
    1 0xaaaaab06bfbc in bgp_dynamic_capability_software_version /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3713:3
    2 0xaaaaab05ccb4 in bgp_capability_msg_parse /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3839:4
    3 0xaaaaab05c074 in bgp_capability_receive /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:3980:9
    4 0xaaaaab05e48c in bgp_process_packet /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:4109:11
    5 0xaaaaaae36150 in LLVMFuzzerTestOneInput /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_main.c:582:3
```

Hit this again by Iggy \m/

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 5d7af51c4f7980507135babd94d392ca179c1bf7)

bgpd: Remove redundant whitespace before printing the reason of the failed peer

Before:

```
Neighbor        EstdCnt DropCnt ResetTime Reason
127.0.0.1             0       0     never  Waiting for peer OPEN (n/a)
```

After:

```
Neighbor        EstdCnt DropCnt ResetTime Reason
127.0.0.1             0       0     never Waiting for peer OPEN (n/a)
```

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b5bd626a82b2541bee8e3120139e19ba05e444c8)

bgpd: Set last reset reason to admin shutdown if it was manually

Before this patch, we always printed the last reason "Waiting for OPEN", but
if it's a manual shutdown, then we technically are not waiting for OPEN.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c25c7e929d550c2faca3af74a29593b8c0b75db3)

Merge pull request #16255 from FRRouting/mergify/bp/dev/10.1/pr-16059

bgpd: fixed failing to remove VRF if there is a stale l3vni (backport #16059)

Merge pull request #16264 from FRRouting/mergify/bp/dev/10.1/pr-16252

zebra: fix evpn mh bond member proto reinstall (backport #16252)

Merge pull request #16262 from FRRouting/mergify/bp/dev/10.1/pr-16260

bgpd: fix do not use api.backup_nexthop in ZAPI message (backport #16260)

zebra: fix evpn mh bond member proto reinstall

In case of EVPN MH bond, a member port going in
protodown state due to external reason (one case being linkflap),
frr updates the state correctly but upon manually
clearing external reason trigger FRR to reinstate
protodown without any reason code.

Fix is to ensure if the protodown reason was external
and new state is to have protodown 'off' then do no reinstate
protodown.

Ticket: #3947432
Testing:
switch:#ip link show swp1
4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
   pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
   1000
       link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff protodown on
       protodown_reason <linkflap>

switch:#ip link set swp1 protodown off protodown_reason linkflap off
switch:#ip link show swp1
 4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
    pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
    1000
        link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff

Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit e4d843b438ae7cbae89ae47af0754fb1db153c6c)

bgpd: fix do not use api.backup_nexthop in ZAPI message

The backup_nexthop entry list has been populated by mistake,
and should not. Fix this by reverting the introduced behavior.

Fixes: 237ebf8d4503 ("bgpd: rework bgp_zebra_announce() function, separate nexthop handling")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit d4390fc21795b09b84a6b95b1f8fa1ac2b3dcda9)

bgpd: fixed failing remove of vrf if there is a stale l3vni

Problem statement:
==================
When a vrf is deleted from the kernel, before its removed from the FRR
config, zebra gets to delete the the vrf and assiciated state.

It does so by sending a request to delete the l3 vni associated with the
vrf followed by a request to delete the vrf itself.

2023/10/06 06:22:18 ZEBRA: [JAESH-BABB8] Send L3_VNI_DEL 1001 VRF
testVRF1001 to bgp
2023/10/06 06:22:18 ZEBRA: [XC3P3-1DG4D] MESSAGE: ZEBRA_VRF_DELETE
testVRF1001

The zebra client communication is asynchronous and about 1/5 cases the
bgp client process them in a different order.

2023/10/06 06:22:18 BGP: [VP18N-HB5R6] VRF testVRF1001(766) is to be
deleted.
2023/10/06 06:22:18 BGP: [RH4KQ-X3CYT] VRF testVRF1001(766) is to be
disabled.
2023/10/06 06:22:18 BGP: [X8ZE0-9TS5H] VRF disable testVRF1001 id 766
2023/10/06 06:22:18 BGP: [X67AQ-923PR] Deregistering VRF 766
2023/10/06 06:22:18 BGP: [K52W0-YZ4T8] VRF Deletion:
testVRF1001(4294967295)
.. and a bit later :
2023/10/06 06:22:18 BGP: [MRXGD-9MHNX] DJERNAES: process L3VNI 1001 DEL
2023/10/06 06:22:18 BGP: [NCEPE-BKB1G][EC 33554467] Cannot process L3VNI
1001 Del - Could not find BGP instance

When the bgp vrf config is removed later it fails on the sanity check if
l3vni is removed.

        if (bgp->l3vni) {
            vty_out(vty, "%% Please unconfigure l3vni %u\n",
                bgp->l3vni);
            return CMD_WARNING_CONFIG_FAILED;
        }

Solution:
=========
The solution is to make bgp cleanup the l3vni a bgp instance is going
down.

The fix:
========
The fix is to add a function in bgp_evpn.c to be responsible for for
deleting the local vni, if it should be needed, and call the function
from bgp_instance_down().

Testing:
========
Created a test, which can run in container lab that remove the vrf on
the host before removing the vrf and the bgp config form frr. Running
this test in a loop trigger the problem 18 times of 100 runs. After the
fix it did not fail.

To verify the fix a log message (which is not in the code any longer)
were used when we had a stale l3vni and needed to call
bgp_evpn_local_l3vni_del() to do the cleanup. This were hit 20 times in
100 test runs.

Signed-off-by: Kacper Kwasny <kkwasny@akamai.com>
bgpd: braces {} are not necessary for single line block

Signed-off-by: Kacper Kwasny <kkwasny@akamai.com>
(cherry picked from commit 171d2583d0373b456335477dea6688d2e9e95db7)

zebra: Prevent starvation in dplane_thread_loop

When removing a large number of routes, the linux kernel can take the
cpu for an extended amount of time, leaving a situation where FRR
detects a starvation event.

r1# sharp install routes 10.0.0.0 nexthop 192.168.44.33 1000000 repeat 10
2024-06-14 12:55:49.365 [NTFY] sharpd: [M7Q4P-46WDR] vty[5]@# sharp install routes 10.0.0.0 nexthop 192.168.44.33 1000000 repeat 10
2024-06-14 12:55:49.365 [DEBG] sharpd: [YP4TQ-01TYK] Inserting 1000000 routes
2024-06-14 12:55:57.256 [DEBG] sharpd: [TPHKD-3NYSB] Installed All Items 7.890085
2024-06-14 12:55:57.256 [DEBG] sharpd: [YJ486-NX5R1] Removing 1000000 routes
2024-06-14 12:56:07.802 [WARN] zebra: [QH9AB-Y4XMZ][EC 100663314] STARVATION: task dplane_thread_loop (634377bc8f9e) ran for 7078ms (cpu time 220ms)
2024-06-14 12:56:25.039 [DEBG] sharpd: [WTN53-GK9Y5] Removed all Items 27.783668
2024-06-14 12:56:25.039 [DEBG] sharpd: [YP4TQ-01TYK] Inserting 1000000 routes
2024-06-14 12:56:32.783 [DEBG] sharpd: [TPHKD-3NYSB] Installed All Items 7.743524
2024-06-14 12:56:32.783 [DEBG] sharpd: [YJ486-NX5R1] Removing 1000000 routes
2024-06-14 12:56:41.447 [WARN] zebra: [QH9AB-Y4XMZ][EC 100663314] STARVATION: task dplane_thread_loop (634377bc8f9e) ran for 5175ms (cpu time 179ms)

Let's modify the loop in dplane_thread_loop such that after a provider
has been run, check to see if the event should yield, if so, stop
and reschedule this for the future.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 6faad863f30d29157e4c675ad956e3ccd38991a7)

Merge pull request #16210 from LabNConsulting/chopps/fix-bug

lib: fix incorrect use of error checking macro

lib: fix incorrect use of error checking macro

Signed-off-by: Christian Hopps <chopps@labn.net>

Merge pull request #16191 from pguibert6WIND/srte_color_not_copied

lib: fix copy srte_color from zapi_nexthop structure

Merge pull request #16190 from trots/master

doc: Add reloading script into Python dependency section

Merge pull request #16050 from rgirada/ospfv3_helper

ospf6d: Handling Topo Change in GR-HELPER mode for max-age lsas

doc: Add reloading script into Python dependency section

Signed-off-by: Alexander Trotsenko <trotsenko93@mail.ru>

Merge pull request #16193 from opensourcerouting/fix/ecommunity_linkbw_present_overrun

bgpd: Check against extended community unit size for link bandwidth

Merge pull request #16187 from opensourcerouting/isis_tilfa_topo_rework

isis_tilfa_topo1 rework

bgpd: Check against extended community unit size for link bandwidth

If we receive a malformed packets, this could lead ptr_get_be64() reading
the packets more than needed (heap overflow).

```
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
    0 0xaaaaaadf86ec in __asan_memcpy (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x3586ec) (BuildId: 78123cd26ada92b8b59fc0d74d292ba70c9d2e01)
    1 0xaaaaaaeb60fc in ptr_get_be64 /home/ubuntu/frr-public/frr_public_private-libfuzzer/./lib/stream.h:377:2
    2 0xaaaaaaeb5b90 in ecommunity_linkbw_present /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_ecommunity.c:1895:10
    3 0xaaaaaae50f30 in bgp_attr_ext_communities /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:2639:8
    4 0xaaaaaae49d58 in bgp_attr_parse /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:3776:10
    5 0xaaaaab063260 in bgp_update_receive /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:2371:20
    6 0xaaaaab05df00 in bgp_process_packet /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:4063:11
    7 0xaaaaaae36110 in LLVMFuzzerTestOneInput /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_main.c:582:3
```

This is triggered when receiving such a packet (malformed):

```
(gdb) bt
0  ecommunity_linkbw_present (ecom=0x555556287990, bw=bw@entry=0x7fffffffda68)
    at bgpd/bgp_ecommunity.c:1802
1  0x000055555564fcac in bgp_attr_ext_communities (args=0x7fffffffd840) at bgpd/bgp_attr.c:2619
2  bgp_attr_parse (peer=peer@entry=0x55555628cdf0, attr=attr@entry=0x7fffffffd960, size=size@entry=20,
    mp_update=mp_update@entry=0x7fffffffd940, mp_withdraw=mp_withdraw@entry=0x7fffffffd950)
    at bgpd/bgp_attr.c:3755
3  0x00005555556aa655 in bgp_update_receive (connection=connection@entry=0x5555562aa030,
    peer=peer@entry=0x55555628cdf0, size=size@entry=41) at bgpd/bgp_packet.c:2324
4  0x00005555556afab7 in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:3897
5  0x00007ffff7ac2f73 in event_call (thread=thread@entry=0x7fffffffdc70) at lib/event.c:2011
6  0x00007ffff7a6fb90 in frr_run (master=0x555555bc7c90) at lib/libfrr.c:1212
7  0x00005555556457e1 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:543
(gdb) p *ecom
$1 = {refcnt = 1, unit_size = 8 '\b', disable_ieee_floating = false, size = 2, val = 0x555556282150 "",
  str = 0x5555562a9c30 "UNK:0, 255 UNK:2, 6"}
```

Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #16183 from LabNConsulting/chopps/notif-doc-update

mgmtd: add empty notif xpath map for completeness

tests: introduce method to update reference data in isis_tilfa_topo1

The isis_tilfa_topo1 topotest is comprehensive and contains a large
amount of reference data. One problem is that, when changes occur,
updating this reference data can be difficult.

To address this problem, this commit introduces a method to
automatically regenerate the reference data by setting the `REGEN_DATA`
environment variable.

Usage:
$ REGEN_DATA=true python3 ./test_isis_tilfa_topo1.py

When `REGEN_DATA` is set, the topotest regenerates reference data
from the current run instead of comparing against existing reference
data. Note that regenerated data must be manually verified for
correctness.

This commit also simplifies the reference data by replacing all diff
files with complete JSON snapshots.

Signed-off-by: Renato Westphal <renato@opensourcerouting.org>

tests: rework isis_tilfa_topo1 to fix timing issues

In this topotest, steps 10-15 were added to test the IS-IS switchover
functionality. In short, two cases were tested: switchover after a
link down event and switchover after a BFD down event. Both cases
were tested in sequence on the same router, rt6. This involved the
following steps:
- Setting the SPF delay timer to 15 seconds
- Shutting down the eth-rt5 interface from the switch side
- Testing the post-switchover RIB and LIB (triggered by the link down
  event)
- Testing the post-SPF RIB and LIB
- Bringing the eth-rt5 interface back up
- Configuring a BFD session between rt6 and rt5
- Shutting down the eth-rt5 interface from the switch side once again
- Testing the post-switchover RIB and LIB (triggered by the BFD down
  event)
- Testing the post-SPF RIB and LIB

Since the time window to test the post-switchover RIB and LIB was too
narrow (10 seconds), these tests were having sporadic failures.

To resolve this problem, we can simplify the switchover test as follows:
- Setting the SPF delay timer to 60 seconds (not 15)
- Disabling "link-detect" on rt6's eth-rt5 interface
- Shutting down the eth-rt5 interface from the switch side
- On rt6, testing the post-switchover RIB and LIB (triggered by the
  BFD down event)
- On rt5, testing the post-switchover RIB and LIB (triggered by the
  link down event)

Notice how we can test both post-link-down and post-BFD-down switchover
cases simultaneously by having different "link-detect" configurations
on rt5 and rt6. Additionally, by using a larger SPF delay timer, the
time window to test the post-switchover RIB and LIB is much larger
and less prone to sporadic failures.

Signed-off-by: Renato Westphal <renato@opensourcerouting.org>

lib: fix copy srte_color from zapi_nexthop structure

When switching from nexthop to zapi_nexthop, the srte color
is copied. Do the same in reverse.

Fixes: 31f937fb43f4 ("lib, zebra: Add SR-TE policy infrastructure to zebra")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

Merge pull request #16093 from louis-6wind/fix-show-route-memory

zebra: fix Out Of Memory issue when displaying large route tables in JSON

Merge pull request #16189 from LabNConsulting/chopps/triage-github-action

ci: do apt-get update before installing required modules

- Use `uname -r` to also install specific module versions since
  with github runners the running kernel can become out-dated with
  the deployed packages.

Signed-off-by: Christian Hopps <chopps@labn.net>

Merge pull request #15900 from mikemallin/v6-vtep-lib-upstream

lib, bgpd, tests, zebra: prefix_sg changes for V6 VTEP

doc: add some text on native message API and notif xpath array

Signed-off-by: Christian Hopps <chopps@labn.net>

mgmtd: add empty notif xpath map for completeness

New back-end clients may need to add notification static allocations so
we should have it available for those users, rather than requiring the
new user delve into the mgmtd infra and modify it themselves.

Signed-off-by: Christian Hopps <chopps@labn.net>

tests: check show route vrf all json output

Check that "show ip route vrf XXX json" and the JSON at key "XXX" of
"show ip route vrf all json" gives the same output.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

zebra: fix show route memory consumption

When displaying a route table in JSON, a table JSON object is storing
all the prefix JSON objects containing the prefix information. This
results in excessive memory allocation for JSON objects, potentially
leading to an out-of-memory error on the machine with large routing
tables.

To Fix the memory consumption issue for the "show ip[v6] route [vrf XX]
json" command, display the prefixes one by one and free the memory of
each JSON object after it has been displayed.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

zebra: fix show route vrf all memory consumption

0e2fc3d67f ("vtysh, zebra: Fix malformed json output for multiple vrfs
in command 'show ip route vrf all json'") has been reverted in the
previous commit. Although the fix was correct, it was consuming too muca
memory when displaying large route tables.

A root JSON object was storing all the JSON objects containing the route
tables, each containing their respective prefixes in JSON objects. This
resulted in excessive memory allocation for JSON objects, potentially
leading to an out-of-memory error on the machine.

To Fix the memory consumption issue for the "show ip[v6] route vrf all
json" command, display the tables one by one and free the memory of each
JSON object after it has been displayed.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

lib: add helpers to print json keys

Add helpers to print json keys in order to prepare the next commits.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

Revert "vtysh, zebra: Fix malformed json output for multiple vrfs in command 'show ip route vrf all json'"

This reverts commit 0e2fc3d67f1d358896a764373f41cb59c095eda9.

This fix was correct but not optimal for memory consumption at scale.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

Merge pull request #16143 from eremcan/patch-1

docker: fix chmod issues when running container for debian

Merge pull request #11906 from louis-6wind/show_isis_db_json

isisd: fix show isis database [detail] json

Merge pull request #15434 from louis-6wind/labels-hash

bgpd: move labels from extra to extra->labels and add them to adj-rib-in and adj-rib-out

Merge pull request #16151 from pguibert6WIND/srv6_fix_source_address

zebra: display srv6 encapsulation source-address when configured

Merge pull request #16171 from mjstapp/fix_fpm_nl_len_check

zebra: fix incoming FPM message length validation

Merge pull request #16176 from LabNConsulting/chopps/munet-version-update

tests: munet: update to version 0.14.9

ospf6d: Handling Topo Change in GR-HELPER mode for max-age lsas

Description:
OSPF6 GR HELPER router should  consider as TOPOCHANGE when
it receives lsas with max age and should exit from Helper.
But, it is not exiting from helper because this max age lsa is
considered as duplicated lsa since the sender uses same seq
number for max age lsa from the previous lsa update.
Currently, topo change is not considered for duplicated lsas.
So removed the duplicated check when validating TOPOCHNAGE.

Signed-off-by: Rajesh Girada <rgirada@vmware.com>

tests: munet: update to version 0.14.9

Topotest relevant changes:

    - add support for `timeout` arg to `cmd_*()`
    - handle invalid regexp in CLI commands
    - fix long interface name support

Full munet changelog:

    munet: 0.14.9: add support for `timeout` arg to `cmd_*()`
    munet: 0.14.8: cleanup the cleanup (kill) on launch options
    munet: 0.14.7: allow multiple extra commands for shell console init
    munet: 0.14.6:
      - qemu: gather gcda files where munet can find them
      - handle invalid regexp in CLI commands
    munet: 0.14.5:
      - (podman) pull missing images for containers
      - fix long interface name support
      - add another router example
    munet: 0.14.4: mutest: add color to PASS/FAIL indicators on tty consoles
    munet: 0.14.3: Add hostnet node that runs it's commands in the host network namespace.
    munet: 0.14.2:
      - always fail mutest tests on bad json inputs
      - improve ssh-remote for common use-case of connecting to host connected devices
      - fix ready-cmd for python v3.11+
    munet: 0.14.1: Improved host interface support.

Signed-off-by: Christian Hopps <chopps@labn.net>

Merge pull request #16170 from LabNConsulting/dleroy/nhrpd-shortcut-cleanup

nhrpd: cleans up shortcut cache entries on termination

zebra: fix incoming FPM message length validation

Validate incoming message length against correct
(struct rtmsg) len, not top-level netlink message header size.

Signed-off-by: Mark Stapp <mjs@cisco.com>

nhrpd: cleans up shortcut cache entries on termination

nhrp_shortcut_terminate() previously was just freeing the associated AFI shortcut
RIBs and not addressing existing shortcut cache entries. This cause a use after
free issue in vrf_terminate() later in the terminate sequence

NHRP: Received signal 7 at 1717516286 (si_addr 0x1955d, PC 0x7098786912c0); aborting...
NHRP: zlog_signal+0xf5                   709878ad1255     7fff3d992eb0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: core_handler+0xb5                  709878b0db85     7fff3d992ff0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: __sigaction+0x50                   709878642520     7fff3d993140 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP:     ---- signal ----
NHRP: __lll_lock_wait_private+0x90       7098786912c0     7fff3d9936d8 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: pthread_mutex_lock+0x112           709878698002     7fff3d9936e0 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: _event_add_read_write+0x63         709878b1f423     7fff3d993700 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: zclient_send_message+0xd4          709878b37614     7fff3d993770 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_route_announce+0x1ad          5ab34d63d39d     7fff3d993790 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_shortcut_cache_notify+0xd8     5ab34d63e758     7fff3d99d4e0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_cache_free+0x165              5ab34d632f25     7fff3d99d510 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: hash_iterate+0x4d                  709878ab949d     7fff3d99d540 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_cache_interface_del+0x37      5ab34d633eb7     7fff3d99d580 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: nhrp_if_delete_hook+0x26           5ab34d6350d6     7fff3d99d5a0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: if_delete_retain+0x3d              709878abcd1d     7fff3d99d5c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: if_delete+0x4c                     709878abd87c     7fff3d99d600 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: if_terminate+0x53                  709878abda83     7fff3d99d630 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: vrf_terminate_single+0x24          709878b23c74     7fff3d99d670 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: nhrp_request_stop+0x34             5ab34d636844     7fff3d99d690 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: frr_sigevent_process+0x53          709878b0df53     7fff3d99d6a0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: event_fetch+0x6c5                  709878b20405     7fff3d99d6c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: frr_run+0xd3                       709878ac8163     7fff3d99d840 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000)
NHRP: main+0x195                         5ab34d631915     7fff3d99d960 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)
NHRP: __libc_init_first+0x90             709878629d90     7fff3d99d980 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: __libc_start_main+0x80             709878629e40     7fff3d99da20 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000)
NHRP: _start+0x25                        5ab34d631b65     7fff3d99da70 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000)

Signed-off-by: Dave LeRoy <dleroy@labn.net>

Merge pull request #16164 from opensourcerouting/fix/doc_clear_bgp_by_asn

doc: Add missing `clear bgp ASNUM` command

Merge pull request #16159 from opensourcerouting/fix/ignore_auto_created_vrf_bgp_instances

bgpd: Ignore auto created VRF BGP instances

Merge pull request #16163 from LabNConsulting/aceelindem/ospfv3-auth-sa-id-checking

 ospf6d: OSPFv3 manual key authentication neglects checking the SA ID.

Merge pull request #16155 from httpstorm/gcc-14-compatibility

zebra: fix compilation with GCC14

bgpd: fix label in adj-rib-out

After modifying the "label vpn export value", the vpn label information
of the VRF is not updated to the peers.

For example, the 192.168.0.0/24 prefix is announced to the peer with a
label value of 222.

> router bgp 65500
> [..]
>  neighbor 192.0.2.2 remote-as 65501
>  address-family ipv4-vpn
>   neighbor 192.0.2.2 activate
>  exit-address-family
> exit
> router bgp 65500 vrf vrf2
>  address-family ipv4 unicast
>   network 192.168.0.0/24
>   label vpn export 222
>   rd vpn export 444:444
>   rt vpn both 53:100
>   export vpn
>   import vpn
>  exit-address-family

Changing the label with "label vpn export" does not update the label
value to the peer unless the BGP sessions is re-established.

No labels are stored are stored struct bgp_adj_out so that it is
impossible to compare the current value with the previous value
in adj-RIB-out.

Reference the bgp_labels pointer in struct bgp_adj_out and compare the
values when updating adj-RIB-out.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: fix labels in adj-rib-in

In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with
'soft-reconfiguration inbound'), after applying a deny route-map and
removing it, the remote MPLS label information is lost. As a result, BGP
is unable to re-install the related routes in the RIB.

For example,

> router bgp 65500
> [..]
>  neighbor 192.0.2.2 remote-as 65501
>  address-family ipv4 vpn
>   neighbor 192.0.2.2 activate
>   neighbor 192.0.2.2 soft-reconfiguration inbound

The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP
RIB.

> # show bgp ipv4 vpn 192.168.0.0/24
>  BGP routing table entry for 444:1:192.168.0.0/24, version 2
>  [..]
>      192.168.0.0 from 192.0.2.2
>        Origin incomplete, metric 0, valid, external, best (First path received)
>        Extended Community: RT:52:100
>        Remote label: 102

A route-map now filter all incoming BGP updates:

> route-map rmap deny 1
> router bgp 65500
>  address-family ipv4 vpn
>   neighbor 192.0.2.2 route-map rmap in

The prefix is now filtered:

> # show bgp ipv4 vpn 192.168.0.0/24
> #

The route-map is detached:

> router bgp 65500
>  address-family ipv4 vpn
>   no neighbor 192.168.0.1 route-map rmap in

The BGP RIB entry is present but the remote label is lost:

> # show bgp ipv4 vpn 192.168.0.0/24
>  BGP routing table entry for 444:1:192.168.0.0/24, version 2
>  [..]
>      192.168.0.0 from 192.0.2.2
>        Origin incomplete, metric 0, valid, external, best (First path received)
>        Extended Community: RT:52:100

The reason for the loose is that labels are stored within struct attr ->
struct extra -> struct bgp_labels but not in the struct bgp_adj_in.

Reference the bgp_labels pointer in struct bgp_adj_in and use its values
when doing a soft reconfiguration of the BGP table.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: get rid of has_valid_label in bgp_update()

Get rid of has_valid_label in bgp_update() to prepare the next commits.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: move labels from extra to extra->labels

Move labels from extra to extra->labels. Labels are now stored in a hash
list.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: add bgp_labels hash

Add bgp_labels type and hash list.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

topotests: add bgp test to check the ADJ-RIB-IN label value

The test is done on r2. A BGP update is received on r2, and is
filtered on r2. The RIB of r2 does not have the BGP update stored,
but the ADJ-RIB-IN is yet present. To demonstrate this, if the
inbound route-map is removed, then the BGP update should be copied
from the the ADJ-RIB-IN and added to the RIB with the label
value.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

topotests: add bgp test to check the ADJ-RIB-OUT label value

This test ensures that when r1 changes the label value, then
the new value is automatically propagated to remote peer.
This demonstrates that the ADJ-RIB-OUT to r2 has been correctly
updated.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

topotests: clarify bgp_vpnv4_ebgp

Clarify bgp_vpnv4_ebgp

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: store number of labels with 8 bits

8 bits are sufficient to store the number of labels because the current
maximum is 2.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: fix too leading tabs in vnc_import_bgp

Small rework to fix the following checkpatch warning:

> < WARNING: Too many leading tabs - consider code refactoring
> < #2142: FILE: /tmp/f1-1616988/vnc_import_bgp.c:2142:

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: add bgp_path_info_num_labels()

Add bgp_path_info_num_labels() to get the number of labels stored in
a path_info structure.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: rework vni printing in route_vty_out_detail()

In route_vty_out_detail(), tag_buf stores a string representation of
the VNI label.

Rename tag_buf to vni_buf for clarity and rework the code a little bit
to prepare the following commits.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: num_labels cannot be greater than BGP_MAX_LABELS

num_labels cannot be greater than BGP_MAX_LABELS by design.

Remove the check and the override.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: add bgp_path_info_labels_same()

Add bgp_path_info_labels_same() to compare labels with labels from
path_info. Remove labels_same() that was used for mplsvpn only.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: optimize label copy for new path_info

In bgp_update(), path_info *new has just been created and has void
labels. bgp_labels_same() is always false.

Do not compare previous labels before setting them.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: do not init labels in extra

No need to init labels at extra allocation. num_labels is the number
of set labels in label[] and is initialized to 0 by default.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

bgpd: add bgp_path_info_has_valid_label()

Add bgp_path_has_valid_label to check that a path_info has a valid
label.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>