Skip to content

Commit 15b9c0b

Browse files
llpetersonllpeterson
committed
reorg packet capture
1 parent 37c560f commit 15b9c0b

File tree

2 files changed

+111
-58
lines changed

2 files changed

+111
-58
lines changed

‎onramp/gnb.rst

Lines changed: 46 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -342,60 +342,53 @@ follow:
342342
address. Then set the default gateway to the IP address of your
343343
Aether server.
344344

345-
Run Diagnostics
346-
~~~~~~~~~~~~~~~~~
347-
348-
Successfully connecting a UE to the Internet is not a straightforward
349-
exercise. It involves configuring the UE, gNB, and SD-Core software in
350-
a consistent way; establishing SCTP-based control plane (N2) and
351-
GTP-based user plane (N3) connections between the base station and
352-
Mobile Core; and traversing multiple IP subnets along the end-to-end
353-
path.
354-
355-
The UE and gNB provide limited diagnostic tools. For example, it's
356-
possible to run ``ping`` and ``traceroute`` from both. You can also
357-
run the ``ksniff`` tool described in the Networking section, but the
358-
most helpful packet traces you can capture are shown in the following
359-
commands. You can run these on the Aether server, where we use our
360-
example ``ens18`` interface for illustrative purposes:
345+
Deployment Milestones
346+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
347+
348+
Successfully connecting a UE to the Internet involves configuring the
349+
UE, gNB, and SD-Core in a consistent way, and doing so for both the
350+
control and user planes. This section identifies the key milestones
351+
along the way, and how to use the available diagnostic tools to verify
352+
that you are making progress. (As a reminder, the available tools
353+
include running ``ping`` and ``traceroute`` from all three components,
354+
capturing packet traces on the Aether server, viewing the monitoring
355+
dashboard, and viewing the gNB Status panel).
356+
357+
* **Milestone 1: Bring up SD-Core.** Success can be verified by using
358+
``kubectl`` to observer the status of Kubernetes pods, and by noting
359+
that the monitoring dashboard reports *UPF Up*. And as noted earlier
360+
in this section, we recommend running gNBsim on a second server to
361+
verify that you have a working network path between the gNB and the
362+
Core before attempting to do the same with a physical gNB.
363+
364+
* **Milestone 2: Connect gNB to the Internet.** Configuring the gNB to
365+
treat the Aether server as its default router (and configuring that
366+
server to forward IP packets) is the recommended way to provide the
367+
gNB with Internet connectivity. Such connectivity is needed when
368+
your deployment depends on Internet services like NTP, and it can be
369+
verified by running ``ping`` or ``traceroute`` to those services
370+
from the gNB.
371+
372+
* **Milestone 3: Connect gNB to the AMF.** The gNB will automatically
373+
try to establish control plane connectivity to the configured AMF,
374+
and once successful, the dashboard will indicate *NR Ready*. The
375+
Aether monitoring dashboard will also show *gNodeB Up*.
376+
377+
* **Milestone 4: Connect gNB to the UPF.** Until we try to establish
378+
end-to-end connectivity from the UE (see the next Milestone), the
379+
best indicator of user plane connectivity between the gNB and UPF
380+
can be shown by successfully running ``ping 192.168.252.3`` on the
381+
gNB.
382+
383+
* **Milestone 5: Establish UE Connectivity.** Getting *5G bars* on
384+
the UE, followed by the ability to access Internet content, is the
385+
ultimate demonstration of success. To help diagnose problems, run
386+
the packet captures described in the Verify Network section.
387+
388+
One reason for calling out this sequence of milestones is that they
389+
establish a baseline that makes it easier for the community to help
390+
troubleshoot a deployment.
361391

362-
.. code-block::
363-
364-
$ sudo tcpdump -i any sctp -w sctp-test.pcap
365-
$ sudo tcpdump -i ens18 port 2152 -w gtp-outside.pcap
366-
$ sudo tcpdump -i access port 2152 -w gtp-inside.pcap
367-
$ sudo tcpdump -i core net 172.250.0.0/16 -w n6-inside.pcap
368-
$ sudo tcpdump -i ens18 net 172.250.0.0/16 -w n6-outside.pcap
369-
370-
The first trace, saved in file ``sctp.pcap``, captures SCTP packets
371-
sent to establish the control path between the base station and the
372-
Mobile Core (i.e., N2 messages). Toggling "Mobile Data" on the UE,
373-
for example by turning Airplane Mode off and on, will generate the
374-
relevant control plane traffic.
375-
376-
The second and third traces, saved in files ``gtp-outside.pcap`` and
377-
``gtp-inside.pcap``, respectively, capture GTP packets (tunneled
378-
through port ``2152`` ) on the RAN side of the UPF. Setting the
379-
interface to ``ens18`` corresponds to "outside" the UPF and setting
380-
the interface to ``access`` corresponds to "inside" the UPF. Running
381-
``ping`` from the UE will generate the relevant user plane (N3) traffic.
382-
383-
Similarly, the fourth and fifth traces, saved in files
384-
``n6-inside.pcap`` and ``n6-outside.pcap``, respectively, capture IP
385-
packets on the Internet side of the UPF (which is known as the **N6**
386-
interface in 3GPP). In these two tests, ``net 172.250.0.0/16``
387-
corresponds to the IP addresses assigned to UEs by the SMF. Running
388-
``ping`` from the UE will generate the relevant user plane traffic.
389-
390-
If the ``gtp-outside.pcap`` has packets and the ``gtp-inside.pcap``
391-
is empty (no packets captured), you may run the following commands
392-
to make sure packets are forwarded from the ``ens18`` interface
393-
to the ``access`` interface and vice versa:
394-
395-
.. code-block::
396-
397-
$ sudo iptables -A FORWARD -i ens18 -o access -j ACCEPT
398-
$ sudo iptables -A FORWARD -i access -o ens18 -j ACCEPT
399392

