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: 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: 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 Signed-off-by: Ido Schimmel --- 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 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 Signed-off-by: Ido Schimmel --- 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 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 Signed-off-by: Ido Schimmel --- 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 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 vrf encap ip id src dst via 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 Signed-off-by: Ido Schimmel --- 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 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 Signed-off-by: Ido Schimmel --- 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