[PATCH net-next 8/8] selftests: traceroute: Add VRF tests

David Ahern dsahern at kernel.org
Tue Sep 2 02:40:20 UTC 2025


On 9/1/25 2:30 AM, Ido Schimmel wrote:
> Create versions of the existing test cases where the routers generating
> the ICMP error messages are using VRFs. Check that the source IPs of
> these messages do not change in the presence of VRFs.
> 
> IPv6 always behaved correctly, but IPv4 fails when reverting "ipv4:
> icmp: Fix source IP derivation in presence of VRFs".
> 
> Without IPv4 change:
> 
>  # ./traceroute.sh
>  TEST: IPv6 traceroute                                               [ OK ]
>  TEST: IPv6 traceroute with VRF                                      [ OK ]
>  TEST: IPv4 traceroute                                               [ OK ]
>  TEST: IPv4 traceroute with VRF                                      [FAIL]
>          traceroute did not return 1.0.3.1
>  $ echo $?
>  1
> 
> The test fails because the ICMP error message is sent with the VRF
> device's IP (1.0.4.1):
> 
>  # traceroute -n -s 1.0.1.3 1.0.2.4
>  traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets
>   1  1.0.4.1  0.165 ms  0.110 ms  0.103 ms
>   2  1.0.2.4  0.098 ms  0.085 ms  0.078 ms
>  # traceroute -n -s 1.0.3.3 1.0.2.4
>  traceroute to 1.0.2.4 (1.0.2.4), 30 hops max, 60 byte packets
>   1  1.0.4.1  0.201 ms  0.138 ms  0.129 ms
>   2  1.0.2.4  0.123 ms  0.105 ms  0.098 ms
> 
> With IPv4 change:
> 
>  # ./traceroute.sh
>  TEST: IPv6 traceroute                                               [ OK ]
>  TEST: IPv6 traceroute with VRF                                      [ OK ]
>  TEST: IPv4 traceroute                                               [ OK ]
>  TEST: IPv4 traceroute with VRF                                      [ OK ]
>  $ echo $?
>  0
> 
> Reviewed-by: Petr Machata <petrm at nvidia.com>
> Signed-off-by: Ido Schimmel <idosch at nvidia.com>
> ---
>  tools/testing/selftests/net/traceroute.sh | 178 ++++++++++++++++++++++
>  1 file changed, 178 insertions(+)
> 

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





More information about the Linux-security-module-archive mailing list