> 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

> | Capacity/PAC | Capacity/Full System1 | Minimum # of LAC services Required2
> Tunnels | 32,000 | 32,000 | 1
> Sessions | 40,000 | 500,000 | 1
> Transactions/Second | 4003 | 40004 | N/A
> 1. A full system consists of 13 active PACs.
> 2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
> 3. Transactions include PPP and LAC
> 4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.

> ‌
> L2TP LAC Tunnel and Session Capacity per ASR 5000 for PDSN Simple IP

> | Capacity/PSC | Capacity/Full System1 | Minimum # of LAC services Required2
> Tunnels | 32,000 | 32,000 | 1
> Sessions | 120,000 | 1,500,000 | 1
> Transactions/Second | 8003 | 10,0004 | N/A
> 1. A full system consists of 13 active PSCs.
> 2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
> 3. Transactions include PPP and LAC
> 4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.

> ‌
> 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

> | Capacity/PAC | Capacity/Full System1 | Minimum # of LAC services Required2
> Tunnels | 32,000 | 32,000 | 1
> Sessions | 25,000 | 300,000 | 1
> Transactions/Second | 2503 | 30004 | N/A
> 1. A full system consists of 13 active PACs.
> 2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
> 3. Transactions include PPP and LAC
> 4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.

> ‌
> L2TP LAC Tunnel and Session Capacity per ASR 5000 for HA

> | Capacity/PSC | Capacity/Full System1 | Minimum # of LAC services Required2
> Tunnels | 32,000 | 32,000 | 1
> Sessions | 83,000 | 1,000,000 | 1
> Transactions/Second | 5003 | 6,0004 | N/A
> 1. A full system consists of 13 active PSCs.
> 2. Multiple LAC services can be configured to reduce the amount of traffic over a single interface.
> 3. Transactions include PPP and LAC
> 4. Transactions include PPP and LAC session setup assuming that a tunnel already exists.

> ‌
> 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.

> Applicable Product(s) | Refer to Sections
> PDSN/FA/HA |
> • | Supported LAC Service Configurations for PDSN Simple IP
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
> • | Configuring LAC Services
> • | Modifying PDSN Services for L2TP Support
> GGSN/SGSN/FA |
> • | Supported LAC Service Configurations for the GGSN
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Configuring LAC Services
> • | Modifying APN Templates to Support L2TP
> ASN GW |
> • | Supported LAC Service Configuration for Mobile IP
> • | Configuring Subscriber Profiles for L2TP Support
> • | RADIUS and Subscriber Profile Attributes Used
> • | Configuring Local Subscriber Profiles for L2TP Support
> • | Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
> • | Configuring LAC Services

> ‌
> 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. | A subscriber session from the PCF is received by the PDSN service over the R-P interface.

> 2. | The PDSN service attempts to authenticate the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> 3. | The RADIUS server returns an Access-Accept message, which includes 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.

> 4. | The PDSN service receives the information and then forwards the packets to the LAC service, configured within the Destination context.

> 5. | The LAC service, upon receiving the packets, encapsulates the information and forwards it to the appropriate PDN interface for delivery to the LNS.

> 6. | The encapsulated packets are sent to the peer LNS through the packet data network where they will be un-encapsulated.

> 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 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> Step 3 | Configure the PDSN service(s) with the tunnel context location according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.

> 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. | A subscriber session from the PCF is received by the PDSN service over the R-P interface.

> 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. | The PDSN forwards all packets for the session to a LAC service configured in the Destination context. If multiple LAC services are configured, session traffic will be routed to each using a round-robin algorithm.

> 4. | The LAC service initiates an L2TP tunnel to one of the LNS peers listed as part of its configuration.

> 5. | Session packets are passed to the LNS over a packet data network for authentication.

> 6. | The LNS authenticates the session and returns an Access-Accept to the PDSN.

> 7. | The PDSN service initiates accounting for the session using a constructed NAI.

> 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 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> 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. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> 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. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 2. | The GGSN passes data received from the MS to a LAC service.

> 3. | The LAC service encapsulates the IP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 4. | The LNS un-encapsulates the packets and processes them as needed. The processing includes IP address allocation.

> 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. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> 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. | The GGSN service authenticates the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> 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. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 5. | The GGSN passes data received from the MS to a LAC service.

> 6. | The LAC service encapsulates the IP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 7. | The LNS un-encapsulates the packets and processes them as needed.The processing includes authentication and IP address allocation.

> 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. | A Create PDP Context Request message for a subscriber session is sent from the SGSN to the GGSN service over the Gn interface. The message contains information such as the PDP Type, APN, and charging characteristics.

