| Message ID | 20191101233408.BC15495C0902@us180.sjc.aristanetworks.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [net-next,1/2] selftest: net: add icmp6 reply address test | expand |
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.
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
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.
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
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.
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.
> > > 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
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.
> 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
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} +
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