ARP broadcast domain
Change-Id: I477ae706eac9d83315ceb247e475ba2606b5420e
diff --git a/onramp/start.rst b/onramp/start.rst
index aa58191..f10544f 100644
--- a/onramp/start.rst
+++ b/onramp/start.rst
@@ -333,7 +333,7 @@
webui-5894ffd49d-gg2jh 1/1 Running 0 6m13s
If you see problematic pods that are not getting into the ``Running``
-state, a re-install usually corrects the problem. Type:
+state, a reset usually corrects the problem. Type:
.. code-block::
@@ -427,10 +427,15 @@
.. admonition:: Troubleshooting Hint
If ``summary.log`` reports ``UEs Passed: 0 , UEs Failed: 5`` then it
- is likely the case that SD-Core did not come up cleanly. Type
+ may be the case that SD-Core did not come up cleanly. Type
``make aether-resetcore``, and after verifying all pods are running
with ``kubectl``, run gNBsim again.
+ Another possibility is that you have multiple SD-Cores running in
+ the same broadcast domain. This causes ARP to behave in unexpected
+ ways, which interferes with OnRamp's ability to establish a route
+ to the UPF pod.
+
If you are interested in the config file that controls the test,
including the option of enabling other profiles, take a look at
``deps/gnbsim/config/gnbsim-default.yaml``. We return to the issue of