L2TP Subscriber Management
Feature Summary and Revision History
- Summary Data
- Revision History
Feature Description
- L2TP Overview
  - L2TP Features
- How it Works
Configuring the L2TP Subscriber Management Feature
- Creating the L2TP Profile

L2TP Subscriber Management

Feature Summary and Revision History

Summary Data

Table 1. Summary Data
Applicable Product(s) or Functional Area	cnBNG
Applicable Platform(s)	SMI
Feature Default Setting	Disabled - Configuration Required
Related Changes in this Release	Not Applicable
Related Documentation	Not Applicable

Revision History

Table 2. Revision History
Revision Details	Release
First introduced.	2021.04.0

Feature Description

Note

This feature is Network Services Orchestrator (NSO) integrated.

Majority of the digital subscriber line (DSL) broadband deployments use PPPoE sessions to provide Subscriber services. These sessions terminate the PPP link and provide all the features, service, and billing on the same node. These sessions are called PPP Terminated (PTA) sessions .

There are some wireline subscriber deployments are in wholesale-retail model where some ISPs work with others to provide the access and core services separately. In such cases, the subscribers are tunneled between wholesale and retail ISPs using the Layer 2 Tunneling Protocol (L2TP) protocol.

L2TP Overview

In cnBNG, the L2TP performs the hand-off task of the subscriber traffic to the Internet service provider (ISP). To do this, L2TP uses two network components:

L2TP Access Concentrator (LAC)—The L2TP enables subscribers to dial into the L2TP access concentrator (LAC), which extends the PPP session to the LNS. cnBNG provides LAC.
L2TP Network Server—The L2TP extends PPP sessions over an arbitary netowrk to a remote network server that is, the L2TP network server (LNS). The ISP provides LNS.

The overall network deployment architecture is also known as Virtual Private Dial up Network (VPDN). The overall topology of LAC and LNS is depicted as follows:

The CP for LAC and LNS depend on the L2TP session termination. Developing these two control planes in a single cnBNG microservice has the following benefits:

Simplified Single L2TP Control Plane

Reduces the configuration complexity of the current XR L2TP

vpdn-groups, vpdn-templates, l2tp-class and so on are simplified.
Supports LC subscriber (not supported on the physical BNG)
Avoids Ns/Nr checkpointing issues of pBNG to support RPFO

Collocated LAC and LNS

Supports LAC and LNS in the same cnBNG CP, with different User Plane (UPs)
Enables sharing of the same AAA and Policy Plane
Simplifies management and troubleshooting

Flexible Deployment Options

The integration of LAC and LNS into a centralized cnBNG CP provides highly flexible deployments options to suit different customer use-cases and needs. For example, the cnBNG CP can host the CP functionality either for a LAC or LNS UP. Also, the same CP cluster can act as a CP for both LAC and LNS UPs from different data centers (or even from the same user-plane, if the user-plane supports it) except for the same session at the same time.

L2TP Features

The cnBNG supports the following Layer 2 Tunneling Protocol (L2TP) features:

Tunnel authentication
L2TP congestion control
AVP encryption
Tunnel Hello interval
IP ToS value for tunneled traffic
IPv4 don't fragment bit
DSL line information attributes
IPv4 tunnel source address
IPv4 tunnel destination address
IPv4 destination load balancing
Tunnel mode
MTU for LCP negotiation
TCP maximum support
Start-Control-Connection-Request (SCCRQ) timeout
SCCRQ retries
Control packet retransmission
Control packet retransmission retries
Receive window size for control channel
Rx and Tx connect speed
Tunnel VRF
Tunnel session limit
Weighed and Equal Loadbalancing
Tunnel password for authentication
Domain name and tunnel assignment
LCP and Authentication renegotiation
LAC hostnames for tunnelling requests

How it Works

This section provides a brief of how the L2TP Subscriber Management feature works.

L2TP Handling

Both LAC and LNS sessions use L2TP protocol for negotiation and creation of L2TP sessions. However for LAC sessions, there is additional PPPoE handling. This section focuses on the L2TP protocol handling.

LAC Sessions

For LAC sessions, the PPP sessions are terminated on a different network node from where the PPPoE sessions are terminated. The PPPoE sessions are terminated on the LAC, but the PPP session is terminated on an LNS upstream, over an L2TP tunnel. Initial PPP negotiations are done on the LAC to determine the appropriate LNS to tunnel the session. When the tunnel has been established, all PPP handling is handed off to the LNS.

