fixes the recent support bmp monitor of VPNv4 afi/safi
the bmp updates messages (MP_REACH_NLRI) are never sent for VPNv4 and bmp withdraws (MP_UNREACH_NRLI) are sent instead
this is caused by bgp_node_lookup which fails to find VPNv4 bgp_node in the rib which results in NULL path info attributes passed to bmp_monitor
using bgp_afi_node_lookup instead of bgp_node_lookup solves the problem
Signed-off-by: Maxence Younsi <mx.yns@outlook.fr>
Do not forget to cleanup after we are done:
==395247== 8,268 (32 direct, 8,236 indirect) bytes in 1 blocks are definitely lost in loss record 199 of 205
==395247== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==395247== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1FBF63: community_intern (in /usr/lib/frr/bgpd)
==395247== by 0x1FC0C5: community_parse (in /usr/lib/frr/bgpd)
==395247== by 0x1F0B66: bgp_attr_community (in /usr/lib/frr/bgpd)
==395247== by 0x1F4185: bgp_attr_parse (in /usr/lib/frr/bgpd)
==395247== by 0x26BC29: bgp_update_receive (in /usr/lib/frr/bgpd)
==395247== by 0x26E887: bgp_process_packet (in /usr/lib/frr/bgpd)
==395247== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 94 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD3CC: bgp_ca_alias_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8E5: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==361630==
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 95 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD39C: bgp_ca_community_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8F4: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
According to RFC9234:
An UPDATE message with a malformed OTC Attribute SHALL be handled
using the approach of "treat-as-withdraw".
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
- ignore parent from daemonize valgrind files these allocations will be
checked in the child.
- check for memleaks at end of module/file not just after tests.
Signed-off-by: Christian Hopps <chopps@labn.net>
The API pim_rp_check_interface_addrs checks if the RP address matches
with the primary address then it returns true.
In case of PIMv4 this condition is true, therefore the router becomes RP.
But in case of PIMv6, this condition does not pass because primary address
for PIMv6 is link-local address.
Also PIMv4 allows secondary addresses to be used as RP
if it is a host route in case primary does not match.
Fixing it by only checking the configured
RP address with the interface address and ignoring the prefix
length since it does not matter.
Fixes: #11335
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
In several places, we are getting the vrf structure using
vrf_lookup_by_name(). Again we are passing vrf->vrf_id to
pim_get_pim_instance() to get the pim_instance.
The API pim_get_pim_instance() again get the VRF structure using
vrf_lookup_by_id(). This is avoided in this PR.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Longest possible length of a IPV6 (S,G) string is 94 bytes
INET6_ADDRSTRLEN * 2 = 46 * 2
(,) = 1
NULL Character at end = 1
Signed-off-by: Sarita Patra <saritap@vmware.com>
These are in packed structs at weird offsets (e.g. 2 bytes), and as such
need a memcpy to get them into proper alignment.
It'd be even better if the pimd code used proper de/serialization, but
let's get this improved one step at a time.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
