interface detection and add into the meta data when packet arrives
sothy opened this issue · comments
The currently rules detection works with tunnel id (for uplink) and UE IP address (for downlink). I try to makes as I-UPF. so I have to use source interface to find the matching rule id.
I'm sharing you the code I developed ( not best one, working well).
https://bitbucket.org/sothy5/upf/commits/35eb80e383d72d2d3d4126049b17ff15b0099de1?at=feature/2001/upf
I will modify code again to get the source interface based on receiving IP address.with upf_main_t.
I don't understand what problem you are trying to solve. The UPF is perfectly capable of taking incoming GTP-U packets and forwarding them through another GTP-U tunnel. We do use that setup quite a lot.
Can you post a PFCP trace with your PDR's and FAR's? That might explain it best.
@RoadRunnr sorry for the response.
My case I am assign two PDR with same tunnel id, but differ SDF values. so that I-UPF can do UL CL.
show upf session
CP F-SEID: 0x0000000000000001 (1) @ 172.32.1.1
UP F-SEID: 0x0000000000000001 (1) @ 172.42.1.2
Sx Association: 1
PDR: 1 @ 0x7fc58e146790
Precedence: 32
PDI:
Fields: 0000000d
Source Interface: Access
Network Instance: access
Local F-TEID: 1 (0x00000001)
IPv4: 172.40.1.2
UE IP address (source):
IPv4 address: 172.105.1.241
SDF Filter [1]:
permit out ip from any to 172.43.1.1
Outer Header Removal: GTP-U/UDP/IPv4
FAR Id: 1
URR Ids: [] @ 0x0
QER Ids: [] @ 0x0
PDR: 2 @ 0x7fc58e146818
Precedence: 32
PDI:
Fields: 0000000d
Source Interface: Access
Network Instance: access
Local F-TEID: 1 (0x00000001)
IPv4: 172.40.1.2
UE IP address (source):
IPv4 address: 172.105.1.241
SDF Filter [1]:
permit out ip from any to any
Outer Header Removal: GTP-U/UDP/IPv4
FAR Id: 2
URR Ids: [] @ 0x0
QER Ids: [] @ 0x0
PDR: 3 @ 0x7fc58e1468a0
Precedence: 32
PDI:
Fields: 00000004
Source Interface: Core
Network Instance: core
UE IP address (destination):
IPv4 address: 172.105.1.241
Outer Header Removal: no
FAR Id: 3
URR Ids: [] @ 0x0
QER Ids: [] @ 0x0
PDR: 4 @ 0x7fc58e146928
Precedence: 32
PDI:
Fields: 00000005
Source Interface: Core
Network Instance: core
Local F-TEID: 2 (0x00000002)
IPv4: 172.41.1.2
UE IP address (destination):
IPv4 address: 172.105.1.241
Outer Header Removal: GTP-U/UDP/IPv4
FAR Id: 3
URR Ids: [] @ 0x0
QER Ids: [] @ 0x0
FAR: 1
Apply Action: 00000002 == [FORWARD]
Forward:
Network Instance: core
Destination Interface: 2
FAR: 2
Apply Action: 00000002 == [FORWARD]
Forward:
Network Instance: core
Destination Interface: 1
Outer Header Creation: [GTP-U/UDP/IPv4],TEID:00000001,IP:172.30.1.2
FAR: 3
Apply Action: 00000002 == [FORWARD]
Forward:
Network Instance: access
Destination Interface: 0
Outer Header Creation: [GTP-U/UDP/IPv4],TEID:00000001,IP:172.40.1.1
My case I am assign two PDR with same tunnel id, but differ SDF values. so that I-UPF can do UL CL.
I assume you mean the PDIs in PDR 1 and 2, right?
Those two PDIs have the same precedence. It is therefore pure luck which one will be applied.
My guess is that you want PDR 1 to take precedence over PDR 2. You have to reflect that through a lower precedence value.
Also, the PDI in PDR 3 is not valid. You can't try to detect unencapsulated traffic on the Core interface type. You either have to use a tunnel there or switch that to the SGi interface type.
It seems that you are trying to route SGi traffic over the Core interface (FAR 1 also makes that impression). This is not supported by VPP/UPF and I doubt that TS 29.244 does even permit such a setup. You have to seperate Access, Core and SGi.
I'm working in UL CL traffic in I-UPF. PDR 1 has SDF for forwarding to local access of Sgi interface or DN. So it will go to the edge computing network.
PDR2 has SDF for forwarding the traffic to UPF, then go central DN.
IMO, precedence does not work in this situation. a for single PDU session, I-UPF will receive data on same TEID. In order to do two different actions, I should do as specified TS 29.244.
regarding PDR3, you right. I-UPF connects to two UPF( one central DN and another one local DN for edge computing). so core has GTP connection to two UPFs.
Sometimes, I-UPF and UPF for local DN can be merged. so Access,Core and Sgi should be defined in a single UPF. In my setup, it works. Core together Sgi works. (not clean).
I'm working in UL CL traffic in I-UPF. PDR 1 has SDF for forwarding to local access of Sgi interface or DN. So it will go to the edge computing network.
PDR2 has SDF for forwarding the traffic to UPF, then go central DN.
IMO, precedence does not work in this situation. a for single PDU session, I-UPF will receive data on same TEID. In order to do two different actions, I should do as specified TS 29.244.
Precedence is the ONLY thing that works in this setup. That TS 29.244 does not specify any ordering of PDRs except for precedence. There is no notion of "matches more that the other rule" (again, except for precedence). Both PDRs are nearly identical (same Source Interface, Network Instance, IP, and TEID, different SDF and FAR), so both will match on the same traffic. Because they have the identical precedence, the UPF is free to apply whichever of the two rules is chooses. If you want one rule to take precedence, you have to set the precedence value accordingly.
Also, the any to any SDF might no be a valid expression (see #50 (comment)).
regarding PDR3, you right. I-UPF connects to two UPF( one central DN and another one local DN for edge computing). so core has GTP connection to two UPFs.
Sometimes, I-UPF and UPF for local DN can be merged. so Access,Core and Sgi should be defined in a single UPF. In my setup, it works. Core together Sgi works. (not clean).
Merging Core and SGi will allow access to your core network from the UE. This is most likely not an intended setup.
Anyhow, VPP/UPF does not support merging of the different interfaces. There might unexpected side effects.
yes precedence can solve. Not exactly. I will test and tell you.