The PPPoE protocol is negotiated in the same way as a PTA session.
PPPoE service handles all PPPoE packets and the nitial LCP and authorization packets.
After authentication , if the user-profile contains service=outbound, PPPoE service decides to tunnel the sessions.
It reaches out the L2TP pod to initiate a L2TP tunnel . The L2TP tunnel pod creates the tunnel and returns the L2TP session ID.
The PPPoE service continues to handle the L2TP session FSM and bring-up the LAC session and program the UP via the Subscriber Manager.

LNS Sessions

LNS sessions are similar to PTA sessions in the overall functionality. Instead of PPPoE protocol, here the First-Sign-Of-Life (FSOL) packets are the L2TP Incoming-Call-Request (ICRQ) messages. When the L2TP session protocol is up, then the existing PPP protocol finite state machines (FSM) is triggered to bring up and program the session on the UP.

L2TP Tunnel pod receives tunnel-create request from the remote LAC.
After Tunnel is up, PPPoE Pod receives ICRQ to create a session.
PPPoE pod communicates with the L2TP to get L2TP session-id for the given tunnel ID.
L2TP generates the session ID and checks the session count.
PPPoE pod checks if there is forced renegotiation configured for the session. Else, it proceeds with the session programming to the UP.

AAA Attributes for L2TP

The following is the list of AAA attributes for L2TP LAC and LNS sessions.

IETF Attribute: AAA_TUNNEL_PASSWORD (69)

Tunnel-Password=<16byte-encrypted-value>

The value of this attribute is defined as an "encrypted-string". RADIUS decrypts the value and sends a plain-text password to the Subscriber Manager (SM).

For more L2TP IETF Attributes, see IETF Tagged Attributes on LAC.

CISCO-VSA: AAA_AT_L2TP_TUNNEL_PASSWORD

Cisco-AVPair += "l2tp-tunnel-password=<plain-text>"

The value of this attribute is defined in "plain-text". RADIUS passes the value to SM in the respective Access-accept request.

If required, the RADIUS server can this as an "encrypted-cisco-visa(36)", which is similar to the Layer1 vendor-specific attributes (VSAs).

In that case, RADIUS-Ep decrypts the complete VSA and sends the plain-text value.

For more L2TP VSA attributes, see RADIUS Vendor-Specific Attributes.

Call Flows

This section includes the following high-level call flows.

LAC Session Bringup Call Flow

The LAC Session Bringup call flow is as follows.

Table 3. LAC Session Bringup Call Flow Description

Steps

Description

On learning the first control packet, the BNG-CP sends a Session Creation request to create a new packet forwarding state for the data packet. This updates the BNG-UP state.

Note

At this step, it is possible to create a session from the redirected control packet. By doing so, resources are consumed on the BNG-UP to allow individual subscriber control packet management such as blocking, rate limiting, and specific packet filtering. It is also possible to postpone the session creation. By doing so, additional resources BNG-UP are not consumed, but individual subscriber control packet management is not possible.

The BNG-UP sends the following response to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) is ready to forward the subscriber PPP control packets.

The BNG-CP sends the PADO message back to the CPE through the BNG-UP using the control packet redirect interface.

The PADR message is sent from the CPE through the BNG-UP using the control packet redirect interface.

The BNG-CP sends the PADS message back to the CPE through the BNG-UP using the control packet redirect interface.

The LCP configuration request is sent from the CPE through the BNG-UP using the control packet redirect interface.

The BNG-CP sends the LCP configuration acknowledgement back to the CPE through the BNG-UP using the control packet redirect interface. The LCP configuration acknowledgement indicates either a PAP or CHAP authentication challenge.

Options:

Option 1: If the client chooses PAP, the CPE sends a PAP request to the BNG-CP through the BNG-UP using the control packet redirect interface. The PAP password is sent as an Access request to the AAA server.
Option 2: If CHAP is required, the BNG-CP initiates a challenge to the CPE though the BNG-UP using the control packet redirect interface. The CPE responds back to the challenge to the BNG-CP. The challenge is sent to the AAA server.

The AAA successfully authenticates the CPE and replies to the CPE with a PAP/CHAP success and that this is a L2TP session.

Note

If the RADIUS profile received in AAA Accept-Ack has the field “service-type” with the value as “outbound-user”, this means that the session must be tunneled to the LNS IP address (either specified in the same profile or available in the Control Plane configuration).

