lib: crash handlers must be allowed on threads

Blocking all signals on non-main threads is not the way to go, at least
the handlers for SIGSEGV, SIGBUS, SIGILL, SIGABRT and SIGFPE need to run
so we get backtraces.  Otherwise the process just exits.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 13a6ac5b4ca8fc08b348f64de64a787982f24250)

Merge pull request #18036 from opensourcerouting/fix/stabilize_10.1_again

Stabilize 10.1 branch

Revert "bgpd: Do not ignore auto generated VRF instances when deleting"

This reverts commit 0a923af56dbe43fdb4e9184c3525d0537740aef9.

Revert "bgpd: fix duplicate BGP instance created with unified config"

This reverts commit aba588dd09aa098a88ba1355798c0e784e91ebc8.

Revert "bgpd: fix import vrf creates multiple bgp instances"

This reverts commit 8c187fb4f838d8d8a21f8608c3a510136764b122.

Reapply "bgpd: fix duplicate BGP instance created with unified config"

This reverts commit daa68852a2a78acf103e8ae1127953b2870c6772.

Revert "bgpd: fix duplicate BGP instance created with unified config"

This reverts commit 3abd84ef5be1ef56b66f0e7617f8afab6da6c5cc.

Merge pull request #18016 from opensourcerouting/fix/backport_bgpd_10.1

bgpd: Recent failed backports for 10.1

bgpd: fix duplicate BGP instance created with unified config

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a9b636 ("bgpd: Ignore auto created VRF BGP instances")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Revert "bgpd: fix duplicate BGP instance created with unified config"

This reverts commit aba588dd09aa098a88ba1355798c0e784e91ebc8.

bgpd: fix add label support to EVPN AD routes

When peering with an EVPN device from other vendor, FRR acting as route
reflector is not able to read nor transmit the label value.

Actually, EVPN AD routes completely ignore the label value in the code,
whereas in some functionalities like evpn-vpws, it is authorised to
carry and propagate label value.

Fix this by handling the label value.

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

bgpd: Do not start BGP session if BGP identifier is not set

If we have IPv6-only network and no IPv4 addresses at all, then by default
0.0.0.0 is created which is treated as malformed according to RFC 6286.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17995 from FRRouting/mergify/bp/stable/10.1/pr-17991

zebra: fix evpn svd hash avoid double free (backport #17991)

Merge pull request #17998 from FRRouting/mergify/bp/stable/10.1/pr-17992

bgpd: fix route-distinguisher in vrf leak json cmd (backport #17992)

Merge pull request #17984 from opensourcerouting/fix/backports_auto_vrf_10.1

bgpd: Auto vrf instance (backports)

bgpd: fix route-distinguisher in vrf leak json cmd

For auto configured value RD value comes as NULL,
switching back to original change will ensure to cover
for both auto and user configured RD value in JSON.

tor-11# show bgp vrf blue ipv4 unicast route-leak json
{
  "vrf":"blue",
  "afiSafi":"ipv4Unicast",
  "importFromVrfs":[
    "purple"
  ],
  "importRts":"10.10.3.11:6",
  "exportToVrfs":[
    "purple"
  ],
  "routeDistinguisher":"(null)", <<<<<
  "exportRts":"10.10.3.11:10"
}

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

zebra: evpn svd hash avoid double free

Upon zebra shutdown hash_clean_and_free is called
where user free function is passed,
The free function should not call hash_release
which lead to double free of hash bucket.

Fix:
The fix is to avoid calling hash_release from
free function if its called from hash_clean_and_free
path.

10 0x00007f0422b7df1f in free () from /lib/x86_64-linux-gnu/libc.so.6
11 0x00007f0422edd779 in qfree (mt=0x7f0423047ca0 <MTYPE_HASH_BUCKET>,
    ptr=0x55fc8bc81980) at ../lib/memory.c:130
12 0x00007f0422eb97e2 in hash_clean (hash=0x55fc8b979a60,
    free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
    ../lib/hash.c:290
13 0x00007f0422eb98a1 in hash_clean_and_free (hash=0x55fc8a675920
    <svd_nh_table>, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
    ../lib/hash.c:305
14 0x000055fc8a5323a5 in zebra_vxlan_terminate () at
    ../zebra/zebra_vxlan.c:6099
15 0x000055fc8a4c9227 in zebra_router_terminate () at
    ../zebra/zebra_router.c:276
16 0x000055fc8a4413b3 in zebra_finalize (dummy=0x7fffb881c1d0) at
    ../zebra/main.c:269
17 0x00007f0422f44387 in event_call (thread=0x7fffb881c1d0) at
    ../lib/event.c:2011
18 0x00007f0422ecb6fa in frr_run (master=0x55fc8b733cb0) at
    ../lib/libfrr.c:1243
19 0x000055fc8a441987 in main (argc=14, argv=0x7fffb881c4a8) at
    ../zebra/main.c:584

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

bgpd: Do not ignore auto generated VRF instances when deleting

When VRF instance is going to be deleted inside bgp_vrf_disable(), it uses
a helper method that skips auto created VRF instances and that leads to STALE
issue.

When creating a VNI for a particular VRF vrfX with e.g. `advertise-all-vni`,
auto VRF instance is created, and then we do `router bgp ASN vrf vrfX`.

But when we do a reload bgp_vrf_disable() is called, and we miss previously
created auto instance.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

bgpd: fix import vrf creates multiple bgp instances

The more the vrf green is referenced in the import bgp command, the more
there are instances created. The below configuration shows that the vrf
green is referenced twice, and two BGP instances of vrf green are
created.

The below configuration:
> router bgp 99
> [..]
>  import vrf green
> exit
> router bgp 99 vrf blue
> [..]
>  import vrf green
> exit
> router bgp 99 vrf green
> [..]
> exit
>
> r4# show bgp vrfs
> Type  Id     routerId          #PeersCfg  #PeersEstb  Name
>              L3-VNI            RouterMAC              Interface
> DFLT  0      10.0.3.4          0          0           default
>              0                 00:00:00:00:00:00      unknown
>  VRF  5      10.0.40.4         0          0           blue
>              0                 00:00:00:00:00:00      unknown
>  VRF  6      0.0.0.0           0          0           green
>              0                 00:00:00:00:00:00      unknown
>  VRF  6      10.0.94.4         0          0           green
>              0                 00:00:00:00:00:00      unknown

Fix this at import command, by looking at an already present bgp
instance.

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

bgpd: fix duplicate BGP instance created with unified config

When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a9b636 ("bgpd: Ignore auto created VRF BGP instances")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17974 from FRRouting/mergify/bp/stable/10.1/pr-17971

bgpd: With suppress-fib-pending ensure withdrawal is sent (backport #17971)

bgpd: With suppress-fib-pending ensure withdrawal is sent

When you have suppress-fib-pending turned on it is possible
to end up in a situation where the prefix is not withdrawn
from downstream peers.

Here is the timing that I believe is happening:

a) have 2 paths to a peer.
b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING
   and send the route install to zebra.
c) receive a withdrawal from the other path.
d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING
   old_select the path_info going away, new_select is NULL
e) A bit further down we call group_announce_route() which calls
   the code to see if we should advertise the path.  It sees the
   BGP_NODE_FIB_INSTALL_PENDING flag and says, nope.
f) the route is sent to zebra to withdraw, which unsets the
   BGP_NODE_FIB_INSTALL_PENDING.
g) This function winds up and deletes the path_info.  Dest now
   has no path infos.
