L2TP Access Concentrator


L2TP Access Concentrator
 
 
This chapter describes the Layer 2 Tunneling Protocol (L2TP) Access Concentrator (LAC) functionality support on ST16 and Cisco® ASR 5000 Chassis and explains how it is configured.
The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
Important: This product requires the purchase of a separate session licence and feature key in order to function as described.
When enabled though the session license and feature use key, the system supports L2TP for encapsulation of data packets between it and one or more L2TP Network Server (LNS) nodes. In the system, this optional packet encapsulation, or tunneling, is performed by configuring L2TP Access Concentrator (LAC) services within contexts.
Important: The LAC service uses UDP ports 13660 through 13668 as the source port for sending packets to the LNS.
 
L2TP Session and Tunnel Capacities
The system is capable of supporting L2TP tunnels for all subscriber sessions or on a session-by-session basis.
Each L2TP tunnel can facilitate one or more subscriber sessions. The number of supported L2TP sessions and tunnels corresponds to the number of active Packet Accelerator Cards (PACs) or Packet Services Cards (PSCs)
The following tables lists PDSN Simple IP tunnel and session capacities for the ST16 and ASR 5000 respectively.
Important: The capacities stated in this section are the maximum supported by the components. Actual capacities are dependent upon hardware and software configurations.
L2TP LAC Tunnel and Session Capacity per ST16 for PDSN Simple IP
L2TP LAC Tunnel and Session Capacity per ASR 5000 for PDSN Simple IP
The following table lists HA tunnel and session capacities for the ST16 and ASR 5000 respectively.
L2TP LAC Tunnel and Session Capacity per ST16 for HA
L2TP LAC Tunnel and Session Capacity per ASR 5000 for HA
 
Applicable Products and Relevant Sections
The LAC feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
 
Supported LAC Service Configurations for PDSN Simple IP
LAC services can be applied to incoming PPP sessions using one of the following methods:
 
Attribute-based tunneling: This method is used to encapsulate PPP packets for only specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
PDSN Service-based compulsory tunneling: This method of tunneling is used to encapsulate all incoming PPP traffic from the R-P interface coming into a PDSN service, and tunnel it to an LNS peer for authentication. It should be noted that this method does not consider subscriber configurations, since all authentication is performed by the peer LNS.
Each LAC service is bound to a single system interface configured within the same system context. It is recommended that this context be a destination context as displayed in the following figure.
 
LAC Service Configuration for SIP
 
Attribute-based Tunneling
This section describes the working of attribute-based tunneling and its configuration.
 
How The Attribute-based L2TP Configuration Works
The following figure and the text that follows describe how Attribute-based tunneling is performed using the system.
 
 
Attribute-based L2TP Session Processing for SIP
 
1.
2.
3.
4.
5.
6.
 
Configuring Attribute-based L2TP Support for PDSN Simple IP
This section provides a list of the steps required to configure attribute-based L2TP support for use with PDSN Simple IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
Step 1
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
Step 2
Step 3
Step 4
Save your configuration as described in Verifying and Saving Your Configuration.
 
PDSN Service-based Compulsory Tunneling
This section describes the working of service-based compulsory tunneling and its configuration.
 
How PDSN Service-based Compulsory Tunneling Works
PDSN Service-based compulsory tunneling enables wireless operators to send all PPP traffic to remote LNS peers over an L2TP tunnel for authentication. This means that no PPP authentication is performed by the system.
 
Accounting start and interim accounting records are still sent to the local RADIUS server configured in the system’s AAA Service configuration. When the L2TP session setup is complete, the system starts its call counters and signals the RADIUS server to begin accounting. The subscriber name for accounting records is based on the NAI-constructed name created for each session.
PDSN service-based compulsory tunneling requires the modification of one or more PDSN services and the configuration of one or more LAC services.
The following figure and the text that follows describe how PDSN service-based compulsory tunneling is performed using the system.
PDSN Service-based Compulsory Tunneling Session Processing
1.
2.
The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.
3.
4.
5.
6.
7.
Session data traffic is passed over the L2TP tunnel established in step 4.
 