The BNG-CP sends a Session Establishment message to the BNG-UP. The BNG-CP programs the NBG-UP control packet redirect rules to do the following:

Decapsulate and send the L2TP control message towards the LNS.
Redirect L2TP control message back to the BNG-CP. This session establishment is only on a per-tunnel basis.

The BNG-UP sends the following response to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) is ready to forward the L2TP control packets.

The BNG-CP sends Start-Control-Connection-Request (SCCRQ), Start-Control-Connection-Reply (SCCRP), Start-Control-Connection-Connected (SCCCN), and Zero-Length Body (ZLB) to the LNS via the BNG-UP through the control packet redirect interface.

The BNG-CP sends Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming-Call-Connected (ICCN), and ZLB to the LNS via the BNG-UP through the control packet redirect interface.

The BNG-CP sends a Session Modify request if there is a previous session established to allow for data packet forwarding to the LNS (and control packet if not done already). If a previous session was not established, this is a Session Request message to allow for data packet forwarding to the LNS. This updates the User Plane state.

Note

Subscriber session creation can be performed at any steps prior to this. This step is the last chance for a session creation to avoid subscriber data packets drops. Immediately after this step, the CPE is assigned an address and data packets would be sent immediately.

The BNG-UP sends the following response to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) is ready to forward subscribers PPP control and data packets.

If the LNS has cached the LCP configuration and there is no negotiation disagreement, this step can be skipped. If LNS has not cached the LCP configuration or the session requires renegotiation, then the LCP negotiation takes place.

If the LNS has cached the authentication information and there is no disagreement on authentication, this step can be skipped. If LCP has not cached the authentication information or authentication has failed, then reauthorization occurs.

The IP Control Protocol (IPCP) takes place between the CPE and the LNS through the BNG-UP.

The PPP LCP echo hello are exchanged between the CPE and the LNS through the BNG-UP.

LAC Session Bringdown Call Flow

The LAC Session Bringdown call flow is as follows.

Table 4. LAC Session Bringdown Call Flow Description
Steps	Description
1	The L2TP (LAC) session and tunnel bringdown can occur due to various reasons. For example, CPE can send PADT to gracefully bringdown the subscriber session. This triggers the L2TP session cleanup between LAC and LNS.
2	If it is the last session in the L2TP tunnel, the tunnel is also deleted and the PPPoE session is cleaned up in the LAC. The session or tunnel bringdown occurs in the following scenarios: PPP keepalive failure between CPE and LNS. Tunnel keepalive failure. In this case, all sessions in the tunnel are removed first. Admin clear on either LAC or LNS.

LNS Session Bringup Call Flow

The LNS Session Bringup call flow is as follows.

Table 5. LNS Session Bringup Call Flow Description

Steps

Description

The Start Control Connection Request (SCCRQ) message is received through the control packet redirect interface following the common packet redirect rule.

The BNG-CP sends a Session Establishment request message to the BNG-UP. The BNG-CP programs the DBNG-UP control packet redirect rules to send L2TP control message towards the BNG-CP to only accept particular tunnels.

The BNG-UP sends the following response back to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) is ready to forward the L2TP control packets.

The BNG-CP exchanges Start Control Connection Reply (SCCRP), Start Control Connection Connected (SCCCN), and Zero Length Body (ZLB) with the LAC using the control packet redirect interface.

The BNG-CP receives the Incoming Call Request (ICRQ) message (includes AVP defined in RFC 5515).

After receiving the ICRQ message, the BNG-CP has the L2TP session ID information. The BNG-CP can send a Session Establishment request to the BNG-UP to ensure only known L2TP sessions are accepted.

Note

At this step, it is possible to create a session from the redirected control packet. By doing so, resources are consumed on the DBNG-UP in order to allow individual subscriber control packet management such as blocking, rate limiting, and specific packet filtering. It is also possible to postpone the session creation. By doing so, additional resources DBNG-UP are not consumed, but individual subscriber control packet management is not possible

The BNG-UP sends the following response back to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) only accepts L2TP control packet from known sessions.

The BNG-CP exchanges ICRP, ICCN, and ZLB with the LAC using the control packet redirect interface.

If the LNS has cached the LCP configuration and there is no negotiation disagreement, this step can be skipped. If the LCP has not cached the LCP configuration or the session requires renegotiation, then the LCP negotiation takes place.

