Open ljysdfz opened 2 years ago
Can you please attach a trace for the issue taken on both the VMs?
My suspicion is that since both (gNB + UE) and 5GC are running in two VMs behind a NATed IPs (192.168.100.X) there maybe a need for static route in 5GC host machine to reach gNB
@herlesupreeth
I have been weighing up the possibility of the circumstances you have suggested. But in fact, if there is any problem with the visibility for 5GC to reach gNB, then it can't be done for UE to ping UPF through eth0
. I have shown that a UE is capable of reaching UPF and vice versa in one of above clips. So I guess the nature of the problem is that the uesimtun0
failed to bind the eth0
, so there is not any traffic that have been sent through uesimtun0
. But unfortunately, the UERANSIM indicated that the tunnel has been established.
I've used tcpdump
to capture the ICMP packets of ping
. Actually, when we used the uesimtun0
as the NIC ingress, the tcpdump didn't receive any packets. On the contrary, when we used eth0
as the NIC ingress, ICMP traffic could be seen on the screen.
From the perspective of RAN as pinging through eth0
From the perspective of 5GC as pinging through eth0
If I were to have more time to establish an IDE for stepping in the code, I should find the bug.
Hello! I am in the same situation with srsRAN. I can't ping the upf using the ue tunnel. Any update on this topic? @ljysdfz Thanks.
@RaulB16 Sorry, just recognized your comment. I've adopted a new docker network driver named IPVLAN. It acts like the UE/gNB uses a IP address in the same subnet as the host of 5GC. For example, UE (192.168.12.2) gNB (192.168.12.3) 5GC host (192.168.12.4). The 5GC NFs lurk behind the 5GC host as before under a bridge network driver.
@herlesupreeth
Hello, Herle and every other lovely guy. I have tried to externalize ueransim and deploy it in a separate VM that resides outside the 5GC SA networks. ueransim part was left as much the way as it used to be. My version of open5gs is v2.4.7, ueransim version is v3.2.6. This is the specific topology:
Both of the gNB and UE were up, but I found that the UE failed to ping
192.168.100.1
, that is the data plane of UPF.gNB log:
ip route table in gNB
NIC list in gNB
UE log:
ip route table in UE
NIC list in UE
What's weird was that UE was able to ping
192.168.100.1
through the NICeth0
.And if you look at the proper examples in the integrated version set up before, you can find that the name of eth0 should be
eth0@uesimtun0
instead ofeth0@if14
. In that way, the traffic enters eth0 will finally pass through the GTP-U tunnel.the proper one:
From here, I will show what have been configured in the VMs. I've done these things in the VM-5GC, aka 5GC SA networks:
.env
file, changeUPF_ADVERTISE_IP
->DOCKER_HOST_IP
sa-deploy.yaml
file, uncomment these 2 code blocks in order to enforce port mappings.I've made a new folder
ran/
for the individual RAN. Here is a breakdown of the file system.I will list a series of aforementioned configuration out here:
ran/gnb/Dockerfile
ran/gnb/open5gs-gnb.yaml
ran/ue/Dockerfile
ran/ue/open5gs-ue.yaml
ran/nr-gnb.yaml
ran/nr-ue.yaml
In light of the fact that there is only ONE IP allocated per VM, so that there is no more host IP space for a
vlan
(ipvlan or macvlan) driver, though I've made it through by using aipvlan
for the target scenario. I have to use thebridge
driver to save IP addresses. I hope whoever is looking at this would come up with a favorable advice or solution. Thank you in advance.