ULCL Malfunction

[romoreira]

Dear @andy89923 and @abousselmi,

Thank you for your support. I am attaching the traces here. Could you clarify if this is the expected behavior of ULCL?

• I branched to the correct release (the one with ULCL support).

• Following are the IPs of core entities and UE:

  • UE: 10.100.200.15 (10.60.0.1)
  • i-UPF: 10.100.200.2
  • PSA-UPF: 10.100.200.3

• The uerouting.yaml is as per the file available on the Git repository:

  specificPath:
      - dest: 1.0.0.1/32
        path: [I-UPF]

Test: I performed the following:

• Pinged destination 8.8.8.8 for a given time.

• Pinged destination 1.0.0.1 for another period.

• Observation: For all destinations, the traffic is being forwarded to the DN through PSA-UPF.

• Question: What should I expect? I assumed that the destination 1.0.0.1 would be forwarded to the DN through i-UPF. Is this correct?

[andy89923]

@lyz508 Please help this out! Thanks~

[andy89923]

Hi @romoreira ,

The screenshot you provided shows that the packet will go through I-UPF (10.100.200.2) -> PSA-UPF(10.100.200.3)

[romoreira]

@andy89923 thanks for your response. My question is: when the destination was 1.0.0.1 the packet should be forwarded to the DN thought I-UPF? but this does not happen.

Which test or scenario do you suggest to me to see the ULCL working clearly?

[romoreira]

@andy89923 @abousselmi; and my last question, I promise.

• Is it possible to make i-UPF a branching point, I mean, to enable i-UPF forward traffic to two different UPFs (PSA1-UPF or PSA2-UPF) depending on the uerouting.yaml configurations?
• ULCL enables us to do this?
• There are any group for technical discussion for free5gc, such as Discord?

[andy89923]

Hi, for the quick answer,
We discovered that the behavior is not correct.
We will fix this ASAP.