After authentication, the BNG-CP knows the IP address or prefix (or both) for the subscriber either though the local address server or from the AAA returned VSAs. The BNG-CP sends a Session Modify request if there is already an established session to update the User Plane (UP) state. If there are no prior sessions, this requires a Session Establishment request to update the UP.

Note

The BNG-UP sends the following response back to the BNG-CP:

Informs that the states are installed.
Informs that it (BNG-UP) is ready to forward subscribers PPP control and data packets.

The IPCP takes place between the CPE and the LNS through the BNG-UP.

The PPP LCP echo hello are exchanged between the CPE and the LNS through the BNG-UP.

¹ At this step, it is possible to create a session from the redirected control packet. By doing so, resources are consumed on the BNG-UP to allow individual subscriber control packet management such as blocking, rate limiting, and specific packet filtering. It is also possible to postpone the session creation. By doing so, additional resources BNG-UP are not consumed, but individual subscriber control packet management is not possible.

LNS Session Bringdown Call Flow

The LNS Session Bringdown call flow is as follows.

Table 6. LNS Session Bringdown Call Flow Description
Steps	Description
1	LAC sends a Call-Disconnect-Notify (CDN) message to release the session on the LNS.
2	cnBNG CP deletes the session on UP. It releases all the resources and collects the final statistics from the UP and sends the Accounting-Stop message.
	cnBNG CP sends ZLB as ackndoledgement.
	If it is the last sesion on the tunnel, cnBNG CP sends a Stop-Control-Connection-Notification (Stop-CCN) message to bring down the tunnel.

Standard Compliance

The L2TP Subscriber Management feature is aligned with the following standard:

RFC 2661: Layer Two Tunneling Protocol "L2TP"

Limitations

The LT2P Subscriber Management feature has the following limitations:

LAC and LNS Control Plane (CP) functionality is not supported on the same cluster at the same time.
On-the-fly changes to L2TP profile is not supported.
L2TP attributes should be configured only for session-activate event.
Tunnel load balancing with Tunnel-Assignment-ID is not supported.
Weighted Tunnel load balancing can be configured only in the profile.
The TCP maximum segment size (TCP-MSS) is supported at the global User Plane Function (UPF) chassis level and not at the tunnel or session level. It must be configured on the ASR 9000 UPF.

Configuring the L2TP Subscriber Management Feature

This section describes how to configure the L2TP Subscriber Management feature.

Configuring the L2TP Subscriber Management feature involves the following step:

Creating the L2TP profile

Creating the L2TP Profile

Use the following commands to create the Layer2 Tunnelling Protocol (L2TP) profile and provide the L2TP specific parameters.


