Does the free5gc v3.0.3 dockerized version is validated for data transfer with all protocols like ICMP, TCP and UDP?

Q/A
#1

Hi,

I would like to understand the type of data transfer testing done with the Free5GC v3.0.3 dockerized version.

We could see some discussion in this blog related to data transfer testing using All-in-One-VM version of Free5GC. That too mostly Ping (ICMP) validation.

But in the containerized deployment, is there any data tranfer is validated?

If it is validated, what are all types of Protocols are being leveraged for this data path testing?

Your inputs will help me in great extent.

Thank you for your support.

Thanks & Regards,
Anand

#6

Hi,

I think you need to checkout this: https://docs.docker.com/network/iptables/#docker-on-a-router

Otherwise, did you tried to run using host network (https://docs.docker.com/network/host/) and set all NFs IPs to localhost ? You can escape Docker network config using this option.

BR,
AB

#2

Hi,

We have only simply verify it by icmp (ping) and web browsing with video streaming.

#3

Hi,

Greetings !

Thank you very much for your timely response.

Just re-confirming again. Were this icmp (ping) and web browsing with video streaming tested in dockerized environment or in VM environment?

Our Problem Statement:
• We have been using free5gc v3.0.3 dockerized version. We have deployed Free5GC core using dockers and leveraging RAN Emulator that is developed by us to trigger the test scenarios.
• We could able to do UE registration successfully and the UE IP address for the PDU session was received.
• We tried to Ping google IP address, it was successful. Then we started the TCP data using “wget google’s IP address”. But it was not successful. Similar result for UDP data transfer too.
• After verifying the logs at UPF, we could observe the GTP decapsulation is done at UPF kernel module. But the decapsulated packet needs to be SNATed using the IPtables rules that were already added. But it is not source NATed and the packets are not reaching the destination (extenal server).

Note-1: But ICMP packets are successfully Source NATed, sent outside by UPF and reached the destination using the same dockerized environment…
Note-2: However we had tested successfully ICMP, TCP & UDP protocols in VM based environment (deployed Free5GC in All-in-One-VM)

Since we are pitching free5GC to our customers who need control plane and user plane validation in dockerized environment, we want to ensure this support is already there, if not what is the roadmap.

Looking forward to your reply.

Thanks & Regards,
Anand

#4

The default iptables set by docker will disallow packet with source that are not in the range of docker assigned. The fastest way to fix it is to put a higher priority “accept all” above docker’s rule.

Try and check if it can solve the issue.

Note: After UPF decapsulated the packet, the issue will not stay in 5GC. You should check your system setting.

#5

Hi,

Thank you for your prompt response.

As per your response, We had tried to apply the following rules to override the rules set by docker.
iptables -I INPUT -j ACCEPT
iptables -I FORWARD -j ACCEPT

During ICMP traffic flow, both rules were hit. It was validated using the hit count.
However during TCP and UDP traffic flow, the 1st rule was hit and not the second. So the packet is not sent to the destination.

Would like to hear from you about this approach.

Thanks & Regards,
Anand