bgpd: fix `set evpn gateway-ip ipv[46]` route-map

The `route_set_evpn_gateway_ip` function copies `gw_ip->ip.addr` in the
route's gateway ip. In a nutshell, this skips the `ipa_type` field,
writing the actual IP in the IP type. This later rightfully trips
asserts about unknown IP types.

The following route-map...

```
route-map test permit 10
    set evpn gateway-ip ipv4 1.1.1.1
```

...will make the following gateway IP in the route:

```
(gdb) p/x a1->evpn_overlay->gw_ip
$11 = {ipa_type = 0x1010101, ip = {addr = 0x0, addrbytes = {
      0x0 <repeats 16 times>}, _v4_addr = {s_addr = 0x0}, _v6_addr = {
      __in6_u = {__u6_addr8 = {0x0 <repeats 16 times>}, __u6_addr16 = {0x0,
          0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x0, 0x0, 0x0,
          0x0}}}}}
```

We do indeed see the IP Address in the `ipa_type` field.

Fix by starting the memcpy at the root of `struct ipaddr` instead of
skipping the `ipa_type` field.

Fixes: d0a4ee6010a ("bgpd: Add "set evpn gateway-ip" clause for route-map")
Signed-off-by: Tuetuopay <tuetuopay@me.com>

Merge pull request #18366 from pguibert6WIND/community_limit_zero_add_test

Add Testing for community and Extended community match limit zero

Merge pull request #18367 from donaldsharp/static_nexthop_reinstall

staticd: Install known nexthops upon connection with zebra

Merge pull request #18368 from donaldsharp/backout_bgp_if_up_down_changes

Revert "bgpd: upon if event, evaluate bnc with matching nexthop"

Revert "bgpd: upon if event, evaluate bnc with matching nexthop"

This reverts commit 58592be57783a3b24e7351af2a5afc61299768df.

This commit is being reverted because of several issues:

a) tcpdump -i <any interface that bgp happens to use>

This command causes bgp to dump it's entire table to all
of it's peers again.  This is a huge problem in any type
of scaled environment *and* it is not unusual to have an
operator do this.

b) This commit appears to be attempting to solve the problem
with route leaking across vrf's using labels( or somesuch ).
Unfortunately we have absolutely no topotests that show the
behavior.  I am also unable to get any type of how to reproduce
the problem being solved by the commit.  I do know, though,
that the problem really stems from the fact that bgp has
decided to cheat and not create bnc's for route leaking.
Thus when a nexthop changes, bgp is not being notified.
This commit was being used as a hammer to solve the problem.

While I do agree backing out a bug fix for some operator
is less then ideal, I believe that since I cannot get the
operator to tell me the problem it solved and the fact
that sending large amounts of updates with just a simple
tcpdump command ( actually 2 one for tcpdump start and
one for finishing ) is more detrimental in my eyes at
this point in time.  Additionally the solution used
is the wrong one for the problem.

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

staticd: Install known nexthops upon connection with zebra

CI tests are showing cases where staticd is connecting to
zebra after config is read in and the nexthops are never
being registered w/ zebra:

2025/03/11 15:39:44 STATIC: [T83RR-8SM5G] staticd 10.4-dev starting: vty@2616
2025/03/11 15:39:45 STATIC: [GH3PB-C7X4Y] Static Route to 13.13.13.13/32 not installed currently because dependent config not fully available
2025/03/11 15:39:45 STATIC: [RHJK1-M5FAR] static_zebra_nht_register: Failure to send nexthop 1.1.1.2/32 for 11.11.11.11/32 to zebra
2025/03/11 15:39:45 STATIC: [M7Q4P-46WDR] vty[14]@> enable

Zebra shows connection time as:

2025/03/11 15:39:45.933343 ZEBRA: [V98V0-MTWPF] client 5 says hello and bids fair to announce only static routes vrf=0

As a result staticd never installs the route because it has no nexthop
tracking to say that the route could be installed.

Modify staticd on startup to go through it's nexthops and dump them to
zebra to allow the staticd state machine to get to work.

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

Merge pull request #18336 from routingrocks/rvaratharaj/bugfixmar

zebra: Fix neigh delete causing heap-use-after-free error

zebra: Fix neigh delete causing heap-use-after-free error

Issue:
Not freeing the neighbor n  within the same function can lead to
memory leak.
zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free

Fix: not accessing n after its freed.
Directly free the neighbor entry (n) when its interface index matches
ifp->ifindex.

This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
    #0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
    #1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
    #2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
    #3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
    #4 0x55f95a0f819d in if_down zebra/interface.c:1017
    #5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
    #6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
    #7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
    #8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
    #9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
    #10 0x55f95a11ca7f in main zebra/main.c:543
    #11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)

