The peer distinguisher format was badly displayed when a per peer
header is sent with an IP:AS2B format.
> {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "None:2", ...
The IP header is incorrectly read. Fix it.
> {"peer_type": "loc-rib instance", "is_filtered": false, "policy": "loc-rib",
> "peer_distinguisher": "3.3.3.5:2", ...
Fixes: 875511c466 ("topotests: add basic bmp collector")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test to control the value of the peer bgp id of loc-rib peer up
messages when the bgp router-id is reconfigured.
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 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>
`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>
For JSON output we don't need newline to be printed.
Before:
```
"lastUpdate":{"epoch":1734490463,"string":"Wed Dec 18 04:54:23 2024\n"
```
After:
```
"lastUpdate":{"epoch":1734678560,"string":"Fri Dec 20 09:09:20 2024"
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
newline is not expected to be printed in JSON outputs, e.g.:
```
"lastUpdate":{"epoch":1734490463,"string":"Wed Dec 18 04:54:23 2024\n"
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When deactivating babel no router babel and later re-enabling
it router babel the previous configuration is still in place.
Steps to reproduce:
- Enable babel
- Configure babel
- Disable babel with "no router babel"
- Verify config
Expected correct behavior: No config present
Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>