Re: [PATCH net-next v2 1/2] ipv6: Honor oif when choosing nexthop for locally generated traffic

[David Ahern <dsahern@kernel.org>]

On 6/1/26 12:52 AM, Ido Schimmel wrote:
> Commit 741a11d9e410 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is
> set") made the kernel honor the oif parameter when specified as part of
> output route lookup:
> 
>  # ip route add 2001:db8:1::/64 dev dummy1
>  # ip route add ::/0 dev dummy2
>  # ip route get 2001:db8:1::1 oif dummy2 fibmatch
>  default dev dummy2 metric 1024 pref medium
> 
> Due to regression reports, the behavior was partially reverted in commit
> d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if saddr
> set") to only honor the oif if source address is not specified:
> 
>  # ip route get 2001:db8:1::1 from 2001:db8:2::1 oif dummy2 fibmatch
>  2001:db8:1::/64 dev dummy1 metric 1024 pref medium
> 
> That is, when source address is specified, the kernel will choose the
> most specific route even if its nexthop device does not match the
> specified oif.
> 
> This creates a problem for multipath routes. After looking up a route,
> when source address is not specified, the kernel will choose a nexthop
> whose nexthop device matches the specified oif:
> 
>  # sysctl -wq net.ipv6.conf.all.forwarding=1
>  # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2
>  # for i in {1..100}; do ip route get 2001:db8:10::${i} oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c
>       100 dummy2
> 
> But will disregard the oif when source address is specified despite the
> fact that a matching nexthop exists:
> 
>  # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c
>       53 dummy1
>       47 dummy2
> 
> This behavior differs from IPv4:
> 
>  # ip address add 192.0.2.1/32 dev lo
>  # ip route add 198.51.100.0/24 nexthop via inet6 fe80::1 dev dummy1 nexthop via inet6 fe80::2 dev dummy2
>  # for i in {1..100}; do ip route get 198.51.100.${i} from 192.0.2.1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c
>      100 dummy2
> 
> What happens is that fib6_table_lookup() returns a route with a matching
> nexthop device (assuming it exists):
> 
>  # perf record -e fib6:fib6_table_lookup -- bash -c "for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done > /dev/null"
>  # perf script | grep -o dummy[0-9] | sort | uniq -c
>       100 dummy2
> 
> But it is later overwritten during path selection in fib6_select_path()
> which instead chooses a nexthop according to the calculated hash.
> 
> Solve this by telling fib6_select_path() to skip path selection if we
> have an oif match during output route lookup (iif being
> LOOPBACK_IFINDEX).
> 
> Behavior after the change:
> 
>  # sysctl -wq net.ipv6.conf.all.forwarding=1
>  # ip route add 2001:db8:10::/64 nexthop via fe80::1 dev dummy1 nexthop via fe80::2 dev dummy2
>  # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c
>      100 dummy2
> 
> Note that enabling forwarding is only needed because we did not add
> neighbor entries for the gateway addresses. When forwarding is disabled
> and CONFIG_IPV6_ROUTER_PREF is not enabled in kernel config, the kernel
> will treat non-existing neighbor entries as errors and perform
> round-robin between the nexthops:
> 
>  # sysctl -wq net.ipv6.conf.all.forwarding=0
>  # for i in {1..100}; do ip route get 2001:db8:10::${i} from 2001:db8:2::1 oif dummy2; done | grep -o dummy[0-9] | sort | uniq -c
>       50 dummy1
>       50 dummy2
> 
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
>  net/ipv6/route.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

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