Repository navigation
Conversation
|
@edgecomllc any feedback here? Something I should look at or fix? |
|
Hi @pespin It's a awesome contribution! BTW, is the underlined part below necessary?
Also, what did you use for the 5G Core C-Plane to verify the ULCL operation? Please let me know if you don't mind. Thanks. |
|
@s5uishida thanks for reviewing, indeed that log line was not expected to end up in the PR! I'll submit a new version now. To validate the GTP-U forwarding towards another UPF/GSN (what we tend to call tunmap in osmo-upf) I used the osmo-upf-load-gen we wrote in https://gitea.osmocom.org/cellular-infrastructure/upf-benchmark. We have been using it so far to test both osmo-upf and eupf in our own hardware setup, both with similar results so far, reaching ~2 MPPS and ~20-24 Gbps aggregated (DL+UL) traffic in both tunmap and tunend scenarios. We plan to improve the setup and the mechanisms to generate more traffic as time allows in the future (eg. using TRex), since we seem to also be now CPU constrained regarding traffic generation. |
Until now, eupf only allowed configuring the local IP address for the N3 interface, which actually ended up being used for both N3 and N9 (GTP-U forwarding towards other uplink UPFs). However, that limitation becomes a problem under some production scenarios. Some users require running a UPF to forward GTPv1U traffic from network A to network B and viceversa, where those 2 networks are not reachable to each other, only through the UPF host. This happens for instance when cellular operators don't control/own the entirety of their networks, e.g. a network which runs their NAT under a satellite link with private addresses (eg VPN) which end up at a single host. As a result, the UPF requires managing at least 2 separate local IP addresses for GTP-U traffic: One (usually private) IP address towards the RAN, and one (usually public, or another private network) IP address towards the Core. As a result, when a PFCP client (an SMF, or osmo-hnbgw, or osmo-s1gw to mention some other examples) tries to setup a session to forward GTPU traffic from network A (RAN) to network B (Core), will result in eUPF forwarding the GTP-U packet to the Core but using the RAN configured IP as the GTPU packet local IP address. Hence, either local routing will be wrong, or the Core will drop the received packet, or won't know how to route traffic back to it. This patch allows eupf to be used co-located with 3G osmo-hnbgw [1] and 4G osmo-s1gw [2] under the mentioned network setups, both supporting PFCP to manage a UPF to forward data plane also in GTP1U protocol. [1] https://osmocom.org/projects/osmohnbgw [2] https://gitea.osmocom.org/erlang/osmo-s1gw Related: edgecomllc#577
|
Hi @pespin, Sorry for the delay. I have two common point on this PR:
What do you think? Does it make sense? -- BR, Alex |
|
@pirog-spb I have this in my TODO list, will have a look soon whenever I find some time. |
If you don't mind, I'd do it myself |
|
@pirog-spb maybe in that case you could submit a PR with my patch + your changes on top making the N9 IP address optional and merge them without squashing? I'd be happy with that approach. |
|
@pirog-spb also if you want let me know when you submit the PR, I can give it a test in our gtplab setup to confirm it's working fine. |
|
Abandoning in favour of #585 |
Until now, eupf only allowed configuring the local IP address for the N3 interface, which actually ended up being used for both N3 and N9 (GTP-U forwarding towards other uplink UPFs).
However, that limitation poses so problems under some production scenarios. Some users require running an UPF to forward GTPv1U traffic from network A to network B and viceversa, where those 2 networks are not reachable to each other, only through the UPF host.
This happens for instance when cellular operators don't control/own the entirety of their networks, e.g. a network which runs their NAT under a satellite link with private addresses (eg VPN) which end up at a single host.
As a result, the UPF requires managing at least 2 separate local IP addresses for GTP-U traffic: One (usually private) IP address towards the RAN, and one (usually public, or another private network) IP address towards the Corei. As a result, when a PFCP client (an SMF, or osmo-hnbgw, or osmo-s1gw to mention some other examples) tries to setup a session to forward GTPU traffic from network A (RAN) to network B (Core), will result in eUPF forwarding the GTP-U packet to the Core but using the RAN configured IP as the GTPU packet local IP address.
Hence, either local routing will be wrong, or the Core will drop the received packet, or won't know how to route traffic back to it.
This patch allows eupf to be used co-located with 3G osmo-hnbgw [1] and 4G osmo-s1gw [2] under the mentioned network setups, both supporting PFCP to manage a UPF to forward data plane also in GTP1U protocol.
[1] https://osmocom.org/projects/osmohnbgw
[2] https://gitea.osmocom.org/erlang/osmo-s1gw
Related: #577