[net-next,2/2] selftest: net: add icmp reply address test
diff mbox series

Message ID 20191101233408.BC15495C0902@us180.sjc.aristanetworks.com
State New
Headers show
Series
  • [net-next,1/2] selftest: net: add icmp6 reply address test
Related show

Commit Message

Francesco Ruggeri Nov. 1, 2019, 11:34 p.m. UTC
Verify that in this scenario

                   1.0.3.1/24
---- 1.0.1.3/24    1.0.1.1/24 ---- 1.0.2.1/24    1.0.2.4/24 ----
|H1|--------------------------|R1|--------------------------|H2|
----            N1            ----            N2            ----

where 1.0.3.1/24 and 1.0.1.1/24 are respectively R1's primary and
secondary address on N1, traceroute from H1 to H2 show 1.0.1.1

Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
 tools/testing/selftests/net/Makefile          |   2 +-
 .../testing/selftests/net/icmp_reply_addr.sh  | 106 ++++++++++++++++++
 2 files changed, 107 insertions(+), 1 deletion(-)
 create mode 100755 tools/testing/selftests/net/icmp_reply_addr.sh

Comments

David Ahern Nov. 2, 2019, 2:34 p.m. UTC | #1
On 11/1/19 5:34 PM, Francesco Ruggeri wrote:
> Verify that in this scenario
> 
>                    1.0.3.1/24
> ---- 1.0.1.3/24    1.0.1.1/24 ---- 1.0.2.1/24    1.0.2.4/24 ----
> |H1|--------------------------|R1|--------------------------|H2|
> ----            N1            ----            N2            ----
> 
> where 1.0.3.1/24 and 1.0.1.1/24 are respectively R1's primary and
> secondary address on N1, traceroute from H1 to H2 show 1.0.1.1
> 
> Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
> ---
>  tools/testing/selftests/net/Makefile          |   2 +-
>  .../testing/selftests/net/icmp_reply_addr.sh  | 106 ++++++++++++++++++
>  2 files changed, 107 insertions(+), 1 deletion(-)
>  create mode 100755 tools/testing/selftests/net/icmp_reply_addr.sh
> 

Hi:

It would be better to combine both of these into a single test script;
the topology and setup are very similar and the scripts share a lot of
common code.

The script can be a generic traceroute.sh and then contain 2 tests:
1. IPv4 - verify reply address test,
2. IPv6 - verify reply address test.

Making 1 script with multiple tests allows other tests to be added in
the future with less overhead. This is how other tests under net are done.

Also, you still have these using macvlan devices. The intent is to use
network namespaces to mimic nodes in a network. As such veth pairs are a
better option for this intent.

There are 2 scripts under net (l2tp.sh and fcnal-test.sh) that contain
functions -- create_ns and connect_ns  -- that really reduce the
overhead of creating tests like this. Actually you could copy l2tp.sh to
traceroute.sh and quickly update it for these tests.
Francesco Ruggeri Nov. 2, 2019, 3:08 p.m. UTC | #2
On Sat, Nov 2, 2019 at 7:34 AM David Ahern <dsahern@gmail.com> wrote:
>
> It would be better to combine both of these into a single test script;
> the topology and setup are very similar and the scripts share a lot of
> common code.

Sure, I can do that.

> Also, you still have these using macvlan devices. The intent is to use
> network namespaces to mimic nodes in a network. As such veth pairs are a
> better option for this intent.
>

I am only using macvlans for N1 in the ipv6 test, where there are 3 nodes.
How do I use veths for that?

Thanks,
Francesco
David Ahern Nov. 2, 2019, 3:11 p.m. UTC | #3
On 11/2/19 9:08 AM, Francesco Ruggeri wrote:
> On Sat, Nov 2, 2019 at 7:34 AM David Ahern <dsahern@gmail.com> wrote:
>>
>> It would be better to combine both of these into a single test script;
>> the topology and setup are very similar and the scripts share a lot of
>> common code.
> 
> Sure, I can do that.
> 
>> Also, you still have these using macvlan devices. The intent is to use
>> network namespaces to mimic nodes in a network. As such veth pairs are a
>> better option for this intent.
>>
> 
> I am only using macvlans for N1 in the ipv6 test, where there are 3 nodes.
> How do I use veths for that?

checkout the connect_ns function. It uses veth to connect ns1 to ns2.
Francesco Ruggeri Nov. 2, 2019, 4:09 p.m. UTC | #4
On Sat, Nov 2, 2019 at 8:11 AM David Ahern <dsahern@gmail.com> wrote:
> On 11/2/19 9:08 AM, Francesco Ruggeri wrote:
> > I am only using macvlans for N1 in the ipv6 test, where there are 3 nodes.
> > How do I use veths for that?
>
> checkout the connect_ns function. It uses veth to connect ns1 to ns2.

