[PATCH net-next 0/5] ipv6: Allow for nexthop device mismatch with "onlink"

[PATCH net-next 0/5] ipv6: Allow for nexthop device mismatch with "onlink"

[Ido Schimmel]

This patchset aligns IPv6 with IPv4 with respect to the "onlink" keyword
and allows IPv6 routes to be configured with a gateway address that is
resolved out of a different interface than the one specified.

Patches #1-#3 are small preparations in the existing "onlink" selftest.

Patch #4 is the actual change. See the commit message for detailed
description and motivation.

Patch #5 adds test cases for both address families, to make sure that
this use case does not regress.

Ido Schimmel (5):
  selftests: fib-onlink: Remove "wrong nexthop device" IPv4 tests
  selftests: fib-onlink: Remove "wrong nexthop device" IPv6 tests
  selftests: fib-onlink: Add a test case for IPv4 multicast gateway
  ipv6: Allow for nexthop device mismatch with "onlink"
  selftests: fib-onlink: Add test cases for nexthop device mismatch

 net/ipv6/route.c                              |  7 ++---
 .../testing/selftests/net/fib-onlink-tests.sh | 28 +++++++++----------
 2 files changed, 16 insertions(+), 19 deletions(-)

-- 
2.52.0

[PATCH net-next 1/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv4 tests

[Ido Schimmel]

According to the test description, these tests fail because of a wrong
nexthop device:

 # ./fib-onlink-tests.sh -v
 [...]
 COMMAND: ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth1 onlink
 Error: Nexthop has invalid gateway.

 TEST: Gateway resolves to wrong nexthop device            [ OK ]
 COMMAND: ip ro add table 1101 169.254.102.103/32 via 169.254.7.1 dev veth5 onlink
 Error: Nexthop has invalid gateway.

 TEST: Gateway resolves to wrong nexthop device - VRF      [ OK ]
 [...]

But this is incorrect. They fail because the gateway addresses are local
addresses:

 # ip -4 address show
 [...]
 28: veth3@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netns peer_ns-Urqh3o
     inet 169.254.3.1/24 scope global veth3
 [...]
 32: veth7@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lisa state UP group default qlen 1000 link-netns peer_ns-Urqh3o
     inet 169.254.7.1/24 scope global veth7

Therefore, using a local address that matches the nexthop device fails
as well:

 # ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth3 onlink
 Error: Nexthop has invalid gateway.

Using a gateway address with a "wrong" nexthop device is actually valid
and allowed:

 # ip route get 169.254.1.2
 169.254.1.2 dev veth1 src 169.254.1.1 uid 0
 # ip ro add table 254 169.254.101.102/32 via 169.254.1.2 dev veth3 onlink
 # echo $?
 0

Remove these tests given that their output is confusing and that the
scenario that they are testing is already covered by other tests.

A subsequent patch will add tests for the nexthop device mismatch
scenario.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 tools/testing/selftests/net/fib-onlink-tests.sh | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index ec2d6ceb1f08..1bb1c2289650 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -315,12 +315,6 @@ invalid_onlink_ipv4()
 		"Invalid gw - local unicast address, VRF"
 
 	run_ip 254 ${TEST_NET4[1]}.101 ${V4ADDRS[p1]} "" 2 "No nexthop device given"
-
-	run_ip 254 ${TEST_NET4[1]}.102 ${V4ADDRS[p3]} ${NETIFS[p1]} 2 \
-		"Gateway resolves to wrong nexthop device"
-
-	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.103 ${V4ADDRS[p7]} ${NETIFS[p5]} 2 \
-		"Gateway resolves to wrong nexthop device - VRF"
 }
 
 ################################################################################
-- 
2.52.0

