Modifying igmp_group_count of struct pim_instance
to gm_group_count which is to be used for both IGMP and MLD.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Before:
```
$ vtysh -c 'show bgp l2vpn evpn route detail json'
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
{
...
"numPrefix":4,
"numPaths":4 <<<<< four paths = four empty lines
}
```
Contain as much "empty lines" before the JSON string as the number
of paths displayed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When calling time(NULL), FRR is intentionally throwing
away the upper 32 bits of value returned. Let's explicitly
call it out so that coverity understands this is intentional
and ok.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let's convert to our actual library call instead
of using yet another abstraction that makes it fun
for people to switch daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 routes
(seg6 and seg6local routes) are handled: when the user executes the CLI
command `sharp install seg6-routes` or `sharp install seg6local-routes`
to create a seg6 or seg6local route, sharpd calls
`nexthop_add_srv6_seg6` or `nexthop_add_srv6_seg6local` to create an
SRv6 nexthop. A pointer to the SRv6 nexthop is stored in the global data
structure `sg.r.nhop`. If you call `sharp install routes`,
`sharp install seg6-routes` or `sharp install seg6local-routes` to create
more routes, `sg.r.nhop` is set to zero and the
pointer to the SRv6 nexthop contained in `sg.r.nhop` is definitely lost
and the allocated memory is never freed.
This patch adds calls to `nexthop_del_srv6_seg6()` and
`nexthop_del_srv6_seg6local()` to free the memory allocated for the SRv6
nexthop before clearing the `sg.r.nhop` data structure.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, the `list_delete()` function is called to delete the
chunks list (`loc->chunks`), but the memory allocated for the chunks is
not freed.
This patch defines a new callback `sharp_srv6_locator_chunk_free()`.
This callback takes care of freeing the memory allocated for a given
chunk. When `list_delete()` is called to remove the chunk list
`loc->chunks`, it automatically calls `sharp_srv6_locator_chunk_free()`
on each element of the list to free the allocated memory before
deleting the list.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, all the chunks are removed from the list `loc->chunks`.
Also, the locator is removed from the SRv6 locators list
`sg.srv6_locators`, but the memory allocated for the locator is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when all the chunks of an SRv6 locator are removed and the
locator is removed as well.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running `bgp_srv6l3vpn_to_bgp_vrf` and `bgp_srv6l3vpn_to_bgp_vrf2`
topotests with `--valgrind-memleaks` gives several memory leak errors.
This is due to the way SRv6 locators are removed/unset in bgpd: when
an SRv6 locator is deleted or unset, the memory allocated for the
locator prefix (`tovpn_sid_locator`) is not freed.
This patch adds a `for` loop that iterates over the list of BGP
instances. For each BGP instance using the SRv6 locator to be
removed/unset, we use `XFREE()` to properly free the memory allocated
for `tovpn_sid_locator` after the SRv6 locator is removed or unset.
The memory allocated for `tovpn_sid_locator` cannot be freed before
calling `vpn_leak_postchange_all()`. This is because
after deleting an SRv6 locator, we call `vpn_leak_postchange_all()`
to handle the SRv6 locator deletion and send a BGP Prefix SID withdraw
message. `tovpn_sid_locator` is required to properly build the BGP
Prefix SID withdraw message. After calling `vpn_leak_postchange_all()`
we can safely remove the `tovpn_sid_locator` and free the allocated
memory.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