Configuring L2TP Compulsory Tunneling Support for PDSN Simple IP
This section provides a list of the steps required to configure L2TP compulsory tunneling support for use with PDSN Simple IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
Step 1
Step 2
Configure the PDSN service(s) according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.
Step 3
Save your configuration as described in Verifying and Saving Your Configuration.
 
Supported LAC Service Configurations for the GGSN
As mentioned previously, L2TP is supported through the configuration of LAC services on the system. Each LAC service is bound to a single system interface configured within the same system destination context as displayed in following figure.
LAC Service Configuration
LAC services are applied to incoming subscriber PDP contexts based on the configuration of attributes either in the GGSN’s Access Point Name (APN) templates or in the subscriber’s profile. Subscriber profiles can be configured locally on the system or remotely on a RADIUS server.
LAC service also supports domain-based L2TP tunneling with LNS. This method is used to create multiple tunnels between LAC and LNS on the basis of values received in “Tunnel-Server-Auth-ID” attribute received from AAA Server in Access-Accept as a key for tunnel selection and creation. When the LAC needs to establish a new L2TP session, it first checks if there is any existing L2TP tunnel with the peer LNS based on the value of key “Tunnel-Server-Auth-ID” attribute. If no such tunnel exists for the key, it will create a new Tunnel with the LNS.
If LAC service needs to establish a new tunnel for new L2TP session with LNS and the tunnel create request fails because maximum tunnel creation limit is reached, LAC will try other LNS addresses received from AAA server in Access-Accept message. If all available peer-LNS are exhausted, LAC service will reject the call
L2TP tunnel parameters are configured within the APN template and are applied to all subscribers accessing the APN. However, L2TP operation will differ depending on the subscriber’s PDP context type as described below:
Transparent IP: The APN template’s L2TP parameter settings will be applied to the session.
Non-transparent IP: Since authentication is required, L2TP parameter attributes in the subscriber profile (if configured) will take precedence over the settings in the APN template.
PPP: The APN template’s L2TP parameter settings will be applied and all of the subscriber’s PPP packets will be forwarded to the specified LNS.
More detailed information is located in the sections that follow.
 
Transparent IP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how transparent IP PDP contexts are processed when L2TP tunneling is enabled.
Transparent IP PDP Context Call Processing with L2TP Tunneling
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s International Mobile Subscriber Identity (IMSI) is used as the username at the peer LNS.
 
1.
2.
3.
4.
 
Non-transparent IP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
 
Non-transparent IP PDP Context Call Processing with L2TP Tunneling
 
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s username is sent to the peer LNS.
3.
As part of the authentication, the RADIUS server returns an Access-Accept message.
The message may include attributes indicating that session data is to be tunneled using L2TP, and the name and location of the LAC service to use. An attribute could also be provided indicating the LNS peer to connect to.
If these attributes are supplied, they take precedence over those specified in the APN template.
4.
5.
6.
7.
 
PPP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
 
PPP PDP Context Call Processing with L2TP Tunneling
 
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured.
Note that L2TP support could also be configured in the subscriber’s profile. If the APN is not configured for L2TP tunneling, the system will attempt to authenticate the subscriber.The tunneling parameters in the subscriber’s profile would then be used to determine the peer LNS.
3.
4.
5.
6.
 
Configuring the GGSN to Support L2TP
This section provides a list of the steps required to configure the GGSN to support L2TP. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a GGSN.
Step 1
Important: L2TP tunneling can be configured within individual subscriber profiles as opposed/or in addition to configuring support with an APN template. Subscriber profile configuration is described in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
Step 2
Step 3
Save your configuration as described in Verifying and Saving Your Configuration chapter.
 
Supported LAC Service Configuration for Mobile IP
LAC services can be applied to incoming MIP sessions using attribute-based tunneling. Attribute-based tunneling is used to encapsulate PPP packets for specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
 
Each LAC service is bound to a single system interface within the same system context. It is recommended that this context be a destination context as displayed in figure below.
LAC Service Configuration for MIP
 
How The Attribute-based L2TP Configuration for MIP Works
The following figure and the text that follows describe how Attribute-based tunneling for MIP is performed using the system.
 
 
Attribute-based L2TP Session Processing for MIP
 