h) BGP receives the route install(from step b) and unsets the
   BGP_NODE_FIB_INSTALL_PENDING flag
i) BGP receives the route removed from zebra (from step f) and
   unsets the flag again.

We know if there is no new_select, let's go ahead and just
unset the PENDING flag to allow the withdrawal to go out
at the time when the second withdrawal is received.

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

Merge pull request #17950 from FRRouting/mergify/bp/stable/10.1/pr-17946

tools: Fix frr-reload for ebgp-multihop TTL reconfiguration. (backport #17946)

tools: Fix frr-reload for ebgp-multihop TTL reconfiguration.

In ebgp-multihop, there is a difference in reload behavior when TTL is
unspecified (meaning default 255) and when 255 is explicitly specified.
For example, when reloading with 'neighbor <neighbor> ebgp-multihop
255' in the config, the following difference is created. This commit
fixes that.

    Lines To Delete
    ===============
    router bgp 65001
     no neighbor 10.0.0.4 ebgp-multihop
    exit

    Lines To Add
    ============
    router bgp 65001
     neighbor 10.0.0.4 ebgp-multihop 255
    exit

The commit 767aaa3a8048 is not sufficient and frr-reload needs to be
fixed to handle both unspecified and specified cases.

Signed-off-by: Nobuhiro MIKI <nob@bobuhiro11.net>
(cherry picked from commit 594e917656da5502b302309aed3cf596df24713f)

Merge pull request #17939 from opensourcerouting/fix/revert_4338e21aa2feba57ea7004c36362e5d8186340b8_10.1

Revert "bgpd: Handle Addpath capability using dynamic capabilities" (backport)

Revert "bgpd: Handle Addpath capability using dynamic capabilities"

This reverts commit 05cf9d03b345393b8d63ffe9345c42debd8362b6.

TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically.

When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID,
and at the same time the receiver sends AddPath capability "disable-addpath-rx"
(flag update) via dynamic capabilities, both peers are out of sync about the
AddPath state. The receiver thinks already he's not AddPath-capable anymore,
hence it tries to parse NLRIs as non-AddPath, while they are actually encoded
as AddPath.

AddPath capability itself does not provide (in RFC) any mechanism on backward
compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath).

This explains why we have failures in our CI periodically.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17923 from donaldsharp/backport_17229_some_to_10_1

Backport 17229 some to 10 1

bgpd: Fix wrong pthread event cancelling