Ticket: #18047

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>

Merge pull request #16614 from louis-6wind/fix-otable-heap-after-free

zebra: fix table heap-after-free crash

topotests: check when extended community-limit is set to 0

Add a test to control that when the extended community limit is set
to 0, then only 2 BGP updates are received on R3.

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

topotests: check when community-limit is set to 0

Add a test to control that when the community limit is set to 0, then
only 2 BGP updates are received on R3.

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

Merge pull request #18362 from y-bharath14/srib-tests-v4

tests: Fixed NameError at bmpserver.py

Merge pull request #18346 from donaldsharp/memory_leaks_bgp

Clean up some code and bad assumptions in zebra

Merge pull request #18342 from anlancs/ospfd-minor-change

ospfd: minor change for style

tests: Fixed NameError at bmpserver.py

Fixed NameError at bmpserver.py

Signed-off-by: y-bharath14 <y.bharath@samsung.com>

tests: zebra_rib, test vrf change

Test table ID move to a VRF and the removal of the VRF.

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

lib, tests, zebra: keep table routes at vrf disabling

At VRF disabling, keep the route entries that was associated to its
table ID but not to the VRF itself. Kernel flushes these entries so we
need to reinstall them.

To do so, add a flag to mean that a route entry is owned by a table ID
and not by a VRF. If the VRF associated to the table ID is deleted, the
route entry must not be deleted.

Update to tests with new flag. 2057 is in hexa 0x809, meaning that the
new flag has been to some prefix.

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

tests: zebra_rib, test vrf change

Test table ID move to a VRF and the removal of the VRF.

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

zebra: fix vanished blackhole route

Fix vanished blackhole route when kernel routes are updated.

> root@router# echo "100 my_table" | tee -a /etc/iproute2/rt_tables
> root@router# ip l add du0 type dummy
> root@router# ifconfig du0 192.168.0.1/24 up
> root@router# ip route add blackhole default table 100
> root@router# ip route show table 100
> blackhole default
> root@router# vtysh -c 'show ip route table 100'
> [...]
> Table 100:
> K>* 0.0.0.0/0 [0/0] unreachable (blackhole), weight 1, 00:00:05
> root@router# ip l add red type vrf table 100
> root@router# vtysh -c 'show ip route table 100'
> [...]
> Table 100:
> K>* 0.0.0.0/0 [0/0] unreachable (blackhole), weight 1, 00:00:16
> root@router# ip l set du0 master red
> root@router# vtysh -c 'show ip route table 100'
> [...]
> Table 100:
> C>* 192.168.0.0/24 is directly connected, du0, weight 1, 00:00:02
> L>* 192.168.0.1/32 is directly connected, du0, weight 1, 00:00:02
> root@router# ip route show table 100
> blackhole default
> 192.168.0.0/24 dev du0 proto kernel scope link src 192.168.0.1
> local 192.168.0.1 dev du0 proto kernel scope host src 192.168.0.1
> broadcast 192.168.0.255 dev du0 proto kernel scope link src 192.168.0.1

Fixes: d528c02a20 ("zebra: Handle kernel routes appropriately")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

zebra: fix removed default route at vrf enabling

When a routing table (RT) already has a default route before being
assigned to a VRF, the default route vanishes in zebra after the VRF
assignment.

> root@router:~# ip route add blackhole default table 100
> root@router:~# ip route show table 100
> blackhole default
> root@router:~# vtysh -c 'show ip route table 100'
> [...]
> VRF default table 100:
> K>* 0.0.0.0/0 [0/0] unreachable (blackhole), 00:00:05
> root@router:~# ip l add red type vrf table 100
> root@router:~# vtysh -c 'show ip route table 100'
> root@router:~#

Do not override the default route if it exists.

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

zebra: remove vrf route entries at vrf disabling

This is the continuation of the previous commit.

When a VRF is deleted, the kernel retains only its own routing entries
in the former VRF table and removes all others.

This change ensures that routing entries created by FRR daemons are also
removed from the former zebra VRF table when the VRF is disabled.

To test:

> echo "100 my_table" | tee -a /etc/iproute2/rt_tables
> ip l add du0 type dummy
> ifconfig du0 192.168.0.1/24 up
> ip route add blackhole default table 100
> ip route show table 100
> ip l add red type vrf table 100
> ip l set du0 master red
> vtysh -c 'configure' -c 'vrf red' -c 'ip route 10.0.0.0/24 192.168.0.254'
> vtysh -c 'show ip route table 100'
> sleep 0.1
> ip l del red
> sleep 0.1
> vtysh -c 'show ip route table 100'
> ip l add red type vrf table 100
> ip l set du0 master red
> vtysh -c 'configure' -c 'vrf red' -c 'ip route 10.0.0.0/24 192.168.0.254'
> vtysh -c 'show ip route table 100'
> sleep 0.1
> ip l del red
> sleep 0.1
> vtysh -c 'show ip route table 100'

Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

