diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst
index 432bbcc..a4ae0ab 100644
--- a/onramp/blueprints.rst
+++ b/onramp/blueprints.rst
@@ -100,7 +100,8 @@ To use Multi-UPF, first copy the vars file to ``main.yml``:
    $ cp main-upf.yml main.yml
 
 Then edit ``hosts.ini`` and ``vars/main.yml`` to match your local
-target servers, and deploy the base system (as in previous sections):
+target servers, and deploy the base system (as in previous sections).
+You can also optionally install the monitoring subsystem.
 
 .. code-block::
 
@@ -110,13 +111,13 @@ target servers, and deploy the base system (as in previous sections):
    $ make 5gc-install
    $ make gnbsim-install
 
-You can also optionally install the monitoring subsystem. Note that
-because ``main.yml`` sets ``core.standalone: "false"``, any models
-loaded into ROC are automatically applied to SD-Core.
+Note that because ``main.yml`` sets ``core.standalone: "false"``, any
+models loaded into ROC are automatically applied to SD-Core.
 
 At this point you are ready to bring up additional UPFs and bind them
-to specific slices and devices. This involves first editing the
-``upf`` block in the ``core`` section of ``vars/main.yml``:
+to specific slices and devices. An example configuration that brings
+up second UPF is included in the ``upf`` block in the ``core`` section
+of ``vars/main.yml``:
 
 .. code-block::
 
@@ -142,8 +143,8 @@ As shown above, one additional UPF is enabled (beyond ``upf-0`` that
 already came up as part of SD-Core), with the spec for yet another UPF
 commented out.  In this example configuration, each UPF is assigned a
 subnet on the ``access`` and ``core`` bridges, along with the IP
-address pool for UEs that the UPF serves.  Once done with the edits,
-launch the new UPF(s) by typing:
+address pool for UEs that the UPF serves. To launch this second UPF,
+type:
 
 .. code-block::
 
@@ -184,6 +185,15 @@ the emulation, type:
 
    $ make gnbsim-simulator-run
 
+To verify that both UPFs were functional, you will need to look at the
+``summary.log`` file from both instances of gNBsim:
+
+.. code-block::
+
+   $ docker exec -it gnbsim-1 cat summary.log
+   $ docker exec -it gnbsim-2 cat summary.log
+
+
 SD-RAN
 ~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/onramp/gnbsim.rst b/onramp/gnbsim.rst
index c7484b3..16c95cf 100644
--- a/onramp/gnbsim.rst
+++ b/onramp/gnbsim.rst
@@ -143,8 +143,9 @@ to run gNBsim, and then type
    $ docker exec -it gnbsim-1 cat summary.log
 
 Note that container name ``gnbsim-1`` is constructed from the
-``prefix`` variable defined in the ``docker`` section of
-``vars/main.yml``, with ``-1`` indicating the first container.
+``gnbsim.docker.prefix`` variable defined in ``vars/main.yml``, with
+``-1`` indicating the first container, ``-2`` indicating the second
+container, and so on.
 
 In addition to scaling up the workload you put on the Core, you can
 also experiment with the emulation settings defined in any or all of