1.
2.
3.
4.
5.
6.
 
Configuring Attribute-based L2TP Support for HA Mobile IP
This section provides a list of the steps required to configure attribute-based L2TP support for use with HA Mobile IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as an HA.
Step 1
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
Step 2
Step 3
Save your configuration as described in Verifying and Saving Your Configuration chapter.
 
Configuring Subscriber Profiles for L2TP Support
This section provides information and instructions on the following procedures:
 
Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
 
RADIUS and Subscriber Profile Attributes Used
Attribute-based L2TP tunneling is supported through the use of attributes configured in subscriber profiles stored either locally on the system or remotely on a RADIUS server. The following table describes the attributes used in support of LAC services. These attributes are contained in the standard and VSA dictionaries.
Subscriber Attributes for L2TP Support
Important: If the LAC service and egress interface are configured in the same context as the core service or HA service, this attribute is not needed.
Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized.
Random - Random LNS selection order, the Tunnel-Preference attribute is not used in determining which LNS to select.
Balanced - LNS selection is sequential balancing the load across all configured LNS nodes, the Tunnel-Preference attribute is not used in determining which LNS to select.
Prioritized - LNS selection is made based on the priority assigned in the Tunnel-Preference attribute.
 
RADIUS Tagging Support
 
The system supports RADIUS attribute tagging for tunnel attributes. These “tags” organize together multiple attributes into different groups when multiple LNS nodes are defined in the user profile. Tagging is useful to ensure that the system groups all the attributes used for a specific server. If attribute tagging is not supported by your specific RADIUS server, the system implicitly organizes the attributes in the order that they are listed in the access accept packet.
 
Configuring Local Subscriber Profiles for L2TP Support
This section provides information and instructions for configuring local subscriber profiles on the system to support L2TP.
Important: The configuration of RADIUS-based subscriber profiles is not discussed in this document. Please refer to the documentation supplied with your RADIUS server for further information.
Important: This section provides the minimum instruction set for configuring local subscriber profile for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide L2TP support to subscribers:
Step 1
Step 2
Verify your L2TP configuration by following the steps in the Verifying the L2TP Configuration section.
Step 3
Save your configuration as described in Verifying and Saving Your Configuration chapter.
 
Configuring Local Subscriber
Use the following example to configure the Local subscriber with L2TP tunnel parameters. Optionally you can configure load balancing between multiple LNS servers:
configure
  context <ctxt_name> [-noconfirm]
     subscriber name <subs_name>
        tunnel l2tp peer-address <lns_ip_address> [ preference <integer> | [ encrypted ] secret <secret_string> | tunnel-context <context_name> | local-address <local_ip_address> }
        load-balancing { random | balanced | prioritized }
        end
Notes:
<ctxt_name> is the system context in which you wish to configure the subscriber profile.
<lns_ip_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
 
Verifying the L2TP Configuration
These instructions are used to verify the L2TP configuration.
Step 1
 
show subscriber configuration username user_name
The output of this command is a concise listing of subscriber parameter settings as configured.
 
Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
As with other services supported by the system, values for subscriber profile attributes not returned as part of a RADIUS Access-Accept message can be obtained using the locally configured profile for the subscriber named default. The subscriber profile for default must be configured in the AAA context (i.e. the context in which AAA functionality is configured).
 
As a time saving feature, L2TP support can be configured for the subscriber named default with no additional configuration for RADIUS-based subscribers. This is especially useful when you have separate source/AAA contexts for specific subscribers.
To configure the profile for the subscriber named default, follow the instructions above for configuring a local subscriber and enter the name default.
 
Configuring LAC Services
 
Important: Not all commands, keywords and functions may be available. Functionality is dependent on platform and license(s).
This section provides information and instructions for configuring LAC services on the system allowing it to communicate with peer LNS nodes.
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Optional. Configure LNS peer information if the Tunnel-Service-Endpoint attribute is not configured in the subscriber profile or PDSN compulsory tunneling is supported by applying the example configuration in the Configuring LNS Peer section.
Step 3
Step 4
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
 
