No retry of PFCP association to UPF after first failed try

[mgumz]

Description

In a GTP-Proxy setup with real DNS based node selection it was observed, that after selecting a configured upf the PFCP association (or more specific) the "FAR installation procedure" did not succeed.

ergw was configured potentially have cp, epc1, epc2, access1 and access2 as NWIs while the selected *upf was configured to support cp, epc1, epc2and access1. access2 was not supported.

The installation of the FARs after the successfull PFCP association request failed (because upf did not support a NWI required by ergw).

After reconfiguring the upf, restarting it: ergw would not trigger a single PFCP association request to the upf

Side question: ergw wants to install FARs for all available NWIs in the node section. At the same time, the socket-configuration for a access-side socket states it will use only one specific NWI. This is by design? Because ergw can't know upon PFCP establishment which of the NWIs will be used later on?

Relevant configurations

ergw

{ergw, [
    {sockets, [
      {'grx-0', [
        {type, 'gtp-c'},
        {vrf, access1},
        {ip, {192,168,0,1}}
    ]},

    {nodes,
      [{default,
        [{vrfs,
          [{cp, [{features, ['CP-Function']}]},
           {access1, [{features, ['Access']}]},
           {access2, [{features, ['Access']}]},
           {epc1, [{features, ['Core']}]},
           {epc2, [{features, ['Core']}]}
         ]}]

upf

upf nwi name access1 vrf 2
upf gtpu endpoint ip 192.168.0.2 nwi access1 teid 0x80000000/2

upf nwi name epc1 vrf 3
upf gtpu endpoint ip 127.0.0.3 nwi epc1 teid 0x80000000/2

upf nwi name epc2 vrf 4
upf gtpu endpoint ip 127.0.0.4 nwi epc2 teid 0x80000000/2

Versions:

• travelping/ergw:2.4.3
• travelping/vpp:v20.09-upfbase2

[RoadRunnr]

Configuring VRFs on the default node that are not supported by all UPF instance is a broken config. The node config does indeed configure full nodes only and the configuration has to match what the nodes support. The name default is only that, a name.

We could add a template that is then applied to newly discovered nodes. Su a template would then be instantiated with only the VRFs/NWIs that are supported by a UPG.

[mgumz]

@RoadRunnr "After reconfiguring the upf, restarting it: ergw would not trigger a single PFCP association request to the upf" … was the actual question. since ergw:2.8.x was active back then and now ergw:3.1.x is current: is the behaviour of ergw such that after a upg-node was tried to associated with, then failed in the case of vrf-mismatch – is ergw:3.1.x reconsidering the upg-instance after $time on its own?

[RoadRunnr]

It is important to note that the failed session setup was for the CP-to-UP forwarding session and rules that is installed by the ergw_sx_node.
This means that initial attachment of the UPF will fail in the sx node process and that process could then get stuck or otherwise misbehave.