zebra: fix table heap-after-free crash

Fix a heap-after-free that causes zebra to crash even without
address-sanitizer. To reproduce:

> echo "100 my_table" | tee -a /etc/iproute2/rt_tables
> ip route add blackhole default table 100
> ip route show table 100
> ip l add red type vrf table 100
> ip l del red
> ip route del blackhole default table 100

Zebra manages routing tables for all existing Linux RT tables,
regardless of whether they are assigned to a VRF interface. When a table
is not assigned to any VRF, zebra arbitrarily assigns it to the default
VRF, even though this is not strictly accurate (the code expects this
behavior).

When an RT table is created after a VRF, zebra correctly assigns the
table to the VRF. However, if a VRF interface is assigned to an existing
RT table, zebra does not update the table owner, which remains as the
default VRF. As a result, existing routing entries remain under the
default VRF, while new entries are correctly assigned to the VRF. The
VRF mismatch is unexpected in the code and creates crashes and memory
related issues.

Furthermore, Linux does not automatically delete RT tables when they are
unassigned from a VRF. It is incorrect to delete these tables from zebra.

Instead, at VRF disabling, do not release the table but reassign it to
the default VRF. At VRF enabling, change the table owner back to the
appropriate VRF.

> ==2866266==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000154f54 at pc 0x7fa32474b83f bp 0x7ffe94f67d90 sp 0x7ffe94f67d88
> READ of size 1 at 0x606000154f54 thread T0
>     #0 0x7fa32474b83e in rn_hash_node_const_find lib/table.c:28
>     #1 0x7fa32474bab1 in rn_hash_node_find lib/table.c:28
>     #2 0x7fa32474d783 in route_node_get lib/table.c:283
>     #3 0x7fa3247328dd in srcdest_rnode_get lib/srcdest_table.c:231
>     #4 0x55b0e4fa8da4 in rib_find_rn_from_ctx zebra/zebra_rib.c:1957
>     #5 0x55b0e4fa8e31 in rib_process_result zebra/zebra_rib.c:1988
>     #6 0x55b0e4fb9d64 in rib_process_dplane_results zebra/zebra_rib.c:4894
>     #7 0x7fa32476689c in event_call lib/event.c:1996
>     #8 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232
>     #9 0x55b0e4e6c32a in main zebra/main.c:526
>     #10 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308
>     #11 0x55b0e4e2d649 in _start (/usr/lib/frr/zebra+0x1a1649)
>
> 0x606000154f54 is located 20 bytes inside of 56-byte region [0x606000154f40,0x606000154f78)
> freed by thread T0 here:
>     #0 0x7fa324ca9b6f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:123
>     #1 0x7fa324668d8f in qfree lib/memory.c:130
>     #2 0x7fa32474c421 in route_table_free lib/table.c:126
>     #3 0x7fa32474bf96 in route_table_finish lib/table.c:46
>     #4 0x55b0e4fbca3a in zebra_router_free_table zebra/zebra_router.c:191
>     #5 0x55b0e4fbccea in zebra_router_release_table zebra/zebra_router.c:214
>     #6 0x55b0e4fd428e in zebra_vrf_disable zebra/zebra_vrf.c:219
>     #7 0x7fa32476fabf in vrf_disable lib/vrf.c:326
>     #8 0x7fa32476f5d4 in vrf_delete lib/vrf.c:231
>     #9 0x55b0e4e4ad36 in interface_vrf_change zebra/interface.c:1478
>     #10 0x55b0e4e4d5d2 in zebra_if_dplane_ifp_handling zebra/interface.c:1949
>     #11 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268
>     #12 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954
>     #13 0x7fa32476689c in event_call lib/event.c:1996
>     #14 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232
>     #15 0x55b0e4e6c32a in main zebra/main.c:526
>     #16 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308
>
> previously allocated by thread T0 here:
>     #0 0x7fa324caa037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7fa324668c4d in qcalloc lib/memory.c:105
>     #2 0x7fa32474bf33 in route_table_init_with_delegate lib/table.c:38
>     #3 0x7fa32474e73c in route_table_init lib/table.c:512
>     #4 0x55b0e4fbc353 in zebra_router_get_table zebra/zebra_router.c:137
>     #5 0x55b0e4fd4da0 in zebra_vrf_table_create zebra/zebra_vrf.c:358
>     #6 0x55b0e4fd3d30 in zebra_vrf_enable zebra/zebra_vrf.c:140
>     #7 0x7fa32476f9b2 in vrf_enable lib/vrf.c:286
>     #8 0x55b0e4e4af76 in interface_vrf_change zebra/interface.c:1533
>     #9 0x55b0e4e4d612 in zebra_if_dplane_ifp_handling zebra/interface.c:1968
>     #10 0x55b0e4e4fb89 in zebra_if_dplane_result zebra/interface.c:2268
>     #11 0x55b0e4fb9f26 in rib_process_dplane_results zebra/zebra_rib.c:4954
>     #12 0x7fa32476689c in event_call lib/event.c:1996
>     #13 0x7fa32463b7b2 in frr_run lib/libfrr.c:1232
>     #14 0x55b0e4e6c32a in main zebra/main.c:526
>     #15 0x7fa32424fd09 in __libc_start_main ../csu/libc-start.c:308

