Layer 2 Tunneling Protocol

The BNG CUPS environment supports L2TP functionality.

UPF-triggered L2TP access concentrator

The BNG CUPS UPF supports PPPoE LAC sessions with L2TP control plane signaling running on the BNG CUPS UPF. This relies on the SR L2TP functionality described in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, section Layer 2 Tunneling Protocol (L2TP).

Figure 1. L2TP LAC network components

To run a PPPoE LAC session with L2TP control plane signaling on the BNG UPF, the BNG CPF provides the following parameters during the PFCP session data plane setup:

  • list of potential L2TP Network Server (LNS) tunnel endpoints

  • common or per-LNS parameters such as retry timers, preferences, and authorization IDs; see the CMG BNG CUPS Control Plane Function Guide for more information about how to configure these parameters

  • per-session PPP LCP and PPP authentication attributes to be sent by proxy to the chosen LNS, so the LNS can avoid renegotiating LCP and authentication with the PPPoE session

  • unique name to identify the tunnel group over shared sessions

The BNG UPF performs normal L2TP tunnel management over the group of tunnels, including deny list management, as described in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, section Traffic Steering on L2TP LAC. To accomplish this, the BNG UPF creates an internal L2TP group in the VPRN service or base router provided by the PFCP. This internal group is not configurable, but common parameters configured under configure router l2tp or configure vprn service-name l2tp are applied to the setup of the tunnels. If a parameter is configured locally and also in PFCP, the PFCP parameter takes precedence. To set up tunnels, the l2tp context must also be administratively enabled in the router or VPRN.

Based on the tunnel management, the BNG UPF selects a tunnel for the session, or creates the tunnel if it does not exist, and an L2TP session is created for that specific PPPoE session. After the tunnel and session setup are complete, a response including the following parameters is sent to the triggering PFCP message for operational management on the BNG CPF:

  • L2TP tunnel and session IDs of both the LAC and the LNS
  • LNS and LAC hostnames, also known as auth IDs
  • L2TP tunnel and session IDs for both LNS and LAC
  • Call Serial Number (CSN)

After the connection is established, the PPP data packets are forwarded to the LNS. The PFCP message instructs the BNG UPF to stop sending PPP control plane messages to the BNG CPF, and to send them to the LNS instead. Only the PPPoE discovery packets are forwarded to the BNG CPF. For example, a PADT packet is handled by the BNG CPF, while an LCP terminate packet is handled by the LNS.

If L2TP session or tunnel setup fails, the normal L2TP backoff and deny list behavior applies. If the setup fails for all provided tunnels, an explicit PFCP error message is sent to the BNG CPF. However, the BNG UPF does not time out the PFCP message if the setup takes too long, for example, because multiple LNSs are unreachable. The BNG triggers an explicit delete after the PFCP message times out, using its local PFCP N1 or T1 configuration. If a delete is received for an in-progress setup, the setup is aborted.

Note: An aborted setup does not count as a tunnel timeout and the tunnel is not placed in automatic deny lists for timeout hold-off purposes. You must configure the max-retries-not-estab command to ensure that the total timeout does not exceed the PFCP session timeout on the BNG CPF. See the CMG BNG CUPS Control Plane Function Guide for more information about how to correctly align the timeouts.