Re: [PATCH net-next 1/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv4 tests

[David Ahern]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> According to the test description, these tests fail because of a wrong
> nexthop device:
> 
>  # ./fib-onlink-tests.sh -v
>  [...]
>  COMMAND: ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth1 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Gateway resolves to wrong nexthop device            [ OK ]
>  COMMAND: ip ro add table 1101 169.254.102.103/32 via 169.254.7.1 dev veth5 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Gateway resolves to wrong nexthop device - VRF      [ OK ]
>  [...]
> 
> But this is incorrect. They fail because the gateway addresses are local
> addresses:
> 
>  # ip -4 address show
>  [...]
>  28: veth3@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netns peer_ns-Urqh3o
>      inet 169.254.3.1/24 scope global veth3
>  [...]
>  32: veth7@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lisa state UP group default qlen 1000 link-netns peer_ns-Urqh3o
>      inet 169.254.7.1/24 scope global veth7
> 
> Therefore, using a local address that matches the nexthop device fails
> as well:
> 
>  # ip ro add table 254 169.254.101.102/32 via 169.254.3.1 dev veth3 onlink
>  Error: Nexthop has invalid gateway.
> 
> Using a gateway address with a "wrong" nexthop device is actually valid
> and allowed:
> 
>  # ip route get 169.254.1.2
>  169.254.1.2 dev veth1 src 169.254.1.1 uid 0
>  # ip ro add table 254 169.254.101.102/32 via 169.254.1.2 dev veth3 onlink
>  # echo $?
>  0
> 
> Remove these tests given that their output is confusing and that the
> scenario that they are testing is already covered by other tests.
> 
> A subsequent patch will add tests for the nexthop device mismatch
> scenario.
> 
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  tools/testing/selftests/net/fib-onlink-tests.sh | 6 ------
>  1 file changed, 6 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>

[PATCH net-next 2/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv6 tests

[Ido Schimmel]

The command in the test fails as expected because IPv6 forbids a nexthop
device mismatch:

 # ./fib-onlink-tests.sh -v
 [...]
 COMMAND: ip -6 ro add table 1101 2001:db8:102::103/128 via 2001:db8:701::64 dev veth5 onlink
 Error: Nexthop has invalid gateway or device mismatch.

 TEST: Gateway resolves to wrong nexthop device - VRF      [ OK ]
 [...]

Where:

 # ip route get 2001:db8:701::64 vrf lisa
 2001:db8:701::64 dev veth7 table 1101 proto kernel src 2001:db8:701::1 metric 256 pref medium

This is in contrast to IPv4 where a nexthop device mismatch is allowed
when "onlink" is specified:

 # ip route get 169.254.7.2 vrf lisa
 169.254.7.2 dev veth7 table 1101 src 169.254.7.1 uid 0
 # ip ro add table 1101 169.254.102.103/32 via 169.254.7.2 dev veth5 onlink
 # echo $?
 0

Remove these tests in preparation for aligning IPv6 with IPv4 and
allowing nexthop device mismatch when "onlink" is specified.

A subsequent patch will add tests that verify that both address families
allow a nexthop device mismatch with "onlink".

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 tools/testing/selftests/net/fib-onlink-tests.sh | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index 1bb1c2289650..63477be859e3 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -432,13 +432,6 @@ invalid_onlink_ipv6()
 
 	run_ip6 254 ${TEST_NET6[1]}::101 ${V6ADDRS[p1]} "" 2 \
 		"No nexthop device given"
-
-	# default VRF validation is done against LOCAL table
-	# run_ip6 254 ${TEST_NET6[1]}::102 ${V6ADDRS[p3]/::[0-9]/::64} ${NETIFS[p1]} 2 \
-	#	"Gateway resolves to wrong nexthop device"
-
-	run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::103 ${V6ADDRS[p7]/::[0-9]/::64} ${NETIFS[p5]} 2 \
-		"Gateway resolves to wrong nexthop device - VRF"
 }
 
 run_onlink_tests()
-- 
2.52.0

Re: [PATCH net-next 2/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv6 tests

[David Ahern]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> The command in the test fails as expected because IPv6 forbids a nexthop
> device mismatch:
> 
>  # ./fib-onlink-tests.sh -v
>  [...]
>  COMMAND: ip -6 ro add table 1101 2001:db8:102::103/128 via 2001:db8:701::64 dev veth5 onlink
>  Error: Nexthop has invalid gateway or device mismatch.
> 
>  TEST: Gateway resolves to wrong nexthop device - VRF      [ OK ]
>  [...]
> 
> Where:
> 
>  # ip route get 2001:db8:701::64 vrf lisa
>  2001:db8:701::64 dev veth7 table 1101 proto kernel src 2001:db8:701::1 metric 256 pref medium
> 
> This is in contrast to IPv4 where a nexthop device mismatch is allowed
> when "onlink" is specified:
> 
>  # ip route get 169.254.7.2 vrf lisa
>  169.254.7.2 dev veth7 table 1101 src 169.254.7.1 uid 0
>  # ip ro add table 1101 169.254.102.103/32 via 169.254.7.2 dev veth5 onlink
>  # echo $?
>  0
> 
> Remove these tests in preparation for aligning IPv6 with IPv4 and
> allowing nexthop device mismatch when "onlink" is specified.
> 
> A subsequent patch will add tests that verify that both address families
> allow a nexthop device mismatch with "onlink".
> 
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  tools/testing/selftests/net/fib-onlink-tests.sh | 7 -------
>  1 file changed, 7 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>

[PATCH net-next 3/5] selftests: fib-onlink: Add a test case for IPv4 multicast gateway

[Ido Schimmel]

A multicast gateway address should be rejected when "onlink" is
specified, but it is only tested as part of the IPv6 tests. Add an
equivalent IPv4 test.

 # ./fib-onlink-tests.sh -v
 [...]
 COMMAND: ip ro add table 254 169.254.101.12/32 via 233.252.0.1 dev veth1 onlink
 Error: Nexthop has invalid gateway.

 TEST: Invalid gw - multicast address                      [ OK ]
 [...]
 COMMAND: ip ro add table 1101 169.254.102.12/32 via 233.252.0.1 dev veth5 onlink
 Error: Nexthop has invalid gateway.

 TEST: Invalid gw - multicast address, VRF                 [ OK ]
 [...]
 Tests passed:  37
 Tests failed:   0

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 tools/testing/selftests/net/fib-onlink-tests.sh | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index 63477be859e3..7a0fd7a91e4e 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -72,7 +72,8 @@ declare -A TEST_NET4IN6IN6
 TEST_NET4IN6[1]=10.1.1.254
 TEST_NET4IN6[2]=10.2.1.254
 
-# mcast address
+# mcast addresses
+MCAST4=233.252.0.1
 MCAST6=ff02::1
 
 VRF=lisa
@@ -310,9 +311,13 @@ invalid_onlink_ipv4()
 {
 	run_ip 254 ${TEST_NET4[1]}.11 ${V4ADDRS[p1]} ${NETIFS[p1]} 2 \
 		"Invalid gw - local unicast address"
+	run_ip 254 ${TEST_NET4[1]}.12 ${MCAST4} ${NETIFS[p1]} 2 \
+		"Invalid gw - multicast address"
 
 	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.11 ${V4ADDRS[p5]} ${NETIFS[p5]} 2 \
 		"Invalid gw - local unicast address, VRF"
+	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.12 ${MCAST4} ${NETIFS[p5]} 2 \
+		"Invalid gw - multicast address, VRF"
 
 	run_ip 254 ${TEST_NET4[1]}.101 ${V4ADDRS[p1]} "" 2 "No nexthop device given"
 }
-- 
2.52.0

Re: [PATCH net-next 3/5] selftests: fib-onlink: Add a test case for IPv4 multicast gateway

[David Ahern]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> A multicast gateway address should be rejected when "onlink" is
> specified, but it is only tested as part of the IPv6 tests. Add an
> equivalent IPv4 test.
> 
>  # ./fib-onlink-tests.sh -v
>  [...]
>  COMMAND: ip ro add table 254 169.254.101.12/32 via 233.252.0.1 dev veth1 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Invalid gw - multicast address                      [ OK ]
>  [...]
>  COMMAND: ip ro add table 1101 169.254.102.12/32 via 233.252.0.1 dev veth5 onlink
>  Error: Nexthop has invalid gateway.
> 
>  TEST: Invalid gw - multicast address, VRF                 [ OK ]
>  [...]
>  Tests passed:  37
>  Tests failed:   0
> 
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  tools/testing/selftests/net/fib-onlink-tests.sh | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>

[PATCH net-next 4/5] ipv6: Allow for nexthop device mismatch with "onlink"

[Ido Schimmel]

IPv4 allows for a nexthop device mismatch when the "onlink" keyword is
specified:

 # ip link add name dummy1 up type dummy
 # ip address add 192.0.2.1/24 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2
 Error: Nexthop has invalid gateway.
 # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2 onlink
 # echo $?
 0

This seems to be consistent with the description of "onlink" in the
ip-route man page: "Pretend that the nexthop is directly attached to
this link, even if it does not match any interface prefix".

On the other hand, IPv6 rejects a nexthop device mismatch, even when
"onlink" is specified:

 # ip link add name dummy1 up type dummy
 # ip address add 2001:db8:1::1/64 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
 RTNETLINK answers: No route to host
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 Error: Nexthop has invalid gateway or device mismatch.

This is intentional according to commit fc1e64e1092f ("net/ipv6: Add
support for onlink flag") which added IPv6 "onlink" support and states
that "any unicast gateway is allowed as long as the gateway is not a
local address and if it resolves it must match the given device".

The condition was later relaxed in commit 4ed591c8ab44 ("net/ipv6: Allow
onlink routes to have a device mismatch if it is the default route") to
allow for a nexthop device mismatch if the gateway address is resolved
via the default route:

 # ip link add name dummy1 up type dummy
 # ip route add ::/0 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
 RTNETLINK answers: No route to host
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 # echo $?
 0

While the decision to forbid a nexthop device mismatch in IPv6 seems to
be intentional, it is unclear why it was made. Especially when it
differs from IPv4 and seems to go against the intended behavior of
"onlink".

Therefore, relax the condition further and allow for a nexthop device
mismatch when "onlink" is specified:

 # ip link add name dummy1 up type dummy
 # ip address add 2001:db8:1::1/64 dev dummy1
 # ip link add name dummy2 up type dummy
 # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
 # echo $?
 0

The motivating use case is the fact that FRR would like to be able to
configure overlay routes of the following form:

 # ip route add <host-Z> vrf <VRF> encap ip id <ID> src <VTEP-A> dst <VTEP-Z> via <VTEP-Z> dev vxlan0 onlink

Where vxlan0 is in the default VRF in which "VTEP-Z" is reachable via
one of the underlay routes (e.g., via swpX). Without this patch, the
above only works with IPv4, but not with IPv6.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 net/ipv6/route.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a3e051dc66ee..00a8318f33a7 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3419,11 +3419,8 @@ static int ip6_route_check_nh_onlink(struct net *net,
 
 	err = ip6_nh_lookup_table(net, cfg, gw_addr, tbid, 0, &res);
 	if (!err && !(res.fib6_flags & RTF_REJECT) &&
-	    /* ignore match if it is the default route */
-	    !ipv6_addr_any(&res.f6i->fib6_dst.addr) &&
-	    (res.fib6_type != RTN_UNICAST || dev != res.nh->fib_nh_dev)) {
-		NL_SET_ERR_MSG(extack,
-			       "Nexthop has invalid gateway or device mismatch");
+	    res.fib6_type != RTN_UNICAST) {
+		NL_SET_ERR_MSG(extack, "Nexthop has invalid gateway");
 		err = -EINVAL;
 	}
 
-- 
2.52.0

Re: [PATCH net-next 4/5] ipv6: Allow for nexthop device mismatch with "onlink"

[David Ahern]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> IPv4 allows for a nexthop device mismatch when the "onlink" keyword is
> specified:
> 
>  # ip link add name dummy1 up type dummy
>  # ip address add 192.0.2.1/24 dev dummy1
>  # ip link add name dummy2 up type dummy
>  # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2
>  Error: Nexthop has invalid gateway.
>  # ip route add 198.51.100.0/24 nexthop via 192.0.2.2 dev dummy2 onlink
>  # echo $?
>  0
> 
> This seems to be consistent with the description of "onlink" in the
> ip-route man page: "Pretend that the nexthop is directly attached to
> this link, even if it does not match any interface prefix".
> 
> On the other hand, IPv6 rejects a nexthop device mismatch, even when
> "onlink" is specified:
> 
>  # ip link add name dummy1 up type dummy
>  # ip address add 2001:db8:1::1/64 dev dummy1
>  # ip link add name dummy2 up type dummy
>  # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
>  RTNETLINK answers: No route to host
>  # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
>  Error: Nexthop has invalid gateway or device mismatch.
> 
> This is intentional according to commit fc1e64e1092f ("net/ipv6: Add
> support for onlink flag") which added IPv6 "onlink" support and states
> that "any unicast gateway is allowed as long as the gateway is not a
> local address and if it resolves it must match the given device".
> 
> The condition was later relaxed in commit 4ed591c8ab44 ("net/ipv6: Allow
> onlink routes to have a device mismatch if it is the default route") to
> allow for a nexthop device mismatch if the gateway address is resolved
> via the default route:
> 
>  # ip link add name dummy1 up type dummy
>  # ip route add ::/0 dev dummy1
>  # ip link add name dummy2 up type dummy
>  # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2
>  RTNETLINK answers: No route to host
>  # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
>  # echo $?
>  0
> 
> While the decision to forbid a nexthop device mismatch in IPv6 seems to
> be intentional, it is unclear why it was made. Especially when it
> differs from IPv4 and seems to go against the intended behavior of
> "onlink".
> 
> Therefore, relax the condition further and allow for a nexthop device
> mismatch when "onlink" is specified:
> 
>  # ip link add name dummy1 up type dummy
>  # ip address add 2001:db8:1::1/64 dev dummy1
>  # ip link add name dummy2 up type dummy
>  # ip route add 2001:db8:10::/64 nexthop via 2001:db8:1::2 dev dummy2 onlink
>  # echo $?
>  0
> 
> The motivating use case is the fact that FRR would like to be able to
> configure overlay routes of the following form:
> 
>  # ip route add <host-Z> vrf <VRF> encap ip id <ID> src <VTEP-A> dst <VTEP-Z> via <VTEP-Z> dev vxlan0 onlink
> 
> Where vxlan0 is in the default VRF in which "VTEP-Z" is reachable via
> one of the underlay routes (e.g., via swpX). Without this patch, the
> above only works with IPv4, but not with IPv6.
> 
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  net/ipv6/route.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>

[PATCH net-next 5/5] selftests: fib-onlink: Add test cases for nexthop device mismatch

[Ido Schimmel]

Add test cases that verify that when the "onlink" keyword is specified,
both address families (with and without VRF) accept routes with a
gateway address that is reachable via a different interface than the one
specified.

Output without "ipv6: Allow for nexthop device mismatch with "onlink"":

 # ./fib-onlink-tests.sh | grep mismatch
 TEST: nexthop device mismatch                             [ OK ]
 TEST: nexthop device mismatch                             [ OK ]
 TEST: nexthop device mismatch                             [FAIL]
 TEST: nexthop device mismatch                             [FAIL]

Output with "ipv6: Allow for nexthop device mismatch with "onlink"":

 # ./fib-onlink-tests.sh | grep mismatch
 TEST: nexthop device mismatch                             [ OK ]
 TEST: nexthop device mismatch                             [ OK ]
 TEST: nexthop device mismatch                             [ OK ]
 TEST: nexthop device mismatch                             [ OK ]

That is, the IPv4 tests were always passing, but the IPv6 ones only pass
after the specified patch.

Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 tools/testing/selftests/net/fib-onlink-tests.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index 7a0fd7a91e4e..b5773ac8847d 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -271,11 +271,15 @@ valid_onlink_ipv4()
 
 	run_ip 254 ${TEST_NET4[1]}.1 ${CONGW[1]} ${NETIFS[p1]} 0 "unicast connected"
 	run_ip 254 ${TEST_NET4[1]}.2 ${RECGW4[1]} ${NETIFS[p1]} 0 "unicast recursive"
+	run_ip 254 ${TEST_NET4[1]}.9 ${CONGW[1]} ${NETIFS[p3]} 0 \
+		"nexthop device mismatch"
 
 	log_subsection "VRF ${VRF}"
 
 	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[3]} ${NETIFS[p5]} 0 "unicast connected"
 	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.2 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive"
+	run_ip ${VRF_TABLE} ${TEST_NET4[2]}.10 ${CONGW[3]} ${NETIFS[p7]} 0 \
+		"nexthop device mismatch"
 
 	log_subsection "VRF device, PBR table"
 
@@ -366,12 +370,16 @@ valid_onlink_ipv6()
 	run_ip6 254 ${TEST_NET6[1]}::1 ${V6ADDRS[p1]/::*}::64 ${NETIFS[p1]} 0 "unicast connected"
 	run_ip6 254 ${TEST_NET6[1]}::2 ${RECGW6[1]} ${NETIFS[p1]} 0 "unicast recursive"
 	run_ip6 254 ${TEST_NET6[1]}::3 ::ffff:${TEST_NET4IN6[1]} ${NETIFS[p1]} 0 "v4-mapped"
+	run_ip6 254 ${TEST_NET6[1]}::a ${V6ADDRS[p1]/::*}::64 ${NETIFS[p3]} 0 \
+		"nexthop device mismatch"
 
 	log_subsection "VRF ${VRF}"
 
 	run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::1 ${V6ADDRS[p5]/::*}::64 ${NETIFS[p5]} 0 "unicast connected"
 	run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::2 ${RECGW6[2]} ${NETIFS[p5]} 0 "unicast recursive"
 	run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::3 ::ffff:${TEST_NET4IN6[2]} ${NETIFS[p5]} 0 "v4-mapped"
+	run_ip6 ${VRF_TABLE} ${TEST_NET6[2]}::b ${V6ADDRS[p5]/::*}::64 \
+		${NETIFS[p7]} 0 "nexthop device mismatch"
 
 	log_subsection "VRF device, PBR table"
 
-- 
2.52.0

Re: [PATCH net-next 5/5] selftests: fib-onlink: Add test cases for nexthop device mismatch

[David Ahern]

On 1/11/26 5:08 AM, Ido Schimmel wrote:
> Add test cases that verify that when the "onlink" keyword is specified,
> both address families (with and without VRF) accept routes with a
> gateway address that is reachable via a different interface than the one
> specified.
> 
> Output without "ipv6: Allow for nexthop device mismatch with "onlink"":
> 
>  # ./fib-onlink-tests.sh | grep mismatch
>  TEST: nexthop device mismatch                             [ OK ]
>  TEST: nexthop device mismatch                             [ OK ]
>  TEST: nexthop device mismatch                             [FAIL]
>  TEST: nexthop device mismatch                             [FAIL]
> 
> Output with "ipv6: Allow for nexthop device mismatch with "onlink"":
> 
>  # ./fib-onlink-tests.sh | grep mismatch
>  TEST: nexthop device mismatch                             [ OK ]
>  TEST: nexthop device mismatch                             [ OK ]
>  TEST: nexthop device mismatch                             [ OK ]
>  TEST: nexthop device mismatch                             [ OK ]
> 
> That is, the IPv4 tests were always passing, but the IPv6 ones only pass
> after the specified patch.
> 
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  tools/testing/selftests/net/fib-onlink-tests.sh | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

Reviewed-by: David Ahern <dsahern@kernel.org>

Re: [PATCH net-next 0/5] ipv6: Allow for nexthop device mismatch with "onlink"

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Sun, 11 Jan 2026 14:08:08 +0200 you wrote:
> This patchset aligns IPv6 with IPv4 with respect to the "onlink" keyword
> and allows IPv6 routes to be configured with a gateway address that is
> resolved out of a different interface than the one specified.
> 
> Patches #1-#3 are small preparations in the existing "onlink" selftest.
> 
> Patch #4 is the actual change. See the commit message for detailed
> description and motivation.
> 
> [...]

Here is the summary with links:
  - [net-next,1/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv4 tests
    https://git.kernel.org/netdev/net-next/c/e5566f6b1d13
  - [net-next,2/5] selftests: fib-onlink: Remove "wrong nexthop device" IPv6 tests
    https://git.kernel.org/netdev/net-next/c/0a3419f4ba40
  - [net-next,3/5] selftests: fib-onlink: Add a test case for IPv4 multicast gateway
    https://git.kernel.org/netdev/net-next/c/9bf8345fb38a
  - [net-next,4/5] ipv6: Allow for nexthop device mismatch with "onlink"
    https://git.kernel.org/netdev/net-next/c/b853b94e8482
  - [net-next,5/5] selftests: fib-onlink: Add test cases for nexthop device mismatch
    https://git.kernel.org/netdev/net-next/c/f8f9ee9d8b2e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html