neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-upf/+/30833 )

Change subject: manual: explain new netinst cfg ......................................................................

manual: explain new netinst cfg

Related: SYS#6192 Change-Id: I1d636b8a6ae7628b4369734a45e60f2eaf437dce --- A doc/manuals/chapters/netinst.adoc M doc/manuals/osmoupf-usermanual.adoc 2 files changed, 58 insertions(+), 0 deletions(-)

Approvals: Jenkins Builder: Verified pespin: Looks good to me, but someone else must approve laforge: Looks good to me, approved

diff --git a/doc/manuals/chapters/netinst.adoc b/doc/manuals/chapters/netinst.adoc new file mode 100644 index 0000000..3add2bb --- /dev/null +++ b/doc/manuals/chapters/netinst.adoc @@ -0,0 +1,56 @@ +== Local GTP Addresses / Network Instance + +PFCP features optional Network Instance IEs, in which the CPF may tell the UPF which local network interface to use for +a PDR and/or a FAR. + +NOTE:: osmo-upf only evaluates the Network Instances configured in PDRs. Since osmo-upf always pairs a PDR+FAR with +another PDR+FAR in reverse direction, each side's PDR is sufficient. + +Network Instance IEs affect both the tunend and the tunmap use cases, as well as which local IP address is returned +in the PFCP response + +1. Look up Network Instance name in the osmo-upf.cfg `netinst` section, to obtain a local IP address. +2. Depending on use case: + - tunend: create the tunnel on a GTP device matching the local IP address, see <<gtp_module>>. + - tunmap: use the local IP address in the netfilter ruleset, see <<nftables>>. +3. Usually, return the chosen local IP address in the F-TEID IE of the Created PDR IE in the PFCP response. + +Network Instance configuration consists of {name, IP address} pairs. + +NOTE:: As soon as a `netinst` configuration is nonempty, receiving an undefined Network Instance name results in a PFCP +Reject response, and a log message on cateogry `session`, level `NOTICE`. To make the PFCP return success, add the +failing name to the `netinst` config. + +=== netinst for tunend + +The following configuration sets up two GTP devices for tunend, expecting Network Instance names `access1` or `access2`: + +---- +tunend + dev create apn1 10.0.0.1 + dev create apn2 10.0.0.2 +netinst + add access1 10.0.0.1 + add access2 10.0.0.2 +---- + +For example, if a Create PDR IE indicates Network Instance = `access1`, a GTP tunnel is set up in GTP kernel device +`apn1`. For `access2`, use `apn2`. + +=== netinst for tunmap + +For the tunmap use case, it is sufficient to configure `netinst` entries, without any addition to the `tunmap` section. +The following example configures various interfaces for tunmap, to match Network Instance names received in PFCP: + +---- +tunmap + table-name osmo-upf +netinst + add access1 10.0.0.1 + add access2 10.0.0.2 + add core1 9.0.0.1 + add core2 9.0.0.2 +---- + +For example, a Create PDR indicating a Network Instance of `core1` will result in an nftables rule that receives packets +on local address `9.0.0.1`. diff --git a/doc/manuals/osmoupf-usermanual.adoc b/doc/manuals/osmoupf-usermanual.adoc index 0e0e7b7..49e3e23 100644 --- a/doc/manuals/osmoupf-usermanual.adoc +++ b/doc/manuals/osmoupf-usermanual.adoc @@ -11,6 +11,8 @@

include::{srcdir}/chapters/running.adoc[]

+include::{srcdir}/chapters/netinst.adoc[] + include::./common/chapters/vty.adoc[]

include::./common/chapters/logging.adoc[]

2 is the latest approved patch-set. No files were changed between the latest approved patch-set and the submitted one.