> 2. | The GGSN determines whether or not it is configured with an APN identical to the one specified in the message. If so, it determines how to process the session based on the configuration of the APN.

> 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. | The GGSN returns an affirmative Create PDP Context Response to the SGSN over the Gn interface.

> 4. | The GGSN passes the PPP packets received from the MS to a LAC service.

> 5. | The LAC service encapsulates the PPP packets and forwards it to the appropriate Gi interface for delivery to the LNS.

> 6. | The LNS un-encapsulates the packets and processes them as needed. The processing includes PPP termination, authentication (using the username/password provided by the subscriber), and IP address allocation.

> 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 | Configure the APN template to support L2TP tunneling according to the information and instructions located in the Modifying APN Templates to Support L2TP section of this chapter.

> 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 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> 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. | A subscriber session from the FA is received by the HA service over the Pi interface.

> 2. | The HA service attempts to authenticate the subscriber. The subscriber could be configured either locally or remotely on a RADIUS server. Figure above shows subscriber authentication using a RADIUS AAA server.

> 3. | The RADIUS server returns an Access-Accept message, which includes 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.

> 4. | The HA service receives the information and then forwards the packets to the LAC service, configured within the Destination context.

> 5. | The LAC service, upon receiving the packets, encapsulates the information and forwards it to the appropriate PDN interface for delivery to the LNS.

> 6. | The encapsulated packets are sent to the peer LNS through the packet data network where they will be un-encapsulated.

> 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 | Configure one or more LAC services according to the information and instructions located in the Configuring LAC Services section of this chapter.

> 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:

> • | RADIUS and Subscriber Profile Attributes Used

> • | Configuring Local Subscriber Profiles for L2TP Support

> • | Configuring Local Subscriber

> • | Verifying the L2TP Configuration

> 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

> RADIUS Attribute | Local Subscriber Attribute | Description | Variable
> Tunnel-Type | tunnel l2tp | Specifies the type of tunnel to be used for the subscriber session | L2TP
> Tunnel-Server-Endpoint | tunnel l2tp peer-address | Specifies the IP address of the peer LNS to connect tunnel to. | IPv4 address in dotted-decimal format, enclosed in quotation marks
> Tunnel-Password | tunnel l2tp secret | Specifies the shared secret between the LAC and LNS. | Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
> Tunnel-Private- Group-ID | tunnel l2tp tunnel-context | Specifies the name of the destination context configured on the system in which the LAC service(s) to be used are located. 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. | Alpha and or numeric string from 1 to 63 characters, enclosed in quotation marks
> Tunnel-Preference | tunnel l2tp preference | Configures the priority of each peer LNS when multiple LNS nodes are configured. Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized. | Integer from 1 to 65535
> SN-Tunnel-Load- Balancing | loadbalance-tunnel- peer | A vendor-specific attribute (VSA) used to provides a selection algorithm defining how an LNS node is selected by the RADIUS server when multiple LNS peers are configured within the subscriber profile. |
> • | 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.
> Client-Endpoint | local-address | Specifies the IP address of a specific LAC service configured on the system that to use to facilitate the subscriber’s L2TP session. This attribute is used when multiple LAC services are configured. | IPv4 address in dotted decimal notation. (xxx.xxx.xxx.xxx)

> ‌
> 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 | Configure the “Local” subscriber with L2TP tunnel parameters and the load balancing parameters with action by applying the example configuration in the Configuring Local Subscriber section.

> 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 | Verify that your L2TP configurations were configured properly by entering the following command in Exec Mode in specific context:

> 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 | Configure the LAC service on system and bind it to an IP address by applying the example configuration in the Configuring LAC Service section.

> 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 | Verify your LAC configuration by following the steps in the Verifying the LAC Service Configuration section.

> 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 | Verify that your LAC service configurations were configured properly by entering the following command in Exec Mode in specific context:

> 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 | Modify the PDSN service to support L2TP by associating LAC context and defining tunnel type by applying the example configuration in the Modifying PDSN Service section.

> Step 2 | Verify your configuration to modify PDSN service by following the steps in the Verifying the PDSN Service for L2TP Support section.

> 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 | Verify that your PDSN is configured properly by entering the following command in Exec Mode in specific context:

> 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 | Modify the APN template to support L2TP with LNS server address and other parameters by applying the example configuration in the Assigning LNS Peer Address in APN Template section.

> Step 2 | Optional. If L2TP will be used to tunnel transparent IP PDP contexts, configure the APN’s outbound username and password by applying the example configuration in the Configuring Outbound Authentication section.

> 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 | Verify that your APN configurations were configured properly by entering the following command in Exec Mode in specific context:

> 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