400393
Support for eNBs
401394
~~~~~~~~~~~~~~~~~~

‎onramp/network.rst

Lines changed: 65 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -3,11 +3,16 @@ Verify Network
33

44
This section goes into depth on how SD-Core (which runs *inside* the
55
Kubernetes cluster) connects to either physical gNBs or an emulated
6-
RAN (both running *outside* the Kubernetes cluster). For the purpose
7-
of this section, we assume you already have a scalable cluster running
8-
(as outlined in the previous section), SD-Core has been installed on
9-
that cluster, and you have a terminal window open on the Master node
10-
in that cluster.
6+
RAN (both running *outside* the Kubernetes cluster). It also describes
7+
how to run diagnostics to debug potential problems.
8+
9+
For the purpose of this section, we assume you already have a scalable
10+
cluster running (as outlined in the previous section), SD-Core has
11+
been installed on that cluster, and you have a terminal window open on
12+
the Master node in that cluster.
13+
14+
Network Schematic
15+
~~~~~~~~~~~~~~~~~~~~~~~~~~
1116

1217
:numref:`Figure %s <fig-macvlan>` shows a high-level schematic of
1318
Aether's end-to-end User Plane connectivity, where we start by
@@ -230,3 +235,58 @@ physical gNBs.
230235
macvlan:
231236
iface: gnbaccess
232237
subnet_prefix: "172.20"
238+
239+
Packet Traces
240+
~~~~~~~~~~~~~~~~~
241+
242+
Successfully connecting a UE to the Internet involves configuring the
243+
UE, gNB, and SD-Core software in a consistent way; establishing
244+
SCTP-based control plane (N2) and GTP-based user plane (N3)
245+
connections between the base station and Mobile Core; and traversing
246+
multiple IP subnets along the end-to-end path.
247+
248+
Packet traces are the best way to diagnose your deployment, and the
249+
most helpful traces you can capture are shown in the following
250+
commands. You can run these on the Aether server, where we use our
251+
example ``ens18`` interface for illustrative purposes:
252+
253+
.. code-block::
254+
255+
$ sudo tcpdump -i any sctp -w sctp-test.pcap
256+
$ sudo tcpdump -i ens18 port 2152 -w gtp-outside.pcap
257+
$ sudo tcpdump -i access port 2152 -w gtp-inside.pcap
258+
$ sudo tcpdump -i core net 172.250.0.0/16 -w n6-inside.pcap
259+
$ sudo tcpdump -i ens18 net 172.250.0.0/16 -w n6-outside.pcap
260+
261+
The first trace, saved in file ``sctp.pcap``, captures SCTP packets
262+
sent to establish the control path between the base station and the
263+
Mobile Core (i.e., N2 messages). Toggling "Mobile Data" on a physical
264+
UE, for example by turning Airplane Mode off and on, will generate the
265+
relevant control plane traffic; gNBsim automatically triggers this
266+
activity.
267+
268+
The second and third traces, saved in files ``gtp-outside.pcap`` and
269+
``gtp-inside.pcap``, respectively, capture GTP packets (tunneled
270+
through port ``2152`` ) on the RAN side of the UPF. Setting the
271+
interface to ``ens18`` corresponds to "outside" the UPF and setting
272+
the interface to ``access`` corresponds to "inside" the UPF. Running
273+
``ping`` from a physical UE will generate the relevant user plane (N3)
274+
traffic; gNBsim automatically triggers this activity.
275+
276+
Similarly, the fourth and fifth traces, saved in files
277+
``n6-inside.pcap`` and ``n6-outside.pcap``, respectively, capture IP
278+
packets on the Internet side of the UPF (which is known as the **N6**
279+
interface in 3GPP). In these two tests, ``net 172.250.0.0/16``
280+
corresponds to the IP addresses assigned to UEs by the SMF. Running
281+
``ping`` from a physical UE will generate the relevant user plane
282+
traffic; gNBsim automatically triggers this activity.
283+
284+
If the ``gtp-outside.pcap`` has packets and the ``gtp-inside.pcap``
285+
is empty (no packets captured), you may run the following commands
286+
to make sure packets are forwarded from the ``ens18`` interface
287+
to the ``access`` interface and vice versa:
288+
289+
.. code-block::
290+
291+
$ sudo iptables -A FORWARD -i ens18 -o access -j ACCEPT
292+
$ sudo iptables -A FORWARD -i access -o ens18 -j ACCEPT

0 commit comments

Comments
 (0)