Description:
===========
Change is intended for fixing the NHT resolution logic.
While recursively resolving nexthop, keep looking for a valid/useable route in the rib,
by not stopping at the first/most-specific route in the rib.
Consider the following set of events taking place on R1:
R1(config)# ip route 2.2.2.0/24 ens192
R1# sharp watch nexthop 2.2.2.32 connected
R1# show ip nht
2.2.2.32(Connected)
resolved via static
is directly connected, ens192
Client list: sharp(fd 33)
-2.2.2.32 NHT is resolved over the above valid static route.
R1# sharp install routes 2.2.2.32 nexthop 2.2.2.32 1
R1# 2.2.2.32(Connected)
resolved via static
is directly connected, ens192
Client list: sharp(fd 33)
-.32/32 comes which is going to resolve through itself, but since this is an invalid route,
it will be marked as inactive and will not affect the NHT.
R1# sharp install routes 2.2.2.31 nexthop 2.2.2.32 1
R1# 2.2.2.32(Connected)
unresolved(Connected)
Client list: sharp(fd 50)
-Now a .31/32 comes which will resolve over .32 route, but as per the current logic,
this will trigger the NHT check, in turn making the NHT unresolved.
-With fix, NHT should stay in resolved state as long as the valid static or connected route stays installed
Fix:
====
-While resolving nexthops, walk up the tree from the most-specific match,
walk up the tree without any ZEBRA_NHT_CONNECTED check.
Co-authored-by: Vishal Dhingra <vdhingra@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Intentionally up convert uint8_t and uint32_t values
to a uint64_t before doing math to make Coverity happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If time ( a uint64_t ) is large enough doing division
and subtraction can still lead to situations where
the resulting number is greater than a uint32_t.
Just use uint32_t as an intermediate storage spot.
This is unlikely to every occur in a time frame
I could possibly care about but makes Coverity happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
assert when if_lookup_address is passed with
a family that is not AF_INET or AF_INET6 as
that we are dead in the water and this is a
dev escape
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When running a topotest with the --shell or --vtysh argument, the
window titles of the routers are generic.
Set the router name as title to identify correctly the window.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Opening new tab in screen is not possible when using option --vtysh or
--shell. Error 'No such file or directory'.
Fix the issue.
Fixes: 6a5433ef0b ("tests: NEW micronet replacement for mininet")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
224.0.0.0/24 cannot be used by igmp since this is reserved
for routing protocols and other low-level topology discovery or
maintenance protocols.
Fixes: #10614
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Restrict the number of nexthops for a route to the compiled-in
limit. Be careful with the zapi route struct's array of nexthops
too.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
noticed that pylint was complaining about some easily
fixable stuff in test_route_map_topo1.py so let's clean
it up some.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This creates `pim6_stubs.c`, which is intended to temporarily provide
stubbed-out definitions of some functions we don't have yet for IPv6.
This makes pim6d compile without the `PIM_V6_TEMP_BREAK` hack, and is
very important as an intermediate step to get a working environment for
further work.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is just hitting the pim_mroute code with a hammer until it doesn't
print warnings anymore. This is NOT quite tested or working yet, it
just compiles.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