Configuring LAC Service
Use the following example to create the LAC service and bind the service to an IP address:
configure
  context <dst_ctxt_name> [-noconfirm]
     lac-service <service_name>
        bind address <ip_address>
        end
Notes:
<dst_ctxt_name> is the destination context where you want to configure the LAC service.
 
Configuring LNS Peer
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
configure
   context <dst_ctxt_name> [ -noconfirm ]
     lac-service <service_name>
        tunnel selection-key tunnel-server-auth-id
        peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> {[encrypted] isakmp-secret <secret> }] [description <text>] [ preference <integer>]
        load-balancing { random | balanced | prioritized }
        end
Notes:
<dst_ctxt_name> is the destination context where the LAC service is configured.
 
Verifying the LAC Service Configuration
These instructions are used to verify the LAC service configuration.
Step 1
 
show lac-service name service_name
The output given below is a concise listing of LAC service parameter settings as configured.
Service name: vpn1
Context:                       isp1
Bind:                          Done
Local IP Address:              192.168.2.1
First Retransmission Timeout:  1 (secs)
Max Retransmission Timeout:    8 (secs)
Max Retransmissions:           5
Max Sessions:                  500000      Max Tunnels: 32000
Max Sessions Per Tunnel:       512
Data Sequence Numbers:         Enabled   Tunnel Authentication: Enabled
Keep-alive interval:           60         Control receive window: 16
Max Tunnel Challenge Length:   16
Proxy LCP Authentication:      Enabled
Load Balancing:                Random
Service Status:                Started
Newcall Policy:                None
 
Modifying PDSN Services for L2TP Support
PDSN service modification is required for compulsory tunneling and optional for attribute-based tunneling.
 
For attribute-based tunneling, a configuration error could occur such that upon successful authentication, the system determines that the subscriber session requires L2TP but can not determine the name of the context in which the appropriate LAC service is configured from the attributes supplied. As a precautionary, a parameter has been added to the PDSN service configuration options that will dictate the name of the context to use. It is strongly recommended that this parameter be configured.
This section contains instructions for modifying the PDSN service configuration for either compulsory or attribute-based tunneling.
Important: This section provides the minimum instruction set for modifying PDSN service for L2TP support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Step 3
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
 
Modifying PDSN Service
Use the following example to modify the PDSN service to support L2TP by associating LAC context and defining tunnel type:
configure
  context <source_ctxt_name> [ -noconfirm ]
     pdsn-service <pdsn_service_name>
        ppp tunnel-context <lac_context_name>
        ppp tunnel-type { l2tp | none }
        end
Notes:
<source_ctxt_name> is the name of the source context containing the PDSN service, which you want to modify for L2TP support.
<pdsn_service_name> is the name of the pre-configured PDSN service, which you want to modify for L2TP support.
<lac_context_name> is typically the destination context where the LAC service is configured.
 
Verifying the PDSN Service for L2TP Support
These instructions are used to verify the PDSN service configuration.
Step 1
show pdsn-service name pdsn_service_name
The output of this command is a concise listing of PDSN service parameter settings as configured.
 
Modifying APN Templates to Support L2TP
This section provides instructions for adding L2TP support for APN templates configured on the system.
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer LAC Service Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Step 3
Verify your APN configuration by following the steps in the Verifying the APN Configuration section.
Step 4
Save your configuration as described in the Verifying and Saving Your Configuration chapter.
 
Assigning LNS Peer Address in APN Template
Use following example to assign LNS server address with APN template:
configure
  context <dst_ctxt_name> [-noconfirm]
     apn <apn_name>
        tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <integer> ] [ tunnel-context <l2tp_context_name> ] [ local-address <local_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
        end
Notes:
<dst_ctxt_name> is the name of system destination context in which the APN is configured.
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
<lns_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
 
Configuring Outbound Authentication
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
configure
  context <dst_ctxt_name> [ -noconfirm ]
     apn <apn_name>
        outbound { [ encrypted ] password <pwd> | username <name> }
        end
Notes:
<dst_ctxt_name> is the destination context where APN template is is configured.
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
 
Verifying the APN Configuration
These instructions are used to verify the APN configuration.
Step 1
show apn name apn_name
The output is a concise listing of APN parameter settings as configured.
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883