Fixes: d8612e6 ("zebra: Track tables allocated by vrf and cleanup")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>

Merge pull request #18348 from donaldsharp/topotest_startup_order

Topotest startup order

tests: Have zebra startup look for the zserv.api socket

Ensure that the zserv.api socket is actually up and running
before moving onto other daemons after zebra.

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

tests: Allow mgmtd and zebra to fully come up before other daemons

Currently the topotest infrastructure is starting up daemons
in mgmtd,zebra, staticd then everything else.

The problem that is happening, under heavy load, is that
zebra may not be fully started and when a daemon attempts
to connect to it, it will not be able to connect.
Some of the daemons do not have great retry mechanisms at all.
In addition our normal systemctl startup scripts actually
wait a small amount of time for zebra to be ready before
moving onto the other daemons.

Let's make topotests startup a tiny bit more nuanced
and have mgmtd fully up before starting up zebra.

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

Merge pull request #18335 from karthikeyav/bitfield_copy

lib: use memcpy in bf_copy

Merge pull request #18344 from donaldsharp/fix_pytest_syntx_stuff

tests: bgp_evpn_route_map_match fix invalid escape sequence

lib: use memcpy in bf_copy

use memcpy in bf_copy() instead of copy word by word in for loop

Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com>

zebra: Don't use MTYPE_TMP for l2 vni data

Convert over from MTYPE_TMP to MTYPE_L2_VNI as the
data type.

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

zebra: Declutter zebra_vxlan_if_add_update_vni

This function has equivalent code on both sides
of a if statement.  Let's consolidate this.

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

zebra: malloc functions cannot fail

Let's try to remember that when using a malloc function
it can never fail and as such testing for NULL does
nothing.

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

Merge pull request #18338 from donaldsharp/documentation_typesafe

Documentation typesafe

tests: bgp_evpn_route_map_match fix invalid escape sequence

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

Merge pull request #18337 from donaldsharp/revert_keepalive_connection

Revert "bgpd: Make keepalive pthread be connection based."

Merge pull request #18327 from donaldsharp/fixups_for_connection

bgpd: Fix dead code in bgp_route.c #1637664

doc: The sbfd documentation was not being included

Add the sbfd documentation, such as it is, to the
developer documentation so that it can be read
by people.

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

doc: Developer documentation missing some build instructions

The building-frr-for-ubuntu2404 and building-doc were missing
from the compilation of developer documents.

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

doc: Add typesafe conversion examples

Try to give some good examples of various lists being
converted over to the typesafe way of doing things.

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

lib: remove unused macro

This macro is unused and it leads to the compile error:

```
./ospfd/ospf_dump.h:78:60: error: pasting "OSPF_DEBUG_" and ""Global Graceful Restart - GR Mode\n"" does not give a valid preprocessing token
   78 | #define TERM_DEBUG_ON(a, b)      term_debug_ospf_ ## a |= (OSPF_DEBUG_ ## b)
```

Signed-off-by: anlan_cs <anlan_cs@126.com>

Revert "bgpd: Make keepalive pthread be connection based."

This reverts commit 23bdaba147517abb4a70d03166ad74f759888d46.

Merge pull request #18315 from gromit1811/bugfix/pim6_mld_vrf_fix

pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo)

Merge pull request #18214 from soumyar-roy/soumya/ra514nei

zebra: Bring up 514 BGP neighbor sessions

bgpd: Fix dead code in bgp_route.c #1637664

Coverity rightly points out that the worse pointer
cannot be null in this section of code.  Fix it.

Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>

Merge pull request #18313 from donaldsharp/log_always_documented

lib: Document --command-log-always in help

Merge pull request #18319 from qlyoung/fix-overriding-automake-builtin-doc-targets

doc: don't override automake builtin targets