I apologize in advance  for being slow ...
I have 3 namespaces that have to share the same LAN, I am not trying
1-1 connections among those namespaces.

Thanks,
Francesco
David Ahern Nov. 2, 2019, 5:38 p.m. UTC | #5
On 11/2/19 10:09 AM, Francesco Ruggeri wrote:
> On Sat, Nov 2, 2019 at 8:11 AM David Ahern <dsahern@gmail.com> wrote:
>> On 11/2/19 9:08 AM, Francesco Ruggeri wrote:
>>> I am only using macvlans for N1 in the ipv6 test, where there are 3 nodes.
>>> How do I use veths for that?
>>
>> checkout the connect_ns function. It uses veth to connect ns1 to ns2.
> 
> I apologize in advance  for being slow ...
> I have 3 namespaces that have to share the same LAN, I am not trying
> 1-1 connections among those namespaces.
> 

How would you cable this if it were an actual network with physical nodes?
- bridge on R1 (since it is the gw for H1), with connections to R2 and
H1 into the bridge
- second connection between R1 and R2
- connection between R2 and H2

For the simulation, network namespaces represent physical nodes, veth
pairs act like a cable between the nodes / namespaces and the bridge
makes the LAN.
Francesco Ruggeri Nov. 2, 2019, 6:08 p.m. UTC | #6
On Sat, Nov 2, 2019 at 10:38 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 11/2/19 10:09 AM, Francesco Ruggeri wrote:
> > On Sat, Nov 2, 2019 at 8:11 AM David Ahern <dsahern@gmail.com> wrote:
> >> On 11/2/19 9:08 AM, Francesco Ruggeri wrote:
> >>> I am only using macvlans for N1 in the ipv6 test, where there are 3 nodes.
> >>> How do I use veths for that?
> >>
> >> checkout the connect_ns function. It uses veth to connect ns1 to ns2.
> >
> > I apologize in advance  for being slow ...
> > I have 3 namespaces that have to share the same LAN, I am not trying
> > 1-1 connections among those namespaces.
> >
>
> How would you cable this if it were an actual network with physical nodes?
> - bridge on R1 (since it is the gw for H1), with connections to R2 and
> H1 into the bridge
> - second connection between R1 and R2
> - connection between R2 and H2
>
> For the simulation, network namespaces represent physical nodes, veth
> pairs act like a cable between the nodes / namespaces and the bridge
> makes the LAN.
Francesco Ruggeri Nov. 2, 2019, 10:08 p.m. UTC | #7
> > > I apologize in advance  for being slow ...
> > > I have 3 namespaces that have to share the same LAN, I am not trying
> > > 1-1 connections among those namespaces.
> > >
> >
> > How would you cable this if it were an actual network with physical nodes?
> > - bridge on R1 (since it is the gw for H1), with connections to R2 and
> > H1 into the bridge
> > - second connection between R1 and R2
> > - connection between R2 and H2
> >
> > For the simulation, network namespaces represent physical nodes, veth
> > pairs act like a cable between the nodes / namespaces and the bridge
> > makes the LAN.

Thanks, I see what you mean now.
I was assuming a different physical model, with all the namespaces on the LAN
connected to a hub (simulated by the dummy device). For simulation purposes this
model seem simpler: there are N interfaces instead of N pairs, and one does not
have to deal with the bridge end of the pairs.
Why is the model you described preferable?

Thanks,
Francesco
David Ahern Nov. 3, 2019, 4:52 p.m. UTC | #8
On 11/2/19 4:08 PM, Francesco Ruggeri wrote:
>>>> I apologize in advance  for being slow ...
>>>> I have 3 namespaces that have to share the same LAN, I am not trying
>>>> 1-1 connections among those namespaces.
>>>>
>>>
>>> How would you cable this if it were an actual network with physical nodes?
>>> - bridge on R1 (since it is the gw for H1), with connections to R2 and
>>> H1 into the bridge
>>> - second connection between R1 and R2
>>> - connection between R2 and H2
>>>
>>> For the simulation, network namespaces represent physical nodes, veth
>>> pairs act like a cable between the nodes / namespaces and the bridge
>>> makes the LAN.
> 
> Thanks, I see what you mean now.
> I was assuming a different physical model, with all the namespaces on the LAN
> connected to a hub (simulated by the dummy device). For simulation purposes this
> model seem simpler: there are N interfaces instead of N pairs, and one does not
> have to deal with the bridge end of the pairs.
> Why is the model you described preferable?
> 

