Contraints of host routes are too strict in current code:
Host routes with same destination address and nexthop address are forbidden
even when cross VRFs.
Currently host routes with different destination and nexthop address can cross
VRFs, it is ok. But host routes with same addresses are forbidden to cross VRFs,
it is wrong.
Since different VRFs can have the same addresses, leak specific host route with
the same nexthop address ( it means destination address is same to nexthop
address ) to other VRFs is a normal case.
This commit relaxes that contraints. Host routes with same destination address
and nexthop address are forbidden only when not cross VRFs.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When an interface goes down, it signals any related NHGs to
re-validate themselves. During zebra shutdown, ensure we remove
any NHGs we've installed.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
In `zebra_evpn_neigh_gw_macip_add()`, it sets `mac->flags` to "ZEBRA_MAC_DEF_GW"
for "advertise-default-gw" mode. But this set is redundant because this "mac"
is already set by `zebra_evpn_mac_gw_macip_add()`.
So remove this redundant assignment.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Added this api to fill all multicast group address based on IP version.
For PIMv4 its 224.0.0.0/4, for PIMv6 its FF00::0/8.
Changed the code where its being used currently.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Pass pim_addr as parameter for rp address to accomodate ipv6.
Modifying pim_rp_cmd_worker and pim_no_rp_cmd_worker function
parameters from in_addr to pim_addr.
Changes in the caller functions are done as well to make it work
for IPv6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. Return value of this function pim_rp_del_config is nowhere used.
So made it as a void function.
2. Paramater const char *rp is first converted to string from prefix
in the caller and then back to prefix in this api pim_rp_del_config.
Fixed it by directly passing the address instead of string.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. Moving the processing of the above command to an api.
2. Change DEFUN to DEPFY
3. Make the api common for pimv4 and pimv6 processing.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Modify the apis pim_process_rp_cmd and pim_process_no_rp_cmd
to accomodate ipv4 as well as ipv6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The pattern defined for ipv6-multicast-group-prefix is wrong.
This is leading to mismatch for all the valid ipv6 multicast
addresses.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The vtysh live logs don't try to buffer messages when vtysh isn't
reading them fast enough. Either the kernel has space and can accept
messages without delay, or it doesn't and we continue on.
While this is intentional (otherwise slow vtysh could block a routing
daemon), at least give the user an indication if messages were dropped.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This provides direct raw log output with full metadata directly at
startup regardless of configuration details.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This was the intent here to begin with, not sure where I managed to
forget this along the way...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The timestamps used for the live log are wallclock, not monotonic. Also
some fields were left uninitialized.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Commit: ea47320b1d
Modified the bgp_clear_stale_route function to have
better indentation, but in the process changed some
`continue;` statements to `break;` which modified
the looping and caused stale paths to not always be
removed upon an update.
To reproduce: A ---- B, setup with addpath and GR
One side has a prefix with nhop1 and nhop2, kill one
side and then resend the same prefix with nhop3,
paths nhop1 and 2 become stale and never removed.
Code inspection clearly shows that that `continue`
statements became `break` statements causing the
loop over all paths to stop prematurely.
The fix is to change the break back to continue
statements so the loop can continue instead of
stopping.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
While running singlethreaded, the RCU code is "dormant" and rcu_free is
an immediate operation. This results in the log target loop accessing
free'd memory if a log target removes itself while a message is printed
(which is likely to happen on e.g. error conditions.)
Just use frr_each_safe to avoid this issue.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