0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44
1  __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78
2  __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
3  0x000076e399e42476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
4  0x000076e39a34f950 in core_handler (signo=6, siginfo=0x76e3985fca30, context=0x76e3985fc900) at lib/sigevent.c:258
5  <signal handler called>
6  __pthread_kill_implementation (no_tid=0, signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:44
7  __pthread_kill_internal (signo=6, threadid=130719886083648) at ./nptl/pthread_kill.c:78
8  __GI___pthread_kill (threadid=130719886083648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
9  0x000076e399e42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
10 0x000076e399e287f3 in __GI_abort () at ./stdlib/abort.c:79
11 0x000076e39a39874b in _zlog_assert_failed (xref=0x76e39a46cca0 <_xref.27>, extra=0x0) at lib/zlog.c:789
12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428
13 0x000076e39a369ef6 in event_cancel_event_ready (m=0x5eda32df5e40, arg=0x5eda33afeed0) at lib/event.c:1470
14 0x00005eda0a94a5b3 in bgp_stop (connection=0x5eda33afeed0) at bgpd/bgp_fsm.c:1355
15 0x00005eda0a94b4ae in bgp_stop_with_notify (connection=0x5eda33afeed0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1610
16 0x00005eda0a979498 in bgp_packet_add (connection=0x5eda33afeed0, peer=0x5eda33b11800, s=0x76e3880daf90) at bgpd/bgp_packet.c:152
17 0x00005eda0a97a80f in bgp_keepalive_send (peer=0x5eda33b11800) at bgpd/bgp_packet.c:639
18 0x00005eda0a9511fd in peer_process (hb=0x5eda33c9ab80, arg=0x76e3985ffaf0) at bgpd/bgp_keepalives.c:111
19 0x000076e39a2cd8e6 in hash_iterate (hash=0x76e388000be0, func=0x5eda0a95105e <peer_process>, arg=0x76e3985ffaf0) at lib/hash.c:252
20 0x00005eda0a951679 in bgp_keepalives_start (arg=0x5eda3306af80) at bgpd/bgp_keepalives.c:214
21 0x000076e39a2c9932 in frr_pthread_inner (arg=0x5eda3306af80) at lib/frr_pthread.c:180
22 0x000076e399e94ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
23 0x000076e399f26850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) f 12
12 0x000076e39a369dde in cancel_event_helper (m=0x5eda32df5e40, arg=0x5eda33afeed0, flags=1) at lib/event.c:1428
1428 assert(m->owner == pthread_self());

In this decode the attempt to cancel the connection's events from
the wrong thread is causing the crash.  Modify the code to create an
event on the bm->master to cancel the events for the connection.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

bgpd: Fix deadlock in bgp_keepalive and master pthreads

(gdb) bt
0  futex_wait (private=0, expected=2, futex_word=0x5c438e9a98d8) at ../sysdeps/nptl/futex-internal.h:146
1  __GI___lll_lock_wait (futex=futex@entry=0x5c438e9a98d8, private=0) at ./nptl/lowlevellock.c:49
2  0x00007af16d698002 in lll_mutex_lock_optimized (mutex=0x5c438e9a98d8) at ./nptl/pthread_mutex_lock.c:48
3  ___pthread_mutex_lock (mutex=0x5c438e9a98d8) at ./nptl/pthread_mutex_lock.c:93
4  0x00005c4369c17e70 in _frr_mtx_lock (mutex=0x5c438e9a98d8, func=0x5c4369dc2750 <__func__.265> "bgp_notify_send_internal") at ./lib/frr_pthread.h:258
5  0x00005c4369c1a07a in bgp_notify_send_internal (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000', data=0x0, datalen=0, use_curr=true) at bgpd/bgp_packet.c:928
6  0x00005c4369c1a707 in bgp_notify_send (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_packet.c:1069
7  0x00005c4369bea422 in bgp_stop_with_notify (connection=0x5c438e9a98c0, code=8 '\b', sub_code=0 '\000') at bgpd/bgp_fsm.c:1597
8  0x00005c4369c18480 in bgp_packet_add (connection=0x5c438e9a98c0, peer=0x5c438e9b6010, s=0x7af15c06bf70) at bgpd/bgp_packet.c:151
9  0x00005c4369c19816 in bgp_keepalive_send (peer=0x5c438e9b6010) at bgpd/bgp_packet.c:639
10 0x00005c4369bf01fd in peer_process (hb=0x5c438ed05520, arg=0x7af16bdffaf0) at bgpd/bgp_keepalives.c:111
11 0x00007af16dacd8e6 in hash_iterate (hash=0x7af15c000be0, func=0x5c4369bf005e <peer_process>, arg=0x7af16bdffaf0) at lib/hash.c:252
12 0x00005c4369bf0679 in bgp_keepalives_start (arg=0x5c438e0db110) at bgpd/bgp_keepalives.c:214
13 0x00007af16dac9932 in frr_pthread_inner (arg=0x5c438e0db110) at lib/frr_pthread.c:180
14 0x00007af16d694ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
15 0x00007af16d726850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)

The bgp keepalive pthread gets deadlocked with itself and consequently
the bgp master pthread gets locked when it attempts to lock
the peerhash_mtx, since it is also locked by the keepalive_pthread

The keepalive pthread is locking the peerhash_mtx in
bgp_keepalives_start.  Next the connection->io_mtx mutex in
bgp_keepalives_send is locked and then when it notices a problem it invokes
bgp_stop_with_notify which relocks the same mutex ( and of course
the relock causes it to get stuck on itself ).  This generates a
deadlock condition.

Modify the code to only hold the connection->io_mtx as short as
possible.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>

Merge pull request #17892 from FRRouting/mergify/bp/stable/10.1/pr-17888

bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' table (backport #17888)

bgpd: Fix for local interface MAC cache issue in 'bgp mac hash' table

Issue:
During FRR restart, we fail to add some of the local interface's MAC
to the 'bgp mac hash'. Not having local MAC in the hash table can cause
lookup issues while receiving EVPN RT-2.

Currently, we have code to add local MAC(bgp_mac_add_mac_entry) while handling
interface add/up events in BGP(bgp_ifp_up/bgp_ifp_create). But the code
'bgp_mac_add_mac_entry' in bgp_ifp_create is not getting invoked as it
is placed under a specific check(vrf->bgp link check).

Fix:
We can skip this check 'vrf->bgp link existence' as the tenant VRF might
not have BGP instance but still we want to cache the tenant VRF local
MACs. So keeping this check in bgp_ifp_create inline with bgp_ifp_up.

Ticket: #4204154

Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com>
(cherry picked from commit 016528364e686fb3b23a688707bd6ae6c5ea5f41)

Merge pull request #17851 from FRRouting/mergify/bp/stable/10.1/pr-17832

bgpd: Aggregate backports (backport #17832)

bgpd: fix memory leak in bgp_aggregate_install()

Potential memory leak with as-set and matching-MED-only config.

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 94ca6ddfae959a08e84a7a5a070f44ddba70f156)

bgpd: apply route-map for aggregate before attribute comparison

Currently when re-evaluating an aggregate route, the full attribute of
the aggregate route is not compared with the existing one in the BGP
table. That can result in unnecessary churns (un-install and then
install) of the aggregate route when a more specific route is added or
deleted, or when the route-map for the aggregate changes. The churn
would impact route installation and route advertisement.

The fix is to apply the route-map for the aggregate first and then
compare the attribute.

Here is an example of the churn:

debug bgp aggregate prefix 5.5.5.0/24
!
route-map set-comm permit 10
 set community 65004:200
!
router bgp 65001
 address-family ipv4 unicast
  redistribute static
  aggregate-address 5.5.5.0/24 route-map set-comm
!

Step 1:
  ip route 5.5.5.1/32 Null0

Jan  8 10:28:49 enke-vm1 bgpd[285786]: [J7PXJ-A7YA2] bgp_aggregate_install: aggregate 5.5.5.0/24, count 1
Jan  8 10:28:49 enke-vm1 bgpd[285786]: [Y444T-HEVNG]   aggregate 5.5.5.0/24: installed

Step 2:
  ip route 5.5.5.2/32 Null0

Jan  8 10:29:03 enke-vm1 bgpd[285786]: [J7PXJ-A7YA2] bgp_aggregate_install: aggregate 5.5.5.0/24, count 2
Jan  8 10:29:03 enke-vm1 bgpd[285786]: [S2EH5-EQSX6]   aggregate 5.5.5.0/24: existing, removed
Jan  8 10:29:03 enke-vm1 bgpd[285786]: [Y444T-HEVNG]   aggregate 5.5.5.0/24: installed
---

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit 22d95f4ba8444171944eab29e99dfa6087813d6f)

Revert "bgpd: Reinstall aggregated routes if using route-maps and it was changed"

This reverts commit ee1986f1b5ae6b94b446b12e1b77cc30d8f5f46d.

The fix is incomplete, and is no longer needed with the fix that applies
the route-map for an aggregate and then compares the attribute.

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit 74c9d89aaf3df1b583de341169c4cb77eaa1b3b4)

Merge pull request #17834 from FRRouting/mergify/bp/stable/10.1/pr-17813

bgpd: use igpmetric in bgp_aigp_metric_total() (backport #17813)

bgpd: use igpmetric in bgp_aigp_metric_total()

Use igpmetric from bgp_path_info in bgp_igp_metric_total() to be
consistent with all other cases, e.g., as in bgp_path_info_cmp().

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit b89e66a3bcd5644278f34ec5899b071066e102a1)

Merge pull request #17816 from FRRouting/mergify/bp/stable/10.1/pr-17807

bgpd: fix crash in displaying json orf prefix-list (backport #17807)

bgpd: fix crash in displaying json orf prefix-list

bgpd crashes when there is several entries in the prefix-list. No
backtrace is provided because the issue was catched from a code review.

Fixes: 856ca177c4 ("Added json formating support to show-...-neighbors-... bgp commands.")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 8ccf60921b85893d301186a0f8156fb702da379f)

bgpd: fix bgp orf prefix-list json prefix

0x<address>FX was displayed instead of the prefix.

Fixes: b219dda129 ("lib: Convert usage of strings to %pFX and %pRN")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit b7e843d7e8afe57d3815dbb44e30307654e73711)