The tests are about traceroute in modern networks, not broadcast
domains. As such, it is preferable for these tests to be constructed
similar to other extisting networking tests.
Francesco Ruggeri Nov. 4, 2019, 6:14 p.m. UTC | #9
> The tests are about traceroute in modern networks, not broadcast
> domains. As such, it is preferable for these tests to be constructed
> similar to other extisting networking tests.

Got it.

Thanks,
Francesco

Patch
diff mbox series

diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index daeaeb59d5ca..3a90084feee4 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -11,7 +11,7 @@  TEST_PROGS += udpgso_bench.sh fib_rule_tests.sh msg_zerocopy.sh psock_snd.sh
 TEST_PROGS += udpgro_bench.sh udpgro.sh test_vxlan_under_vrf.sh reuseport_addr_any.sh
 TEST_PROGS += test_vxlan_fdb_changelink.sh so_txtime.sh ipv6_flowlabel.sh
 TEST_PROGS += tcp_fastopen_backup_key.sh fcnal-test.sh l2tp.sh
-TEST_PROGS += icmp6_reply_addr.sh
+TEST_PROGS += icmp6_reply_addr.sh icmp_reply_addr.sh
 TEST_PROGS_EXTENDED := in_netns.sh
 TEST_GEN_FILES =  socket nettest
 TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy reuseport_addr_any
diff --git a/tools/testing/selftests/net/icmp_reply_addr.sh b/tools/testing/selftests/net/icmp_reply_addr.sh
new file mode 100755
index 000000000000..3c0ff3c26c07
--- /dev/null
+++ b/tools/testing/selftests/net/icmp_reply_addr.sh
@@ -0,0 +1,106 @@ 
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Verify that in this scenario
+#
+#                    1.0.3.1/24
+# ---- 1.0.1.3/24    1.0.1.1/24 ---- 1.0.2.1/24    1.0.2.4/24 ----
+# |H1|--------------------------|R1|--------------------------|H2|
+# ----            N1            ----            N2            ----
+#
+# where 1.0.3.1/24 and 1.0.1.1/24 are respectively R1's primary and
+# secondary address on N1, traceroute from H1 to H2 show 1.0.1.1
+#
+
+####################################################################
+# helpers
+# 
+# Interface on network <net> in node <node> is called <node><net>
+#
+
+node()
+{
+	host=$1
+	shift
+	ip netns exec ${host} $*
+}
+
+create_nodes()
+{
+	for n in $*; do
+		ip netns add $n
+		node $n ip link set lo up
+	done
+}
+
+delete_nodes()
+{
+	for n in $*; do
+		ip netns del $n
+	done
+}
+
+create_veth_net()
+{
+	net=$1
+	h1=$2
+	h2=$3
+
+	ip link add ${h1}${net} type veth peer name ${h2}${net}
+	ip link set ${h1}${net} netns ${h1}
+	node ${h1} ip link set ${h1}${net} up
+	ip link set ${h2}${net} netns ${h2}
+	node ${h2} ip link set ${h2}${net} up
+}
+
+# end helpers
+####################################################################
+
+if [ "$(id -u)" -ne 0 ]; then
+        echo "SKIP: Need root privileges"
+        exit 0
+fi
+
+if [ ! -x "$(command -v traceroute)" ]; then
+        echo "SKIP: Could not run test without traceroute"
+        exit 0
+fi
+
+create_nodes host1 rtr1 host2
+
+create_veth_net net1 host1 rtr1
+create_veth_net net2 rtr1 host2
+
+# Configure interfaces and routes in host1
+node host1 ip addr add 1.0.1.3/24 dev host1net1
+node host1 ip route add default via 1.0.1.1
+
+# Configure interfaces and routes in rtr1
+node rtr1 ip addr add 1.0.3.1/24 dev rtr1net1
+node rtr1 ip addr add 1.0.1.1/24 dev rtr1net1
+node rtr1 ip addr add 1.0.2.1/24 dev rtr1net2
+node rtr1 sysctl net.ipv4.ip_forward=1 >/dev/null
+node rtr1 sysctl net.ipv4.icmp_errors_use_inbound_ifaddr=1 >/dev/null
+
+# Configure interfaces and routes in host2
+node host2 ip addr add 1.0.2.4/24 dev host2net2
+node host2 ip route add default via 1.0.2.1
+
+# Ping host2 from host1
+echo "Priming the network"
+node host1 ping -c5 1.0.2.4 >/dev/null
+
+# Traceroute host2 from host1
+echo "Running traceroute (will take a while)"
+if node host1 traceroute 1.0.2.4 | grep -q 1.0.1.1; then
+	ret=0
+	echo "Found 1.0.1.1. Test passed."
+else
+	ret=1
+	echo "Did not find 1.0.1.1. Test failed."
+fi
+
+delete_nodes host1 rtr1 host2
+
+exit ${ret}
+