doc: don't override automake builtin targets

Automake generates default targets for `info`, `html`, `pdf` and
corresponding `install-info` and `install-html` targets to install the
artifacts generated by those rules. Prior to this change we are
overriding those targets which generates a warning.

The automake targets are designed to automatically build texinfo sources
without requiring user-specified rules. We do not have texinfo sources
so this functionality is not in use, but we are still overriding the
built in targets which is considered poor form. Automake has facilities
to modify the built in targets in the form of `-local` rules; this patch
renames the rules we had defined to use the `-local` ones.

The resulting targets generated by Automake look like this:

  html: html-am
  html-am: html-local

i.e. the final `html` target generated when using `html-local` to define
our custom rules is identical to the one we get by overriding the built
in `html` target. The same goes for the others.

So, the only effect this patch has is suppressing the warnings and
bringing us in line with Automake best practice.

Signed-off-by: Quentin Young <qlyoung@nvidia.com>

Merge pull request #18195 from donaldsharp/more_connection_cleanup

More connection cleanup

Merge pull request #18310 from opensourcerouting/freebsd-snmp

configure.ac: fix sed failure on FreeBSD

pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo)

When receiving MLD messages, prefer pktinfo over msghdr.msg_name for
determining the source interface. The latter is just the VRF master
interface in case of VRF and we need the true interface the packet was
received on instead.

Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>

lib: Document --command-log-always in help

The --command-log-always was not being listed as a valid
option for when the operator issues a <daemon> --help
command line.

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

Merge pull request #18268 from donaldsharp/yang_correct_vrf_issue

lib: Correct handling of /frr-vrf:lib/vrf/state/active

tests: add support for 514 unnumbered/v4/v6 BGP sessions

Signed-off-by: Soumya Roy <souroy@nvidia.com>

tests: add support for bringimg up 514 BGP neighbors

Signed-off-by: Soumya Roy <souroy@nvidia.com>

zebra: Bring up 514 BGP neighbor sessions

Issue:
When 514 inerfaces/neighbors are configured, it creates socket error,
"Cannot allocate memory", when back to back V6 RA messages are tried
to be sent over the socket. This prevents interface, to know its peer's
link local address. Socket error comes when 1) try to join ICMPv6 all
router multicast group, back to back for all interfaces 2)send back to
back RA for all interfaces

Fix:
1)For ICMPv6 join case, we check if the interface has already joined
all router group, if not try to join. On failure, retry joining after
random amount of time determined 1 ms to ICMPV6_JOIN_TIMER_EXP_MS(100 ms)
2) For RA issue case, batch sending of RA mesages using wheel timer

Testing:
Monitor BGP session running sh bgp summary command

Before fix:
r1# sh bgp summary

IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 515, using 12 MiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
r1-eth0         4       1002        89        90        0    0    0 00:07:10            0        0 N/A
r1-eth1         4       1002        89        90        0    0    0 00:07:10            0        0 N/A
r1-eth2         4       1002        89        90        0    0    0 00:07:10            0        0 N/A
r1-eth3         4       1002        89        90        0    0    0 00:07:10            0        0 N/A
r1-eth4         4       1002        89        90        0    0    0 00:07:10            0        0 N/A
r1-eth5         4       1002        89        90        0    0    0 00:07:10            0        0 N/A

…..<snip>...
r1-eth252       4       1002        31        29        0    0    0 00:02:08            0        0 N/A
r1-eth253       4       1002        31        29        0    0    0 00:02:08            0        0 N/A
r1-eth254       4       1002        31        29        0    0    0 00:02:08            0        0 N/A
r1-eth255       4       1002        31        29        0    0    0 00:02:08            0        0 N/A
r1-eth256       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth257       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth258       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth259       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth260       4          0         0         0        0    0    0    never         Idle        0 N/A
……..<snip>…..
r1-eth511       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth512       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth513       4          0         0         0        0    0    0    never         Idle        0 N/A
r1-eth514       4          0         0         0        0    0    0    never         Idle        0 N/A
After fix:
r1# show bgp summary

IPv4 Unicast Summary:
BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 515, using 12 MiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
r1-eth0         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth1         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth2         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth3         4       1002        64        67        0    0    0 00:05:09            0        0 N/A
r1-eth4         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth5         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth6         4       1002        67        70        0    0    0 00:05:22            0        0 N/A
r1-eth7         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
r1-eth8         4       1002        87        87        0    0    0 00:07:04            0        0 N/A
....
r1-eth499       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth500       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth501       4       1002        19        22        0    0    0 00:01:21            0        0 N/A
r1-eth502       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth503       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth504       4       1002        20        23        0    0    0 00:01:30            0        0 N/A
r1-eth505       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth506       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth507       4       1002        22        25        0    0    0 00:01:39            0        0 N/A
r1-eth508       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth509       4       1002        17        20        0    0    0 00:01:13            0        0 N/A
r1-eth510       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth511       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth512       4       1002        19        22        0    0    0 00:01:22            0        0 N/A
r1-eth513       4       1002        43        43        0    0    0 00:03:22            0        0 N/A
r1-eth514       4       1002        43        43        0    0    0 00:03:22            0        0 N/A

