eUPF Integration with Nokia CMU SMF #535
Unanswered
howardswe499
asked this question in
Q&A
Replies: 7 comments 6 replies
-
|
Hi Howard @howardswe499 , Well, there are several issues. Let's go step by step:
As a conclusion. My proposal is to fix/configure CMU to send correct PDR instructions if it's possible. Also I think it's possible to just ignore empty SDF filter on eUPF side in order not to skip the whole PDR and allow to forward downlink traffic. I can fix it with ease. -- BR, Alex |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Hi Alex @pirog-spb , I appreciate your quick and helpful reply. Interesting! Your explanation really clarified for me what goes on behind the scenes. I hadn't considered that the empty SDF filter field was part of the problem, and also that Outer Header Removal value was not boolean. That explains a lot! The problem is, I'm not very familiar with CMU configuration, so it may take a while for me to find out how to configure the PDR instructions so that Also, it would be very helpful if you could inform me how to let eUPF ignore the empty SDF filter. Many thanks |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pirog-spb , I was wondering where you got the information regarding result code from point no. 3? I ran into an issue where I got result code 8 on |
Beta Was this translation helpful? Give feedback.
-
|
Nevermind, I found out it meant Here are the rest of the codes if other people are interested |
Beta Was this translation helpful? Give feedback.
-
Take a closer look at CMU's N3 configuration. I suppose, CMU misconfigured to threat connection to UPF as IPv6-based. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@howardswe499 You can try fix for empty SDF Filter from #538 |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Hi Alex @pirog-spb , I updated the project using the following commands However, the PDR with empty SDF filter is still being ignored, here are the eUPF, XDP logs, and API outputs: Thanks for your help |
Beta Was this translation helpful? Give feedback.
-
|
@howardswe499 Could you provide pcap dump for this scenario? Seems like the SDF Filter is not empty but contains spaces or some other unexpected content. May be as well the PFCP library used in eUPF fails to decode SDF Filter correctly. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Hi Alex @pirog-spb , I took a look at the packet, and this was in the problematic PDR's SDF filter field (Flow Description seems to be absent as there is no Flow Description flag): Hope this helps. BR |
Beta Was this translation helpful? Give feedback.
-
|
I've double-checked fix and see no way it may not satisfy you scenario. Could you please recheck on this commit |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Hi @pirog-spb , I've updated to commit Here are the logs (Changes made were that I added 172.16.13.0/24 as N3 network): Thanks for the help. |
Beta Was this translation helpful? Give feedback.
-
|
Looks strange, because in the last commit I slightly changed log format. Instead of: should be (results are quoted) Could you please double check that you run right version of eUPF? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Great news, the fix works! The program was indeed not getting updated properly (probably due to my end, honestly). I checked the ~/eupf/bin/eupf file's modification date, and it was showing an older version. I tried deleting the whole ~/eupf/bin/ folder, then re-building eupf, but that didn't work either (no /bin/eupf was created). So I ended up saving my config files, deleting the ~/eupf folder, and re-cloning the repo. Here are the logs, the PDR with the empty SDF filter field is no longer getting ignored!: Logs
Thanks for your work and patience. Cheers, |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi All,
I'm trying to perform integration with Nokia CMU (Nokia's 5G core solution), using eUPF as UPF and UERANSIM as UE+RAN.
I've run into a problem where eUPF seems to be unable to forward packets that are received from RAN. On the tcpdump of packets outgoing RAN, when performing "ping -I uesimtun0 8.8.8.8", I'm getting "ICMP udp port 2152 unreachable" message from eUPF.
(192.168.102.54 = UERANSIM; 192.168.102.55 = eUPF)
Here are the logs of eUPF:
Here are the logs of UERANSIM:
I did not have XDP logging enabled when I performed the above tests, but I did obtain XDP logs on the same test performed later:
(I enabled XDP logs using steps described here:
Here are XDP logs from O5GS integration, which works as intended.
Finally, here are the API outputs I grabbed of both CMU and O5GS:
The main problem I noticed in these logs was the fact that the SDF filter sent in "PFCP Session Establishment Request" was unable to be processed by eUPF due to not conforming to regex rules. This lead to default SDF filter rules being applied (source 0.0.0.0/0 dest 0.0.0.0/0 port range 0~65535), which would match every packet that comes in to the interface to use TEID=1. Then, a fib lookup of 192.168.102.54->192.168.102.55 was performed, but with the result "4" being outputted. I checked the logs with open5gs integration, and the fib lookup would usually result in xdp outputting the next-hop IP address, so this output of "4" was curious to me.
I suspect with CMU the behavior is caused by the packet being matched with PDR 18944, which has OuterHeaderRemoval value of 1, as opposed to O5GS which matched the packet with a PDR that has OuterHeaderRemoval value of 0.
I would be grateful for any assistance. Please let me know if any other info could be provided. Thanks in advance.
BR
Howard
Beta Was this translation helpful? Give feedback.
All reactions