Merge pull request #17785 from FRRouting/mergify/bp/stable/10.1/pr-17780

bgpd: fix a bug in peer_allowas_in_set() (backport #17780)

Merge pull request #17789 from FRRouting/mergify/bp/stable/10.1/pr-17725

isisd: Allow full `no` form for `domain-password` and `area-password` (backport #17725)

isisd: Allow full `no` form for `domain-password` and `area-password`

Before:

```
LR1.wue3(config)# router isis VyOS
LR1.wue3(config-router)# no  area-password clear
% Unknown command: no  area-password clear
LR1.wue3(config-router)# no  area-password clear foo
% Unknown command: no  area-password clear foo
LR1.wue3(config-router)#
```

Closes https://github.com/FRRouting/frr/issues/17722

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

bgpd: fix a bug in peer_allowas_in_set()

Fix a bug in peer_allowas_in_set() so that the config takes effect
for peer-group members.

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit bcd10177940223d86cbcfbe1818b2a0b29e0552b)

Merge pull request #17764 from FRRouting/mergify/bp/stable/10.1/pr-17750

tools: Add missing rpki keyword to vrf in frr-reload (backport #17750)

tools: Add missing rpki keyword to vrf in frr-reload

When reloading the following configuration:
```
vrf red
 rpki
  rpki cache tcp 172.65.0.2 8282 preference 1
 exit
exit-vrf
```
frr-reload.py does not properly enter the `rpki` context
within a `vrf`. Because of this, it fails to apply RPKI
configurations.

Signed-off-by: Jonathan Voss <jvoss@onvox.net>
(cherry picked from commit 975ee8ed6eb22f68538f3446b29ca34d65bec72f)

Merge pull request #17741 from FRRouting/mergify/bp/stable/10.1/pr-17731

zebra: Fix resetting valid flags for NHG dependents (backport #17731)

Merge pull request #17756 from FRRouting/mergify/bp/stable/10.1/pr-17732

isisd: Show correct level information for `show isis interface detail json` (backport #17732)

isisd: Show correct level information for `show isis interface detail json`

Having this configuration:

```
!
interface r1-eth0
 ip address 10.0.0.1/30
 ip router isis 1
 isis priority 44 level-1
 isis priority 88 level-2
 isis csnp-interval 90 level-1
 isis csnp-interval 99 level-2
 isis psnp-interval 70 level-1
 isis psnp-interval 50 level-2
 isis hello-interval level-1 120
 isis hello-interval level-2 150

!
interface r1-eth1
 ip address 10.0.0.10/30
 ip router isis 1
!
interface lo
 ip address 192.0.2.1/32
 ip router isis 1
 isis passive
!
router isis 1
net 49.0000.0000.0000.0001.00
 metric-style wide
```

Produces:

```
{
 "areas":[
   {
     "area":"1",
     "circuits":[
       {
         "circuit":2,
         "interface":{
           "name":"r1-eth0",
           "state":"Up",
           "is-passive":"active",
           "circuit-id":"0x2",
           "type":"lan",
           "level":"L1L2",
           "snpa":"6e28.9c92.da5e",
           "levels":[
             {
               "level":"L1",
               "metric":10,
               "active-neighbors":1,
               "hello-interval":120,
               "holddown":{
                 "count":10,
                 "pad":"yes"
               },
               "cnsp-interval":90,
               "psnp-interval":70,
               "lan":{
                 "priority":44,
                 "is-dis":"no"
               }
             },
             {
               "level":"L2",
               "metric":10,
               "active-neighbors":1,
               "hello-interval":120, <<<<<<<<<<<<<<<<<<
               "holddown":{
                 "count":10,
                 "pad":"yes"
               },
               "cnsp-interval":90, <<<<<<<<<<<<<<<<<<
               "psnp-interval":70, <<<<<<<<<<<<<<<<<<
               "lan":{
                 "priority":44, <<<<<<<<<<<<<<<<<<
                 "is-dis":"no"
               }
             }
           ],
...
```

Fixes: 9fee4d4c6038ef6b14e9f509d6b04d189660c4cd ("isisd: Add json to show isis interface command.")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 360a0d6f4ca68fda0eb5d64a8633018a3b5a4a1d)

zebra: Fix resetting valid flags for NHG dependents

Upon if_down, we don't reset the valid flag for dependents
and unset the INSTALLED flag.

So when its time for the NHG to be deleted (routes dereferenced),
zebra deletes it since refcnt goes to 0, but stale NHG remains in kernel.

Ticket :#4200788

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 54ec9f38884fb63e045732537c4c1f4a94608987)

FRR Release 10.1.2

- babeld
-   Do not remove route when replacing
-   Send the route's metric down to zebra.
- bfdd
-   Add no variants to interval configurations
-   Retain remote dplane client socket
- bgpd
-   Actually make ` --v6-with-v4-nexthops` it work
-   Add `bgp ipv6-auto-ra` command
-   Allow value 0 in aigp-metric setting
-   Avoid use-after-free when doing `no router bgp` with auto created instances
-   Fix to pop items off zebra_announce FIFO for few EVPN triggers
-   Clear all paths including addpath once GR expires
-   Compare aigp after local route check in bgp_path_info_cmp()
-   Do not filter no-export community for BGP OAD (one administration domain)
-   Do not reset peers on suppress-fib toggling
-   EVPN fix per rd specific type-2 json output
-   Fix bgp core with a possible Intf delete
-   Fix blank line in running-config with bmp listener cmd
-   Fix crash when polling bgp4v2PathAttrTable
-   Fix display of local label in show bgp
-   Fix `enforce-first-as` per peer-group removal
-   Fix evpn bestpath calculation when path is not established
-   Fix evpn mh esi flap remove local routes
-   Fix for match source-protocol in route-map for redistribute cmd
-   Fix memory leak when creating BMP connection with a source interface
-   Fix memory leak when reconfiguring a route distinguisher
-   Fix printfrr_bp for non initialized peers
-   Fix resolvedPrefix in show nexthop json output
-   Fix route selection with AIGP
-   Fix several issues in sourcing AIGP attribute
-   Fix unconfigure asdot neighbor
-   Fix use single whitespace when displaying flowspec entries
-   Fix version attribute is an int, not a string
-   Include structure when installing End.DT4/6 SID
-   Include structure when installing End.DT46 SID
-   Include structure when removing End.DT4/6 SID
-   Include structure when removing End.DT46 SID
-   Move some non BGP-specific route-map functions to lib
-   Set LLGR stale routes for all the paths including addpath
-   Treat numbered community-list only if it's in a range 1-500
-   Validate both nexthop information (NEXTHOP and NLRI)
-   Validate only affected RPKI prefixes instead of a full RIB
- isisd
-   Fix change flex-algorithm number from uint32 to uint8
-   Fix memory leaks when the transition of neighbor state from non-UP to DOWN
-   Fix rcap tlv double-free crash
-   Fix wrong check for MT commands
- lib
-   Attach stdout to child only if --log=stdout and stdout FD is a tty
-   Include SID structure in seg6local nexthop
-   Take ge/le into consideration when checking the prefix with the prefix-list
-   Keep `zebra on-rib-process script` in frr.conf
- nhrpd
-   Fixes duplicate auth extension
- ospfd
-   Add a hidden command for old `no router-id`
-   Fix heap corruption vulnerability when parsing SR-Algorithm TLV
-   Fix missing '[no]ip ospf graceful-restart hello-delay <N>' commands
-   Interface 'ip ospf neighbor-filter' startup config not applied.
-   Use router_id what Zebra has if we remove a static router_id
- pimd
-   Allow resolving bsr via directly connected secondary address
-   Fix access-list memory leak in pimd
- vrrpd
-   Iterate over all ancillary messages
- zebra
-   Add missing new line for help string
-   Add missing proto translations
-   Correctly report metrics
-   Fix crash during reconnect
-   Fix heap-use-after free on ns shutdown
-   Fix snmp walk of zebra rib
-   Let's use memset instead of walking bytes and setting to 0
-   Separate zebra ZAPI server open and accept
-   Unlock node only after operation in zebra_free_rnh()

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17697 from FRRouting/mergify/bp/stable/10.1/pr-17586

bgpd: Validate only affected RPKI prefixes instead of a full RIB (backport #17586)

Merge pull request #17679 from FRRouting/mergify/bp/stable/10.1/pr-17675

bgpd: Fix memory leak when creating BMP connection with a source interface (backport #17675)

Merge pull request #17713 from opensourcerouting/fix/backport_b6dcf618777bb7a11176617d647e16ab64f49b7b_10.1

bgpd: Fix `enforce-first-as` per peer-group removal (backport)

bgpd: Fix `enforce-first-as` per peer-group removal

If we do `no neighbor PG enforce-first-as`, it wasn't working because the flag
was inherited incorrectly for the members of the peer-group.

Fixes: 322462920e2a2c8b73191c6eb5157d64cf4a593e ("bgpd: Enable enforce-first-as by default")
Closes: https://github.com/FRRouting/frr/issues/17702
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17687 from FRRouting/mergify/bp/stable/10.1/pr-17669

bgpd: fix memory leak when reconfiguring a route distinguisher (backport #17669)

bgpd: Validate only affected RPKI prefixes instead of a full RIB

Before this fix, if rpki_sync_socket_rtr socket returns EAGAIN, then ALL routes
in the RIB are revalidated which takes lots of CPU and some unnecessary traffic,
e.g. if using BMP servers. With a full feed it would waste 50-80Mbps.

Instead we should try to drain an existing pipe (another end), and revalidate
only affected prefixes.

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

bgpd: fix memory leak when reconfiguring a route distinguisher

A memory leak happens when reconfiguring an already configured route
distinguisher on an L3VPN BGP instance. Fix this by freeing the previous
route distinguisher.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 0dd96287dda22b79ef6d7424f4e1a8dc92959f92)

bgpd: Fix memory leak when creating BMP connection with a source interface

Testing done with:

```
for x in $(seq 1 100000); do vtysh -c 'conf' -c 'router bgp' -c 'bmp targets test' -c 'bmp connect localhost port 123 min-retry 100 max-retry 100 source-interface lo'; done
```

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

Merge pull request #17657 from FRRouting/mergify/bp/stable/10.1/pr-17615

lib: Take ge/le into consideration when checking the prefix with the prefix-list (backport #17615)

Merge pull request #17663 from FRRouting/mergify/bp/stable/10.1/pr-17613

bgpd: Fix evpn bestpath calculation when path is not established (backport #17613)

bgpd: Fix evpn bestpath calculation when path is not established

If you have a bestpath list that looks something like this:

<local evpn mac route>
<learned from peer out swp60>
<learned from peer out swp57>

And a network event happens that causes the peer out swp60
to not be in an established state, yet we still have the
path_info for the destination for swp60, bestpath
will currently end up with this order:

<learned from peer out swp60>
<local evpn mac route>
<learned from peer out swp57>

This causes the local evpn mac route to be deleted in zebra( Wrong! ).

This is happening because swp60 is skipped in bestpath calculation and
not considered to be a path yet it stays at the front of the list.

Modify bestpath calculation such that when pulling the unsorted_list
together to pull path info's into that list when they are also
not in a established state.

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

lib: Take ge/le into consideration when checking the prefix with the prefix-list

Without the fix:

```
show ip prefix-list test_1 10.20.30.96/27 first-match
 <no result>

show ip prefix-list test_2 192.168.1.2/32 first-match
 <no result>
```

With the fix:

```
ip prefix-list test_1 seq 10 permit 10.20.30.64/26 le 27
!
end
donatas# show ip prefix-list test_1 10.20.30.96/27
   seq 10 permit 10.20.30.64/26 le 27 (hit count: 1, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.64/27
   seq 10 permit 10.20.30.64/26 le 27 (hit count: 2, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.64/28
donatas# show ip prefix-list test_1 10.20.30.126/26
   seq 10 permit 10.20.30.64/26 le 27 (hit count: 3, refcount: 0)
donatas# show ip prefix-list test_1 10.20.30.126/30
donatas#
```

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

Merge pull request #17631 from opensourcerouting/fix/backport_9b0b9282d317a9aeab36d9a8b08a35fe9a172c4b_10.1

bgpd: Fix bgp core with a possible Intf delete (backport)

bgpd: Fix bgp core with a possible Intf delete

Although trigger unknown, based on the backtrace in one of the internal
testing, we do see some delete in the Intf where we can have the peer
ifp pointer null and we try to dereference it while trying to install
the route leading to a crash

Skip updating the ifindex in such cases and since the nexthop is not
properly updated, BGP skips sending it to zebra.

BackTrace:
0  0x00007faef05e7ebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
1  0x00007faef0598fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
2  0x00007faef09900dc in core_handler (signo=11, siginfo=0x7ffdde8cb4b0, context=<optimized out>) at lib/sigevent.c:274
3  <signal handler called>
4  0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc,
   nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273
5  bgp_zebra_announce_actual (dest=dest@entry=0x5560afcfa950, info=0x5560b21187d0, bgp=0x5560ace04df0) at bgpd/bgp_zebra.c:1521
6  0x00005560aad4bc85 in bgp_handle_route_announcements_to_zebra (e=<optimized out>) at bgpd/bgp_zebra.c:1896
7  0x00007faef09a1c0d in thread_call (thread=thread@entry=0x7ffdde8d7580) at lib/thread.c:2008
8  0x00007faef095a598 in frr_run (master=0x5560ac7e5190) at lib/libfrr.c:1223
9  0x00005560aac65db6 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:557

(gdb) f 4
4  0x00005560aad4b7d8 in update_ipv6nh_for_route_install (api_nh=0x7ffdde8cbe94, is_evpn=false, best_pi=0x5560b21187d0, pi=0x5560b21187d0, ifindex=0, nexthop=0x5560b03cb0dc,
    nh_bgp=0x5560ace04df0, nh_othervrf=0) at bgpd/bgp_zebra.c:1273
1273 in bgpd/bgp_zebra.c
(gdb) p pi->peer->ifp
$26 = (struct interface *) 0x0

Ticket :#4203904

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>

Merge pull request #17595 from opensourcerouting/fix/backport_12a9ca4de6c781b061cccdf3e793346e23558901_10.1

bgpd: fix unconfigure asdot neighbor (backport)

bgpd: fix unconfigure asdot neighbor

The below command is not successfull on an existing as dot peer

> no neighbor 10.0.0.2 remote-as 1.1
> % Create the peer-group or interface first

Handle the case where the remote-as argument can be an ASNUM.

Fixes: 8079a4138d61 ("lib, bgp: add initial support for asdot format")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

Merge pull request #17559 from FRRouting/mergify/bp/stable/10.1/pr-17313

zebra: separate zebra ZAPI server open and accept (backport #17313)

Merge pull request #17568 from FRRouting/mergify/bp/stable/10.1/pr-17518

pimd: Fix access-list memory leak in pimd (backport #17518)

pimd: Fix access-list memory leak in pimd

Reset access-lists in pimd on terminate

Signed-off-by: Corey Siltala <csiltala@atcorp.com>
(cherry picked from commit d21a993f16dc23df6a1f1a7c81e9f562446437a0)

zebra: separate zebra ZAPI server open and accept

Separate zebra's ZAPI server socket handling into two phases:
an early phase that opens the socket, and a later phase that
starts listening for client connections.

Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 506097a1b96974c261411edd25330ceaf90fa3db)

Merge pull request #17523 from FRRouting/mergify/bp/stable/10.1/pr-17510

bgpd: fix use single whitespace when displaying flowspec entries (backport #17510)

bgpd: fix use single whitespace when displaying flowspec entries

There is an extra space in the 'Displayed' line of show bgp command,
that should not be present.
Fix this by being consistent with the output of the other address
families.

Fixes: ("a1baf9e84f71") bgpd: Use single whitespace when displaying show bgp summary
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 561debab5430ac85e8e42e839312d213479a767a)

Merge pull request #17512 from FRRouting/mergify/bp/stable/10.1/pr-17506

bgpd: fix version attribute is an int, not a string (backport #17506)

bgpd: fix version attribute is an int, not a string

The json display of the version attribute is originally an
integer. It has changed, most probably mistakenly.

> {
>   "vrfId": 7,
>   "vrfName": "vrf1",
>   "tableVersion": 3,
>   "routerId": "192.0.2.1",
>   "defaultLocPrf": 100,
>   "localAS": 65500,
>   "routes": {
>     "172.31.0.1/32": {
>       "prefix": "172.31.0.1/32",
>       "version": "1", <--- int or string ??

Let us fix it, by using the integer display instead.

Fixes: f9f2d188e398 ("bgpd: fix 'json detail' output structure")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit c5d7815cccb92c192ca6b752843b8b827a607b53)

Merge pull request #17490 from FRRouting/mergify/bp/stable/10.1/pr-17487

bgpd: Do not reset peers on suppress-fib toggling (backport #17487)

bgpd: Do not reset peers on suppress-fib toggling

If the desired state is the same - do nothing instead of resetting once again.

Fixes: bdb5ae8bce94432eb5e581f04f48dc4aa5db7ca4 ("bgpd: Make suppress-fib-pending clear peering")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 7fb4c03f5b1c9cd4e8acb85b4cf953ac85aa0bbf)

Merge pull request #17471 from FRRouting/mergify/bp/stable/10.1/pr-17464

bfdd: retain remote dplane client socket (backport #17464)

bfdd: retain remote dplane client socket

When using bfd in remote-dataplane client mode, don't close
a new client socket if we're going to try to use it.

Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit f5115307888dc8ca4b6369d1b705686d3c689d23)

Merge pull request #17447 from opensourcerouting/fix/backport_65a43b57efd60c4fdf80c935750046ba861ec79f_10.1

bgpd: Validate both nexthop information (NEXTHOP and NLRI) (backport)

bgpd: Validate both nexthop information (NEXTHOP and NLRI)

If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and
mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because
of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we
have at least one a valid nexthop.

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

Merge pull request #17438 from FRRouting/mergify/bp/stable/10.1/pr-17432

bgpd : backpressure - Fix to pop items off zebra_announce FIFO for few EVPN triggers (backport #17432)

bgpd : backpressure - Fix to pop items off zebra_announce FIFO for few EVPN triggers

In cases such as 'no advertise-all-vni' and L2 VNI DELETE, we need to
pop all the VPN routes present in the bgp_zebra_announce FIFO yet to
be processed regardless of VNI is configured or not.

NOTE: NO need to pop the VPN routes in two cases
 1) In free_vni_entry
   - Called by bgp_free()->bgp_evpn_cleanup().
   - Since bgp_delete is called before bgp_free and we pop all the dest
     pertaining to bgp under delete.
 2) evpn_delete_vni() when user configures "no vni" since the withdraw
    of all routes happen in normal cycle.

Fixes: a07df6f7548f6bd1b92acbb7a10c3823de33fe5f
("bgpd : backpressure - Handle BGP-Zebra(EPVN) Install evt Creation")

Ticket :#4163611

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

Merge pull request #17412 from FRRouting/mergify/bp/stable/10.1/pr-17409

bgpd: fix resolvedPrefix in show nexthop json output (backport #17409)

Merge pull request #17402 from opensourcerouting/fix/backport_031d4271018e827010abfa8f3ecfe60bbf1de21d_10.1

bgpd: Fix for match source-protocol in route-map for redistribute cmd (backport)

bgpd: fix resolvedPrefix in show nexthop json output

While populating  the nexthop info for "show bgp nexthop json", resolvedPrefix
is added in parent json object instead of json_nexthop object.
This results in displaying wrong resolvedPrefix for nexthops.
Fixing the same by adding resolvedPrefix to json_nexthop object, so that
the proper resolvedPrefix would be displayed for the respective nexthop

Signed-off-by: Krishnasamy R <krishnasamyr@nvidia.com>
(cherry picked from commit 95c08e082c063374cbc62dea6529c8f54b0722df)

bgpd: Fix for match source-protocol in route-map for redistribute cmd

A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.

Fixing this since this wasnt implemented earlier.

Ticket :#4119692

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 68358c0f928eafe50c9e73b0cb6a443c03f2a33f)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17392 from opensourcerouting/fix/backport_17376_10.1

bgpd: Clear stale routes with multiple paths (backport)

bgpd: Set LLGR stale routes for all the paths including addpath

Without this patch we set only the first path for the route (if multiple exist)
as LLGR stale and stop doing that for the rest of the paths, which is wrong.

Fixes: 1479ed2fb35f4a5ae1017201a7ee37ba2727163a ("bgpd: Implement LLGR helper mode")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

bgpd: Clear all paths including addpath once GR expires

We iterated over all bgp_path_info's, but once we remove the path, we didn't
check for other paths under the same bgp_dest.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>

Merge pull request #17348 from FRRouting/mergify/bp/stable/10.1/pr-17305

bgpd: Treat numbered community-list only if it's in a range 1-500 (backport #17305)

Merge pull request #17353 from FRRouting/mergify/bp/stable/10.1/pr-17319

ospfd: Use router_id what Zebra has if we remove a static router_id (backport #17319)

ospfd: Use router_id what Zebra has if we remove a static router_id

If we set router-id, e.g. `router-id x.x.x.x`, then we have:

```
pc.donatas.net# show ip ospf | include Router ID
 OSPF Routing Process, Router ID: x.x.x.x
```

But once we remove it (`no router-id x.x.x.x`), the old router-id remains.

This is kinda OK, but to be consistent with OSPFv3 we should use what Zebra
already has, instead of retaining the old one.

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

ospfd: Add a hidden command for old `no router-id`

A new command is `ospf router-id ...`, but the old one is also valid. Just a no
form was missed.

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

bgpd: Treat numbered community-list only if it's in a range 1-500

Before this patch, if we set something like:

```
bgp extcommunity-list expanded 1234 permit admin
```

In running config we have:

```
bgp extcommunity-list 1234 seq 5 permit admin
```

That leads to incorrect rendering, even more the line can't be deleted.

With this fix we treat numbered community-list only if it's inside the range
1-500, otherwise it's a non-numbered clist.

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

Merge pull request #17322 from FRRouting/mergify/bp/stable/10.1/pr-17318

zebra: Add missing new line for help string (backport #17318)

Merge pull request #17301 from FRRouting/mergify/bp/stable/10.1/pr-17250

isisd: fix change flex-algorithm number from uint32 to uint8 (backport #17250)

zebra: Add missing new line for help string

```
  -A, --asic-offload        FRR is interacting with an asic underneath the linux kernel
      --v6-with-v4-nexthops Underlying dataplane supports v6 routes with v4 nexthops  -s, --nl-bufsize          Set netlink receive buffer size
```

Fixes: 1f5611c06d1c243b42279748788f0627793ead9c ("zebra: Allow zebra cli to accept v6 routes with v4 nexthops")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 25ae643996d338b8230fb15a9064843fe85de224)

isisd: fix change flex-algorithm number from uint32 to uint8

The algorithm number is encoded on 8 bits and does not require
an unsigned 32 bit value to store the value.

Fixes: cc4926c1284e ("isisd,yang: add algorithm-prefix-sid configuration tree")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 8e861a75e8b426f0944157387699fe1ab322fe8e)

Merge pull request #17298 from FRRouting/mergify/bp/stable/10.1/pr-15716

isisd: Fix memory leaks when the transition of neighbor state from non-UP to DOWN (backport #15716)