Signed-off-by: Soumya Roy <souroy@nvidia.com>

Merge pull request #18293 from y-bharath14/srib-yang-v4

yang: Imported modules are not in use

configure.ac: fix sed failure on FreeBSD

Simplify the sed expression to make sure it works on all platforms.

The previous expression failed on FreeBSD and it caused the SNMP_LIBS
variable to be empty. When SNMP_LIBS is empty it will cause binaries
and/or libraries to not link against the correct libraries.

Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>

yang: Imported modules are not in use

Imported modules are not in use

Signed-off-by: y-bharath14 <y.bharath@samsung.com>

Merge pull request #18306 from LabNConsulting/aceelindem/bfd-log-session-changes

bfdd: Add "log-session-changes" command to BFD configuration and operational state via YANG Northbound API.

Merge pull request #18301 from pguibert6WIND/vpn_prefix_aggregate_export_and_accept

Vpn prefix aggregate export and accept

Merge pull request #18253 from dksharp5/yang_zebra

Allow retrieval of v4/v6 forwarding state via NB

Merge pull request #17961 from opensourcerouting/fix/bgp_reject_as_aggregate

bgpd: Do not advertise aggregate routes to contributing ASes

bfdd: Add BFD "log-session-changes" feature.

Add the BFD "log-session-changes" via the YANG and northbound API. Also
add the configured value to show and operational state.

Signed-off-by: Acee Lindem <acee@lindem.com>

yang: Add "log-session-changes" to BFD common session parameters.

Signed-off-by: Acee Lindem <acee@lindem.com>

doc: Add "log-session-changes" documentation.

Signed-off-by: Acee Lindem <acee@lindem.com>

tests: Add "log-session-changes" to bfd_topo1 r1 and r2 configs.

Signed-off-by: Acee Lindem <acee@lindem.com>

topotests: add a test to configure aggregated summary-only prefix on VPN

That configured aggregated prefix should be present, but all other
suppressed prefixes should not be exported.

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

bgpd: fix syncs suppressed prefixes in VPN environments

By using the summary-only option for aggregated prefixes, the suppressed
prefixes are however exported as VPN prefixes, whereas they should not.

> r1# show bgp vrf vrf1 ipv4
> [..]
>  *>  172.31.1.0/24    0.0.0.0                  0         32768 ?
>  s>  172.31.1.1/32    0.0.0.0                  0         32768 ?
>  s>  172.31.1.2/32    0.0.0.0                  0         32768 ?
>  s>  172.31.1.3/32    0.0.0.0                  0         32768 ?
> [..]
> r1#
>
> r1# show bgp ipv4 vpn
> [..]
>  *>  172.31.1.0/24    0.0.0.0@4<               0         32768 ?
>     UN=0.0.0.0 EC{52:100} label=101 type=bgp, subtype=5
>  *>  172.31.1.1/32    0.0.0.0@4<               0         32768 ?
>     UN=0.0.0.0 EC{52:100} label=101 type=bgp, subtype=5
>  *>  172.31.1.2/32    0.0.0.0@4<               0         32768 ?
>     UN=0.0.0.0 EC{52:100} label=101 type=bgp, subtype=5
>  *>  172.31.1.3/32    0.0.0.0@4<               0         32768 ?
>     UN=0.0.0.0 EC{52:100} label=101 type=bgp, subtype=5
> [..]
> r1#

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

topotests: add a test to unconfigure aggregated prefix on VPN

That test will ensure the VPN prefix associated is removed.

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

bgpd: fix remove vpn aggregated prefix upon unconfiguration

When unconfiguring an aggregated prefix, the VPN prefix is not
removed. Fix this by refreshing the VPN leak when the aggregated route
is or is not available.

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

topotests: add vpn test to control aggregated prefix is exported

Add a test in bgp_vpnv4_ebgp test to control that the aggregated prefix
is exported and selected as a VPN prefix.

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

bgpd: fix export, and selects l3vpn aggregated prefix

On a L3VPN setup, an aggretated prefix can not be exported and selected.
The below example illustrates the 172.31.0.0/24 aggregated prefix, which
is valid as a VRF prefix, but invalid as a VPN prefix:

