This allows eliminating the superfluous yang_data object (which
is getting created used to call lyd_new_term then deleted). Instead
just call lyd_new_term() in the callback directly.
Signed-off-by: Christian Hopps <chopps@labn.net>
The users would know the failure of some case for the two commands, just
return the error ```CMD_WARNING_CONFIG_FAILED```.
Signed-off-by: anlan_cs <anlan_cs@126.com>
This was reused with BGP_NEXTHOP_ULTIMATE by error.
Fixes: 93fd9cbb50 ("bgpd: Validate imported routes next-hop that is in a default VRF")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
"ip/ipv6 protocol any route-map <route map>" cli is setting
wrong route type ( ZEBRA_ROUTE_MAX ), It should set route type
ZEBRA_ROUTE_ALL.
Ticket: #4101560
Signed-off-by: Sougata Barik <sougatab@nvidia.com>
Fixing compilation error in a switch statement case
Fixes :aa4786642c9a65c282d0fd5247a35b0f14fa1c3c
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
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>
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>
If Duplicate Address Detection action is freeze
(permanent or definite time means not warn only mode)
then locally duplicate detected MAC delete notification
is not require to inform,
instead ask BGP to sync previous remote MAC entry.
In freeze case local MAC event is not known to BGP,
instead BGP is pointing to remote VTEP for the MAC.
Ticket: #3652383
Issue: 3652383
Signed-off-by: Chirag Shah <chirag@nvidia.com>
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>
Add a test to control the peer up and down message sent when the route
distinguisher is updated.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