config 
   profile l2tp l2tp_profile_name 
      authentication 
      congestion-control 
      encrypt-avp 
      hello-interval interval_in_seconds 
      hostanme local_hostname 
      ip-tos { ip_tos_value | reflect } 
      ipv4 { df-bit { reflect | set } | source ip_address } 
      mode lac 
         domain domain_name [ tun-assign-id tunnel_id ] 
         dsl-info-forwarding  
         ipv4 { destination ip_address | df-bit { reflect | set } |  
              source ip_address } 
         rx-connect-speed kbps  
         tunnel-load-balancing { equal | weighted }  
         tx-connect-speed kbps  
      mode lns 
         force-lcp-renegotiation 
         mtu mtu_value  
         terminate-from remote_hostname 
      password password 
      receive-window number_of_packets 
      retransmit { retries number_of_retries |  
      timeout { max max_timeout | min min_timeout } 
      tcp adjust-mss mss_value 
      tunnel { session-limit number_of_sessions |  
      timeout { no-session | timeout_value } 
      vrf vrf_name 
      exit

NOTES:

profile l2tp l2tp_profile_name : Specifies the PPPoE profile name and enters the Profile L2TP mode.
authentication : Enables L2TP tunnel authentication.
congestion-control :Enables L2TP congestion control.
encrypt-avp : Hides attribute-value pair (AVPs) in outgoing control messages.
hello-interval interval_in_seconds : Sets the hello interval in seconds. The valid values range from 10 to 1000 seconds.
hostname local_hostname : Specifies the local hostname of the tunnel. The valid value is an alphanumeric string ranging from 1 to 256. The name of the Control Plane (CP) is the default local hostname.
ip-tos { ip_tos_value | reflect } : Sets the IP Type of Service (ToS) value for tunneled traffic. The ToS valid values range from 1 to 255. The control packets use 0xC0 as the default value.
ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } : Specifies the IPv4 settings for the tunnel:
- df-bit { reflect | set } : Specifies the IPv4 Don't Fragment (DF) bit.
  
  reflect : Reflects the DF bit from the specified inner IP address.
  
  set : Sets the DF bit.
- source ip_address : Specifies the source IP address of the tunnel.
mode { lac | lns } : Configures LAC or LNS.
- mode lac { domain domain_name [ tun-assign-id tunnel_id ] | dsl-info-forwarding | ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } | rx-connect-speed kbps | tunnel-load-balancing { equal | weighted } | tx-connect-speed kbps : Configures a L2TP Access Concentrator (LAC) to request the establishment of an L2TP tunnel to an L2TP Network Server (LNS).
  - domain domain_name [ tun-assign-id tunnel_id ] : Specifies the domain name to match. The valid values range from 1 to 255. The control packets use 0xC0 as the default value.
    tun-assign-id tunnel_id : Specifies the domain name with a tunnel ID.
  - dsl-info-forwarding : Forwards DSL line information attributes.
  - ipv4 { destination ip_address | df-bit { reflect | set } | source ip_address } : Specifies the IPv4 settings for the tunnel:
    - destination ip_address: Specifies the destination IP address of the tunnel.
    - df-bit { reflect | set } : Specifies the IPv4 Don't Fragment (DF) bit.
      
      reflect : Reflects the DF bit from the specified inner IP address.
      
      set : Sets the DF bit.
    - source ip_address: Specifies the source IP address of the tunnel.
  - rx-connect-speed kbps : Specifies the receiving (Rx) connection speed in kbps. The valid values range from 9 to 100000000 kbps.
  - tunnel-load-balancing { equal | weighted } : Specifies equal or weighted load sharing of the tunnel.
  - tx-connect-speed kbps : Specifies the transmitting (Tx) connection speed in kbps. The valid values range from 9 to 100000000 kbps.
- mode lns { force-lcp-renegotiation | mtu | terminate-from remote_hostname : Configures a LNS to accept requests from LAC to establish L2TP tunnel:
  - force-lcp-renegotiation : Forces Link Control Protocol (LCP) and Authorisation renegotiation.
    mtu mtu_value : Specifies the MTU for LCP negotiation. The mtu_value valid values range from 500 to 2000. The default value is 1492.
  - terminate-from remote_hostname : Specifies the hostname of the remote peer to accept tunnels.
password password : Specifies the password for tunnel authentication.
receive-window number_of_packets : Specifies the receive window size for the tunnel. The valid values range from 1 to 5000 packets. The default value is 4.
retransmit { retries number_of_retries | timeout { max max_timeout | min min_timeout } : Specifies the control message retransmission parameters.
- retries number_of_retries : Specifies the maximum number of retries for control packets.
- timeout { max max_timeout | min min_timeout } : Specifies the control packet retransmission timeout parameters.
  
  max max_timeout : Specifies the control packet retransmission maximum timeout parameters. The valid values range from 1 to 8 seconds. The default value is 8.
  
  min min_timeout : Specifies the control packet retransmission minimum timeout parameters. The valid values range from 1 to 8 seconds. The default value is 1.
tcp adjust-mss mss_value : Adjusts the TCP Maximum Segment Size (MSS) value of TCP SYN (synchronize) packets. The valid values range from 500 to 1500 packets.
tunnel { session-limit number_of_sessions | timeout { no-session | timeout_value } : Limits the sessions for a tunnel or deletes the tunnel after timeout
- session-limit number_of_sessions : Specifies the maximum number of L2TP sessions per tunnel. The valid values range from 1 to 64000 sessions.
- timeout { no-session | timeout_value } : Specifies the following parameters :
  
  timeout no-session : No-session timeout for the tunnel. The default value is 0 seconds.
  
  timeout timeout_value : Timeout value in seconds. The valid values range from 1 to 86400 seconds.
vrf vrf_name : Specifies the Virtual routing and forwarding (VRF) name of the tunnel.

Cloud Native BNG Control Plane Configuration Guide, Release 2024.03.0

Bias-Free Language

Book Title

Cloud Native BNG Control Plane Configuration Guide, Release 2024.03.0

Chapter Title