> r1# show bgp ipv4 vpn 172.31.0.0/24
> BGP routing table entry for 444:1:172.31.0.0/24, version 0
> not allocated
> Paths: (1 available, no best path)
>   Not advertised to any peer
>   Local, (aggregated by 65500 192.0.2.1)
>     0.0.0.0 from 0.0.0.0 (192.0.2.1) vrf vrf1(4) announce-nh-self
>       Origin incomplete, metric 0, weight 32768, invalid, sourced,
local, atomic-aggregate
>       Extended Community: RT:52:100
>       Originator: 192.0.2.1
>       Remote label: 101
>       Last update: Mon Mar  3 14:35:04 2025
> r1# show bgp vrf vrf1 ipv4 172.31.0.0/24
> BGP routing table entry for 172.31.0.0/24, version 1
> Paths: (1 available, best #1, vrf vrf1)
>   Not advertised to any peer
>   Local, (aggregated by 65500 192.0.2.1)
>     0.0.0.0 from 0.0.0.0 (192.0.2.1)
>       Origin incomplete, metric 0, weight 32768, valid, aggregated,
local, atomic-aggregate, best (First path received)
>       Last update: Mon Mar  3 14:35:03 2025
> r1#

Actually, the aggregated prefix nexthop is considered, and 0.0.0.0 is
an invalid nexthop.

> r1# show bgp vrf vrf1 nexthop
> Current BGP nexthop cache:
>  0.0.0.0 invalid, #paths 1
>   Is not Registered
>   Last update: Thu Feb 13 18:33:43 2025

Fix this by considering the L3VPN prefix selected, if the VRF prefix
is selected too.

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

Merge pull request #18030 from fdumontet6WIND/mem_alloc_stream

zebra: reduce memory usage by streams when redistributing routes

Merge pull request #18294 from Orange-OpenSource/isisd

isisd: Correct edge insertion into TED

isisd: Correct edge insertion into TED

Edges are not correctly linked to Vertices during LSP processing. In function
lsp_to_edge_cb(), once edge created or updated from the LSP TLVs, the code try
to link the edge to destination vertices. In case the revert edge is not found,
the code try to found a destination vertex to link to. But, the sys_id used
for this operation corresponds to the source vertex. As a result, the edge is
attached as source and destination of the vertex. When Traffic Engineering is
stopped, TED is deleted which result into a double free of the edge attributes.
This cause a crash when attempt to free extended admin groupi the second time.

This patch removed wrong code which link twice the edge to the source vertex.

Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>

Merge pull request #18289 from cscarpitta/fix/fix_no_srv6_staticd

staticd: Fix `no srv6` command

Merge pull request #18290 from cscarpitta/fix/fix_frr_reload_static_sids

tools: Fix `frr-reload.py` error related to `static-sids`

ospfd: cosmetic change for one command

Just use the same style for all `DEFPY`s. It is a cosmetic change, doesn't
affect the actual function.

Signed-off-by: anlan_cs <anlan_cs@126.com>

tools: Fix `frr-reload.py` error related to `static-sids`

```
[...]
segment-routing
 srv6
  static-sids
   sid fcbb:bbbb:1::/48 locator MAIN behavior uN
   sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10
   sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20
   sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30
   sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
[...]
```

When the user has a configuration like the one above and runs the
command `frr-reload.py --reload`, the following error occurs:

```
[1129654|mgmtd] sending configuration
line 17: % Unknown command[76]:   sid fcbb:bbbb:1::/48 locator MAIN behavior uN
line 23: % Unknown command[76]:   sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10
line 29: % Unknown command[76]:   sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20
line 35: % Unknown command[76]:   sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30
line 41: % Unknown command[76]:   sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2
```

The problem is that in `frr-reload-py` all commands that start a new
multi-line context must be included in the `ctx_keyword` dictionary.
However, the `static-sids` command is not part of the `ctx_keyword`
dictionary.

This commit fixes the problem by adding `static-sids` to `ctx_keyword`.

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>

tests: Add test case to verify that SIDs can be re-added

Add a test case to verify that staticd is able to re-install all SIDs
after disabling and re-enabling SRv6.

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>

tests: Add test case to verify `no srv6` command

Add a test case to verify that staticd removes all SIDs when the
`no srv6` command is executed.

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>

staticd: Fix `no srv6` command

A user can configure static SIDs as follows:

[...]
segment-routing
 srv6
  static-sids
   sid fcbb:bbbb:1::/48 locator MAIN behavior uN
   sid fcbb:bbbb:1:fe00::/64 locator MAIN behavior uDT46
[...]

When the user runs vtysh and executes the `no srv6` command, the
expectation is that staticd will deallocate all SIDs.

However, currently FRR does not behaves as expected. After the user
executes `no srv6`, the SIDs are still present.

The problem is that vtysh does not forward the `no srv6` command to
mgmtd/staticd.

The `no srv6` command is defined using the `DEFUN_YANG_NOSH` macro,
which instructs `xref2vtysh.py` to skip the `no srv6` command during
the generation of `vtysh_cmd.c`. As a result, vtysh is unaware that it
should forward the `no srv6` command to mgmtd/staticd.

This commit fixes the issue by replacing `DEFUN_YANG_NOSH` with
`DEFUN_YANG`. This change ensures that `xref2vtysh.py` includes the
`no srv6` command when generating `vtysh_cmd.c` and makes vtysh forward
the `no srv6` command to mgmtd/staticd.

Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>

zebra: allow retrieval of ipv6 forwarding state

Allow the retrieval of ipv6 forwarding state from
within the yang framework as that it was missing.

Signed-off-by: Donna Sharp <dksharp5@gmail.com>

zebra: allow retrieval of ip forwarding state

There was no ability to retrieve the ip-forwarding state
of zebra.  Add this to yang under the state container.

Signed-off-by: Donna Sharp <dksharp5@gmail.com>

Merge pull request #18285 from opensourcerouting/pim-cs

pimd: fix null memory access on IGMP source limit

bgpd: Make keepalive pthread be connection based.

Again instead of making the keepalives be peer based
use the connection to make it happen.

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

bgpd: Convert bgp_keepalive_send to use a connection

The peer is going to eventually have a incoming and
outgoing connection.  Let's send the data based
upon the connection not the peer.

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

bgpd: Rename peer1 to just peer

The bgp_accept function was calling the existing
peer data structure peer1 for some reason.  Let's
just call it peer instead of peer1.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Call the doppelganger the doppelganger

Currently the code in bgp_accept is calling the
doppelganger `peer`.  This is confusing with
peer and peer1.  Let's just call it doppelganger.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Call newly created dynamic_peer appropriately

The dynamic peer being created is being called peer1
let's call it dynamic_peer instead.  This will make
what is being done clearer for future developers.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Change existing connection to be called connection

bgp_accept looks up the peer data structure.  The found
one represents the peer data structure that is created
when configuration is created.  This connection is being
called connection1.  Let's rename this to connection
to reduce some confusion.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Call the new doppelganger connection incoming

In bgp_accept, the newly created doppelganger is
accepting a connection and setting it up to work
properly.  For this incoming connection let's call
it incoming as well.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Call dyanmic peer incoming connection incoming

The bgp_accept code calls the different connections
connection and connection1.  Frankly this is confusing
and hard to keep track of what we are talking about
since they are poorly named.  Let's start naming
these variables things that make logical sense.

Author's Note:  I am changing the bgp_accept function
in this manner because I find it incredibly confusing
remembering what is what direction and all my other
attempts at getting this straight has caused real
problems.  So I am resorting to doing really small
transformational changes at a time.

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

bgpd: Add connection direction to debug logs

Currently the incoming and outgoing connections mix up their
logs and there is absolutely no way to tell which way is being
talked about when both are operating.

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

pimd: fix null memory access on IGMP source limit

When the IGMP group source limit is reached the function
`igmp_get_source_by_addr` won't return a `struct gm_source` so we must
test for that condition before attempting to access its fields.

Fixes coverity scan issue 1637406.

Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>

Merge pull request #18263 from cscarpitta/fix/add_no_form_for_static_sids_cli

staticd: Add `no` form for `static-sids` command

Merge pull request #18159 from pguibert6WIND/bgp_ecommlist_count

Bgp ecommlist count

topotests: add bgp ecommunity-list match test

Add a test suite that checks that it is possible to filter out
BGP updates based on the extcommunity-list match operation of the
route-map. Check also the extcommunity-limit option.

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

bgpd: add match ecommunity <exact|any> options

The exact-match and the any options are missing for the extended
communities. Add missing options that are present on the match
operations for communities and large-communities.

> route-map rmap permit 1
>  match extcommunity 1
> exit
> !
> route-map rmap permit 2
>  match extcommunity 2 any
> exit
> !
> route-map rmap permit 3
>  match extcommunity 3 exact-match
> exit

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

yang: enlarge community-limit count from [1-1024] to [0-1024]

It should be possible to configure the community-limit count to 0.

Fixes: f19b8668b3cb ("bgpd: add 'match community-count' command to restrict comm count")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

bgpd: add 'match extcommunity-count' command to restrict comm count

Add a mechanism in route-map to filter out route-map which have a list
of extended communities greater than the given number.

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