In tunmap scenario there's usually 2 PDRs/local-F-TEIDs per session,
hence it makes sense to at least double the hashtable size with respect
to session hashtable. In here we actually multiply it by 2 twice since
this is actually global and not per peer, hence we account for multiple
peers.
Change-Id: I7ee3e875020d707c05e13ee70952174ca4daad30
During a 200K session setup, this can still take quite a noticeable
amount of time (20% of a full CPU) during session creation.
Change-Id: I424778a4c75000fb67ba4725a6a3e3e91a80fc76
This is used every time a new PFCP session was being allocated.
It allows looking up if a given UP SEID exists in any of the peers.
Before this patch, iterating over tens/hundreds of UP peers on every
session creation took 38% of a full CPU.
Change-Id: I617b405e59a3435a1c4912bf4161bc9e036754b4
Use this hashtable while looking up for tunend based on
<access.local.teid, access.remote.teid, access.remote.addr>.
This kind of look up is used every time a session is added or removed,
which means potentially thousands of tunend sessions were being iterated
linerarly every time.
For simplification (easier/quicker hashtable key generation), reduce the
whole key presented above to a more general one based on
"access.local.teid". This is usually enough since we are anyways
allocating local TEIDs globally per tunnel without caring about remote
address.
Change-Id: Ib12ecc8ce87175071c52c0ed2217a29d901f0f05
This lookup was taking ages specially when UPF already managed thousands
of sessions.
Related: SYS#6398
Change-Id: I7df8fd945eedbda98bd08e9fb2f382e0f55c2983
This is a hot path when creating new sessions. Previous code would take
ages specially when UPF already had thousands of sessions created and a
new TEID to allocate was being looked up.
Related: SYS#6398
Change-Id: I90ecbb07b242c1de2298261019f24aa5f5810fda
Allow sending GTPv1-U Echo Requests to GTP peers via new VTY command
gtp1u-echo send to (A.B.C.D|X:X::X:X)
gtp1u-echo send to (A.B.C.D|X:X::X:X) local-ip (A.B.C.D|X:X::X:X)
gtp1u-echo send to (A.B.C.D|X:X::X:X) local-dev DEV_NAME
Related: OS#6541
Tweaked-by: Oliver Smith <osmith@sysmocom.de>
Change-Id: I970dccd7a27b098eea9e660822e24e2c4b059fc6
Store nftables ruleset commands for a limited time and a limited volume
before submitting in batch, in order to minimize the overhead associated
with submitting nftables commands.
Configurable by 'timer nft X32' and 'X33'
Change-Id: Ib0a8e86b29bab1559d94fc55a89daa00ec670318
When handing out a chain_id, make sure it is not in use yet.
So far picking a chain_id was of PoC grade quality. As osmo-upf is
approaching production grade, make this waterproof.
So far with inefficient iteration of all sessions; faster lookup follows
in I36a75ec4698cd83558185c1f202400eb53ae8ff6.
Related: OS#5900
Change-Id: I139b46de0bd15185a7a06109d55f7c759755ec81
Verify that skipping used IDs works for:
- PFCP UP-SEID
- GTP local TEID
- chain_id for nft rulesets -- so far expected to fail,
fix follows in I139b46de0bd15185a7a06109d55f7c759755ec81.
Related: OS#5900
Change-Id: I36acff15f22d23ade4d281c2af3eb117dfc10359
up_endpoint is about the PFCP endpoint, handing out local TEID is about
local GTP endpoints. Move the TEID allocation to g_upf / upf.c.
An upcoming patch will use a hash table in g_upf to speed up lookup
whether a local TEID is already in use; cosmetically prepare for that.
Change-Id: I8eae5b53c563400ddfded264678d9cfb28b6f737
Upcoming patch I8eae5b53c563400ddfded264678d9cfb28b6f737 will introduce
a g_upf->gtp sub struct for more generally GTP related things (local
TEID assignment).
Change-Id: I74df838af50f38604e2ff06cac0af11ccfdab386
Use a common struct upf_tun_ep and struct upf_tun for both tunend and
tunmap definitions, with a nicer local / remote sub-structuring.
Change-Id: I07866e2acbeb74914e1fd6f66839a5a8ae247b1e
The "desc" has no meaning, every struct is a description of its data.
The "nft" and "gtp" hint at the specific "nftables" and "GTP kernel
module" implementations. I'd rather keep it more abstract and shorter.
That serves removing dup of shared bits in an upcoming patch.
Change-Id: I15e4552a20067265abb8d2dd716861cd50270028
Take care of two problems:
- limitation of <= 1024 base chains in nftables, so far meaning we can
establish at most 1024 GTP tunnel mappings.
- mangling of source IP in prerouting so far meaning that the system
needs to be configured to permit 'martian' packets
The new ruleset separates in pre- and post-routing, so that we set a new
destination IP address in pre-routing, and set a new source IP address
in post-routing. Hence no problem with martian packet rejection.
The new ruleset uses verdict maps, which are more efficient, and do not
hit a limit of 1024 as base chains do.
Before, the nft rule used one chain id. In the new ruleset, each tunmap
now needs two distinct chain ids. Refactor.
Related: SYS#6327 SYS#6264
Change-Id: Iccb975a1c0f8a2087f7b7dc4942a6b41f5675a13
Subsequent patch will refactor the tunmap nft ruleset. Instead of
adapting the 'tunmap append' feature to the new ruleset, rather drop
this feature entirely.
The 'nft rule tunmap append' was intended for enabling 'trace' in the
nft ruleset. However, the same can be achieved via the nft cmdline tool.
For example:
sudo nft 'add chain filter trace_chain { type filter hook prerouting priority -301; }'
sudo nft 'add rule filter trace_chain meta nftrace set 1'
Related: SYS#6327 SYS#6264
Change-Id: I1ae36f2f520217254c81fd765d27333ff0f457b2
upf_gtp.h is for the GTP kernel module interaction. The GTP port numbers
are also relevant for the netfilter part, upf_nft.h. An upcoming patch
will use PORT_GTP1_U in the nft ruleset.
Related: SYS#6327 SYS#6264
Change-Id: I37d13cfee225c7ee2cc45525b76d9579d65e847c
Implement handling of the Network Instance IEs from PFCP for tunend,
like already done for tunmap.
In 'tunend' cfg, allow indicating a local GTP address for both 'dev
create' and 'dev use'. Select a GTP device by the local address the
Network Instance IE in PFCP PDR indicates.
Related: SYS#6192
Change-Id: I376c09bfc1844df1e61d2efac17561fac614858b
It can be useful to add 'meta nftrace set 1' to nftables rules to help
analysis / site debugging. Add the possibility to do this by cfg.
Instead of adding the fixed string of 'meta nftrace set 1', allow
appending arbitrary strings to the nftables rules, to accomodate any
other future tweaks that may be useful.
Related: SYS#6192
Change-Id: Ia1fac67108902a48b43d8d1dc184ccf541fd9ba8
Separate string composition of the nftables ruleset from the actual
actvation of the ruleset to nftables.
For a 'show' VTY command added in upcoming patch, I'd like to be able to
vty_out() an nftables rule set. Provide API for that.
Change-Id: I0124a68ccf1ac7b90c5cc32d0cbf58d0cc219ccc
Make sure an assigned id is not overwritten.
So far this function was guaranteed to be called only once. But I would
like to allow getting the nftables ruleset string more than once in a
future patch. Prepare that.
Change-Id: I4e8c48c01fb2f5d4cfd223fe03abbf15b1a55670
At first, this mostly improves logging of GTP actions.
Subsequently, we will use these to:
- for tunend, pick a GTP device based on the local interface.
- for tunmap, change the netfilter rules to match on the *local* GTP
address instead of the remote one.
Related: SYS#6192
Change-Id: I8488c478c4790d3882b22dcdb1f127838e23dd7b
Add 'netinst' config section to osmo-upf.cfg, to define Network Instance
name to local IP address mappings.
For the tunmap use case (forwarding GTP tunnels), heed the Network
Instance IEs in PFCP session creation and return IP addresses in F-TEIDs
accordingly.
Related: SYS#6192
Related: I37bebc7d6ef75c3e6ae05e81b83a1b5895839a64 (osmo-ttcn3-hacks)
Change-Id: I15ee046a1c37b83b8a83527a67a6215a30106d81
No functional change.
Rename forw_to_core to access_to_core.
Rename forw_from_core to core_to_access.
Rename add_gtp_action_endecaps to add_gtp_action_tunend.
Rename add_gtp_action_forw to add_gtp_action_tunmap.
Add assertions to clearly indicate expected PDR and reverse PDR
directions.
Tweak various comments and log messages.
Fix some comments that have Access / Core flipped.
Change-Id: Ia199bb6944476eff6af89b5ab015a9a2f8ce330e
Indicate whether a shown IP address is local or remote, by adding '-l'
or '-r' to the field names shown.
So far, osmo-upf is only tracking remote GTP addrs, but we are about to
implement choosing local GTP addrs by Network Instance IEs. Those should
also be shown and will need to be set apart from the remote addresses.
Related: I440466f1cc9689391869ac2579a4497ef6008adb (osmo-ttcn3-hacks)
Change-Id: Ic539ebe84a0853f665e5b8b8489dd587e6907287
So far the config nodes were named after the implementation:
"GTP kernel module" = "gtp" and
"netfilter" = "nft"
We found that this is confusing, since both are related to handling GTP.
Rename "gtp" to "tunend"; a subsequent patch will rename "nft" to
"tunmap".
Keep a hidden "gtp" VTY cmd as backwards compat alias.
In log output, also print "tunend" instead of "endecaps"
(up_gtp_action_to_str_buf()).
Related: SYS#6192
Change-Id: I49ac7b1f8b5b74f586edfed1dfb29f9af55a521b
Allow running without opening a GTP dev for encapsulation/decapsulation.
Probe and open the mnl socket for talking to the GTP kernel module only
when actual GTP devices exist in the config.
A site that is only doing tunnel proxying via netfilter hence does not
require GTP support in the kernel.
Change-Id: Ibb79b3ce1906136f77a895ff6f691d72a92c9fb9
Accept data on the GTPv1-U socket and respond to GTPv1-U ECHO REQUEST
messages.
We should keep a deterministic recovery counter that increases with
every restart. As a quick and dirty way just use the current time at
startup for now, until osmo-upf reaches production maturity.
Related: OS#5599
Change-Id: I135370a7723e2c667ec681f50c21107cde63ea5b
Implement support for PFCP rulesets that ask for mapping a GTP tunnel:
forwarding GTP payload between two GTP tunnels.
For a GTP tunnel mapping, dispatch netfilter rules that detect GTP
packets with a given source address and TEID, and replace the TEID and
destination address according to the PFCP ruleset.
The netfilter implementation is chosen to effect the packet rewriting
and forwarding to take place directly in the kernel, for high throughput
of GTP packets.
Related: SYS#5599
Change-Id: Ic0d319eb4f98cd51a5999c804c4203ab0bdda650
To avoid actions that require cap_net_admin permissions on build
servers, add this option to "dry run" all kernel GTP actions. Same will
be added for netfilter rules.
On startup, osmo-upf opens sockets to GTP kernel module / NFT ctx.
However, on build servers, this would require giving cap_net_admin
permissions just to run the VTY tests.
Related: SYS#5599
Change-Id: I3b9c796186307fd8562abcff3f0ccfab0e88b6c8
So far we had only osmo_pfcp_enc_to_str_node_id(), used for PFCP message
to string conversion. It behaves like a common _to_str_buf() function,
but has an inconvenient void* arg (for use with libosmo-tlv).
Implement the string conversion as common _to_str_buf() and _to_str_c()
functions, and call that from osmo_pfcp_enc_to_str_node_id(). That's
useful for log messages coming up in a subsequent patch.
Related: SYS#5599
Change-Id: I5c580bc510afce58a03dea0861db9630b063b2ae
The spec indicates three bytes of CP Function Features, but both
wireshark and ttcn3 expect only one byte. This makes sense because only
eight CP F.F. flags are defined.
Drop those two always-zero bytes, hence pass the wireshark dissector and
ttcn3 parsing without warnings.
Related: SYS#5599
Change-Id: Icda891a2f3401e58f142f229465403d5dc8befe5
During code review, it was indicated that some TLV protocols that we
will likely deal with in the near future also employ an I, and instance
value of a tag. Add TLIV support.
A usage example for a manually implemented TLIV structure is found in
tests/libosmo-gtlv/gtlv_test.c.
A usage example for a generated TLIV protocol is found in
tests/libosmo-gtlv/test_tliv/.
Related: SYS#5599
Change-Id: I0a076e54dfba6038cc779cb7c8f3967d212226aa
