==2623619==
==2623619== 6 bytes in 1 blocks are definitely lost in loss record 3 of 75
==2623619== at 0x483877F: malloc (vg_replace_malloc.c:307)
==2623619== by 0x4B55E4A: strdup (strdup.c:42)
==2623619== by 0x493C992: qstrdup (memory.c:128)
==2623619== by 0x1A9212: isis_instance_fast_reroute_level_1_remote_lfa_prefix_list_modify (isis_nb_config.c:1599)
==2623619== by 0x494837C: nb_callback_modify (northbound.c:1083)
==2623619== by 0x4948C6E: nb_callback_configuration (northbound.c:1352)
==2623619== by 0x494919D: nb_transaction_process (northbound.c:1473)
==2623619== by 0x4947DA9: nb_candidate_commit_apply (northbound.c:906)
==2623619== by 0x4947EBA: nb_candidate_commit (northbound.c:938)
==2623619== by 0x494EB9E: nb_cli_classic_commit (northbound_cli.c:64)
==2623619== by 0x494F3DC: nb_cli_apply_changes_internal (northbound_cli.c:250)
==2623619== by 0x494F4E2: nb_cli_apply_changes (northbound_cli.c:268)
==2623619== by 0x1BEF0F: isis_frr_remote_lfa_plist_magic (isis_cli.c:1899)
==2623619== by 0x1B7636: isis_frr_remote_lfa_plist (isis_cli_clippy.c:3406)
==2623619== by 0x48EBA75: cmd_execute_command_real (command.c:997)
==2623619== by 0x48EBD4E: cmd_execute_command_strict (command.c:1108)
==2623619== by 0x48EC1E6: command_config_read_one_line (command.c:1268)
==2623619== by 0x48EC35B: config_from_file (command.c:1313)
==2623619== by 0x4999CC1: vty_read_file (vty.c:2347)
==2623619== by 0x499A4AF: vty_read_config (vty.c:2567)
==2623619== by 0x4924B12: frr_config_read_in (libfrr.c:984)
==2623619== by 0x498F5E3: thread_call (thread.c:2008)
==2623619== by 0x49253DA: frr_run (libfrr.c:1198)
==2623619== by 0x14FC53: main (isis_main.c:273)
Fix this memory leak
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Changing
IGMP_DEFAULT_ROBUSTNESS_VARIABLE to GM_DEFAULT_ROBUSTNESS_VARIABLE,
IGMP_GENERAL_QUERY_INTERVAL to GM_GENERAL_QUERY_INTERVAL,
IGMP_QUERY_MAX_RESPONSE_TIME_DSEC to GM_QUERY_MAX_RESPONSE_TIME_DSEC and
IGMP_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC to GM_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC
to accomodate both igmp and mld. And moved it to common file.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Before returning an error, unlock bgp dest which is locked by
bgp_node_lookup()/bgp_node_get().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
See the BGP message sequence:
R1 R2
| updates |
|------------------>|
| |
| refresh request |
x<------------------|
| |
| updates cont. |
|------------------>|
| |
| end-of-rib |
|------------------>|
| |
When R1 and R2 establish BGP session, R1 begins to send initial updates.
If R2 sends a route-refresh request before EoR, it's silently ignored
by R1, and routes received earlier have no chance to be processed again.
RFC7313 says, "for a BGP speaker that supports the BGP Graceful Restart,
it MUST NOT send a BoRR for an <AFI, SAFI> to a neighbor before it sends
the EoR for the <AFI, SAFI> to the neighbor." But it doesn't forbid
route-refresh request to be sent before receiving EoR.
To handle this scenario, postpone response to refresh request until EoR
is sent.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
After restart pim dr address was zero due to which pim (*,G) join
could not get propagated towards RP.
While trying to find primary address ll_highest will be zero initially,
since we have not received address from zebra yet.
So we can get the best address at this point and use it as primary address
whenever ll_highest is zero.
Fixes: #11925
Signed-off-by: Abhishek N R <abnr@vmware.com>
Root Cause:
"clear ipv6 mroute" was not deleting the subscribers of gm_if
structure.
Fix:
The command "clear ipv6 mroute" deletes grp_pends, gsq_pends, sgs,
subscribers, expires of gm_if data structure.
Deleted the common code in gm_ifp_teardown() and called
gm_group_delete().
Issue: #11724
Signed-off-by: Sarita Patra <saritap@vmware.com>
When bulk deleting prefix lists on shutdown the code
was calling plist_delete, which removed the item
from the master->str list, and then popping the next
item on the list and just dropping it on the floor.
The pop is not needed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Changed PIM_DEBUG_IGMP_TRACE to PIM_DEBUG_GM_TRACE and
PIM_DEBUG_IGMP_TRACE_DETAIL to PIM_DEBUG_GM_TRACE_DETAIL.
Hence, these macros can be used for both v6 and v4.
Issue: #11895
Co-authored-by: Sai Gomathi N <nsaigomathi@vmware.com>
Signed-off-by: Abhishek N R <abnr@vmware.com>
