Improve documentation for debugging MM-setup

docs/Networking.asciidoc

@@ -191,22 +191,21 @@ systemctl enable openqa-worker@{1..3}
 === Verify the setup
 Simply run a MM test scenario. For openSUSE, you can find many relevant tests on
 https://openqa.opensuse.org[o3], e.g. look for networking-related tests like
-wicked-tests. To test GRE tunnels, you may want to change the jobs worker
-classes so the different jobs are executed on different workers.
+`ping_server`/`ping_client` or `wicked_basic_ref`/`wicked_basic_sut`.
 
-So you could call `openqa-clone-job` like this:
+To test GRE tunnels, you may want to change the jobs worker classes so the
+different jobs are executed on different workers. So you could call
+`openqa-clone-job` like this:
 ```
 openqa-clone-job \
-    --skip-download --skip-chained-deps \    # assuming assets are present
-    --max-depth 0 \                          # clone the entire parallel cluster
-    --export-command \                       # only print the API call
-    https://openqa.opensuse.org/tests/250309 # arbitrary job in cluster to clone
-    _GROUP=0 BUILD+=test-mm-setup            # avoid interfering with production jobs
+    --skip-download --skip-chained-deps \        # assuming assets are present
+    --max-depth 0 \                              # clone the entire parallel cluster
+    https://openqa.opensuse.org/tests/3886213 \  # arbitrary job in cluster to clone
+    _GROUP=0 BUILD+=test-mm-setup \              # avoid interfering with production jobs
+    WORKER_CLASS:wicked_basic_ref+=,worker_foo \ # ensure one job runs on `worker_foo`
+    WORKER_CLASS:wicked_basic_sut+=,worker_bar   # ensure other job runs on `worker_bar`
 ```
 
-It will print an `openqa-cli` call. You can modify it to change the worker
-classes of the jobs individually and then invoke it.
-
 Also be sure to reboot the worker host to make sure the setup is actually
 persistent.
 
@@ -232,7 +231,7 @@ Within the VM configure the network *like* this (you may need to adjust concrete
 IP addresses, subnets and interface names):
 
 ```
-ip link set dev eth0 up mtu 1458
+ip link set dev eth0 up mtu 1380
 ip a add dev eth0 10.0.2.15/24
 ip r add default via 10.0.2.2
 echo 'nameserver 8.8.8.8' > /etc/resolv.conf
@@ -243,7 +242,12 @@ for MM tests and should be below the MTU set on the Open vSwitch bridge device
 (e.g. via `os-autoinst-setup-multi-machine`).
 
 After this it should be possible to reach other hosts. You may also launch a 2nd
-VM to see whether the VMs can talk to each other.
+VM to see whether the VMs can talk to each other. You may conduct ping tests
+similar to the `ping_client` test mentioned in the previous section (see the
+https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/cc3a5b32527c4c8bb810c8bce9b1449a891ef74b/lib/utils.pm#L2901[utility function in openSUSE tests]
+for details). When running ping you can add/remove machines to/from the GRE
+network to bisect problematic hosts/connections (via `ovs-vsctl add-port …` and
+`ovs-vsctl del-port …`).
 
 === Debugging Open vSwitch Configuration
 Boot sequence with wicked (version 0.6.23 and newer):
@@ -259,6 +263,7 @@ The configuration and operation can be checked with the following commands:
 
 [source,sh]
 ----
+cat /proc/sys/net/ipv4/conf/{br1,eth0}/forwarding # check whether IP forwarding is enabled
 ovs-vsctl show # shows the bridge br1, the tap devices are assigned to it
 ovs-ofctl dump-flows br1 # shows the rules installed by os-autoinst-openvswitch in table=0
 ovs-dpctl show # show basic info on all datapaths