At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the route distinguisher set to 0:0.
Actually, the route distinguisher has been updated after the peer up
message is sent, and the information is not refreshed.
Create a hook API to handle route distinguisher config events: pre and
post configuration. Use that hook in BMP module to send peer down, and
peer up events when necessary.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the router-id set to 0.0.0.0.
Actually, the router-id has been updated after the peer up
message is sent, and the information is not refreshed.
Create a hook API to handle router id events: withdraw and
updates. Use that hook in BMP module to send peer down, and
peer up events when necessary.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no need to create the bgp bmp instance, while there
is no bmp target to send data to.
Rewrite the code by using bgp_bmp_find() API instead.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test where, when the vrf interface is flapping, a peer down and a
peer up message are sent. This test, when used with ASAN, detects the
memory leak of the open_tx and open_rx messages of the loc-rib.
Refresh the method of updating the SEQ value when reading the peer
messages: only update to the last matching SEQ value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following memory leak can be observed when turning off and on the
BGP vrf interface.
> ==706056==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
> #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
> #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
> #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
> #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
> #4 0x7fbf5bdeaa1c in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3204
> #5 0x562740f0d83f in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64
> #6 0x562740f0ee28 in bgp_ifp_up bgpd/bgp_zebra.c:234
> #7 0x7fbf5f01c193 in hook_call_if_up lib/if.c:57
> #8 0x7fbf5f01d09a in if_up_via_zapi lib/if.c:203
> #9 0x7fbf5f1d6f54 in zclient_interface_up lib/zclient.c:2671
> #10 0x7fbf5f1e3e5a in zclient_read lib/zclient.c:4624
> #11 0x7fbf5f18078d in event_call lib/event.c:1996
> #12 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
> #13 0x562740c0cae1 in main bgpd/bgp_main.c:557
> #14 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
>
> Direct leak of 78 byte(s) in 1 object(s) allocated from:
> #0 0x7fbf5f6b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
> #1 0x7fbf5f0771f8 in qmalloc lib/memory.c:101
> #2 0x7fbf5bdde610 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2042
> #3 0x7fbf5bdde8aa in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2079
> #4 0x7fbf5bdd4839 in bmp_send_peerup_vrf bgpd/bgp_bmp.c:627
> #5 0x7fbf5bddb0d3 in bmp_wrfill bgpd/bgp_bmp.c:1590
> #6 0x7fbf5f10841f in pullwr_run lib/pullwr.c:197
> #7 0x7fbf5f18078d in event_call lib/event.c:1996
> #8 0x7fbf5f048933 in frr_run lib/libfrr.c:1232
> #9 0x562740c0cae1 in main bgpd/bgp_main.c:557
> #10 0x7fbf5ea29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Fix this by freeing the previous open_tx and open_rx contexts before
setting up the new one. Also at deletion of peer, free the open_rx
context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a BGP listener configured with BMP receives the first BGP
IPv6 update from a connected BGP IPv6 peer, the BMP collector
receives a withdraw post-policy message.
> {"peer_type": "route distinguisher instance", "policy": "post-policy",
> "ipv6": true, "peer_ip": "192:167::3", "peer_distinguisher": "444:1",
> "peer_asn": 65501, "peer_bgp_id": "192.168.1.3", "timestamp":
> "2024-10-29 11:44:47.111962", "bmp_log_type": "withdraw", "afi": 2,
> "safi": 1, "ip_prefix": "2001::1125/128", "seq": 22}
> {"peer_type": "route distinguisher instance", "policy": "pre-policy",
> "ipv6": true, "peer_ip": "192:167::3", "peer_distinguisher": "444:1",
> "peer_asn": 65501, "peer_bgp_id": "192.168.1.3", "timestamp":
> "2024-10-29 11:44:47.111963", "bmp_log_type": "update", "origin":
> "IGP", "as_path": "", "afi": 2, "safi": 1, "nxhp_ip": "192:167::3",
> "nxhp_link-local": "fe80::7063:d8ff:fedb:9e11", "ip_prefix": "2001::1125/128", "seq": 23}
Actually, the BGP update is not valid, and BMP considers it as a
withdraw message. The BGP upate is not valid, because the nexthop
reachability is unknown at the time of reception, and no other
BMP message is sent.
Fix this by re-sending a BMP post update message when nexthop
tracking becomes successfull. Generalise the re-sending of
messages when nexthop tracking changes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following warning can be seen:
> In file included from ./bgpd/bgp_trace.h:21,
> from bgpd/bgp_io.c:27:
> bgpd/bgp_io.c: In function ‘read_ibuf_work’:
> bgpd/bgp_io.c:202:53: warning: passing argument 1 of ‘lttng_ust_tracepoint_cb_frr_bgp___packet_read’ from incompatible pointer type [-Wincompatible-pointer-types]
> 202 | frrtrace(2, frr_bgp, packet_read, connection->peer, pkt);
> | ~~~~~~~~~~^~~~~~
> | |
> | struct peer *
> bgpd/bgp_io.c:202:9: note: in expansion of macro ‘frrtrace’
> 202 | frrtrace(2, frr_bgp, packet_read, connection->peer, pkt);
> | ^~~~~~~~
> In file included from ./bgpd/bgp_trace.h:21,
> from bgpd/bgp_io.c:27:
> ./bgpd/bgp_trace.h:57:43: note: expected ‘struct peer_connection *’ but argument is of type ‘struct peer *’
> 57 | TP_ARGS(struct peer_connection *, connection, struct stream *, pkt),
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
Use the appropriate connection parameter when calling the trace.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When stopping and restarting BGP daemon part of the configuration
remains. It should be cleared.
Particulary those are address-family parametes, like: distance,
ead-es-frag, disable-ead-evi-rx, disable-ead-evi-tx.
Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>
The rpki current state was ignored when calling for the 'show bgp ipvX
detail' command. Handle the support for this, with json support too.
> "rpkiValidationState" : "valid",
> "rpkiValidationState" : "invalid",
> "rpkiValidationState" : "not used",
> "rpkiValidationState" : "not found",
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
When reloading the following configuration:
```
segment-routing
srv6
formats
format usid-f3216
wide-local-id-block explicit start 100
exit
!
format uncompressed-f4024
exit
!
exit
!
exit
!
exit
```
frr-reload.py does not properly enter the `formats` context. Because of this,
it fails with an unknown command error when applying new or updating format
configuration.
Signed-off-by: Jonathan Voss <jvoss@onvox.net>
`srv6_static_route` is a pure staticd topotest. It does not have any
dependency on bgpd and sharpd.
Let's fix the pytestmark to include only staticd.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This test was not actually failing when the results didn't match. Fail
now. Also fix the tests that are now found to be failing incorrectly
(wrong expected result).
Signed-off-by: Christian Hopps <chopps@labn.net>
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: 322462920e ("bgpd: Enable enforce-first-as by default")
Closes: https://github.com/FRRouting/frr/issues/17702
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Compile error with `--disable-ripd`:
```
mgmtd/mgmt_be_adapter.c:86:5: error: "HAVE_RIPD" is not defined, evaluates to 0 [-Werror=undef]
86 | #if HAVE_RIPD
| ^~~~~~~~~
```
I have searched the code, there is only three places need to be fixed.
Signed-off-by: anlan_cs <anlan_cs@126.com>
The documentation should provide the valid range of SRv6 locator
node-len parameter, rather than the default value.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The documentation should provide the valid range of SRv6 locator
block-len parameter, rather than the default value.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Align the order of the SRv6 locator parameters with the actual implementation:
```
"prefix X:X::X:X/M$prefix [block-len (16-64)$block_bit_len] \
[node-len (16-64)$node_bit_len] [func-bits (0-64)$func_bit_len]"
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
