HP VSR1000 User manual

HP VSR1000 Virtual Services Router
Layer 2 - WAN Access
Configuration Guide
Part number: 5998-4656
Software version: VSR1000_HP-CMW710-E0101P01-X64
Document version: 5W100-20130918

Legal and notice information
© Copyright 2013 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

i
Contents
Configuring PPPoE ······················································································································································· 1
Overview············································································································································································1
PPPoE network structure····················································································································································1
PPPoE client········································································································································································2
Configuring a PPPoE client···············································································································································3
Configuring a dialer interface ································································································································3
Configuring a PPPoE session···································································································································4
Resetting a PPPoE session········································································································································4
Displaying and maintaining PPPoE ·································································································································5
PPPoE client configuration examples·······························································································································5
Configuring PPPoE client in permanent mode·······································································································5
Configuring PPPoE client in on-demand mode······································································································6
Configuring PPPoE client in diagnostic mode ·······································································································7
Configuring L2TP·························································································································································· 9
Overview············································································································································································9
Typical L2TP networking ··········································································································································9
L2TP message types and encapsulation structure ······························································································ 10
L2TP tunnel and session ········································································································································ 10
L2TP tunneling modes and tunnel establishment process ·················································································· 10
L2TP features ·························································································································································· 14
Protocols and standards ······································································································································· 15
L2TP configuration task list ············································································································································ 15
Configuring basic L2TP capabilities····························································································································· 16
Configuring an LAC······················································································································································· 17
Configuring an LAC to initiate tunneling requests for a specified user ··························································· 17
Specifying LNS IP addresses································································································································ 18
Configuring transferring AVP data in hidden mode·························································································· 18
Configuring AAA authentication on an LAC······································································································ 18
Configuring an LAC to automatically establish an L2TP tunnel········································································ 19
Configuring an LNS ······················································································································································· 20
Creating a VT interface ········································································································································ 20
Configuring an LNS to accept L2TP tunneling requests from a specified LAC ··············································· 20
Configuring user authentication on an LNS ······································································································· 21
Configuring AAA authentication on an LNS ······································································································ 22
Configuring optional L2TP parameters ························································································································ 22
Configuring L2TP tunnel authentication··············································································································· 22
Setting the Hello interval······································································································································· 23
Enabling session flow control······························································································································· 23
Configuring the DSCP value of L2TP packets····································································································· 24
Configuring the VPN for a tunnel peer ··············································································································· 24
Displaying and maintaining L2TP································································································································· 24
L2TP configuration examples ········································································································································ 25
Configuration example for NAS-initiated L2TP tunnel······················································································· 25
Configuration example for client-initiated L2TP tunnel ······················································································ 27
Configuration example for LAC-auto-initiated L2TP tunnel················································································ 29
Troubleshooting L2TP ····················································································································································· 31
Configuring DDR ························································································································································32
Overview········································································································································································· 32

ii
Configuration task list ···················································································································································· 32
Configuring link layer/network/routing protocols on a dialer interface ································································· 32
Configuring a dial access rule······································································································································ 32
Configuring an interface to place calls for bundle DDR···························································································· 33
Configuring attributes for a dialer interface················································································································ 34
Support and other resources ·····································································································································35
Contacting HP ································································································································································ 35
Subscription service ·············································································································································· 35
Related information························································································································································ 35
Documents······························································································································································ 35
Websites································································································································································· 35
Conventions ···································································································································································· 36
Index ···········································································································································································38

1
Configuring PPPoE
Overview
Point-to-Point Protocol over Ethernet (PPPoE) extends PPP by transporting PPP frames encapsulated in
Ethernet over point-to-point links.
PPPoE specifies the methods for establishing PPPoE sessions and encapsulating PPP frames over Ethernet.
PPPoE requires a point-to-point relationship between peers instead of a point-to-multipoint relationship as
in multi-access environments such as Ethernet. PPPoE provides Internet access for the hosts in an Ethernet
through a remote access device and implement access control and accounting on a per-host basis.
Integrating the low cost of Ethernet and scalability and management functions of PPP, PPPoE gained
popularity in various application environments, such as residential networks.
For more information about PPPoE, see RFC 2516.
PPPoE network structure
PPPoE uses the client/server model. The PPPoE client initiates a connection request to the PPPoE server.
After session negotiation between them is complete, a session is established between them, and the
PPPoE server provides access control and authentication to the PPPoE client.
Depending on the starting point of the PPPoE session, the following network structures are available:
•As shown in Figure 1, the PPPoE session is established between routers (Router A and Router B). All
hosts share one PPPoE session for data transmission without being installed with PPPoE client
software. This network structure is typically used by enterprises.
Figure 1 Network structure 1
Router B
Host A Host B Host C
Modem
PPPoE server
PPPoE clientRouter A
DSLAM
Internet
Client device
Carrier device

2
•As shown in Figure 2, a PPPoE session is established between each host (PPPoE client) and the
carrier router (PPPoE server). The service provider assigns an account to each host for billing and
control. The host must be installed with PPPoE client software.
Figure 2 Network structure 2
PPPoE client
PPPoE is widely used in ADSL environments. Typically, to connect to the Internet through an ADSL network,
a host must be installed with PPPoE client software. The device provides PPPoE client functionality that
eliminates the need to install PPPoE client software on hosts to connect to the Internet. In addition, all hosts
on the same LAN can share one ADSL account.
Figure 3 Network diagram
As shown in Figure 3, hosts in an Ethernet are connected to Router (PPPoE client). Internet access data
from the hosts first reaches Router, where the data is encapsulated by PPPoE. Then, the data goes through
Internet
PPPoE server
Host A
Host B
Router
PPPoE client
PPPoE client

3
the ADSL modem to the ADSL server (PPPoE server) and finally to the Internet. The whole process is
achieved without PPPoE client software installed on hosts.
Configuring a PPPoE client
PPPoE client configuration includes dialer interface configuration and PPPoE session configuration.
A PPPoE session can operate in one of the following modes:
•Permanent mode—A PPPoE session is established immediately when the line is physically up. This
type of session remains until the physical link comes down or until the session is disconnected.
•On-demand mode—A PPPoE session is established when there is a demand for data transmission
instead of when the line is physically up. It is terminated when idled for a specific period of time.
•Diagnostic mode—A PPPoE session is established immediately after the device configurations finish,
and the device automatically terminates the PPPoE session and then tries to re-establish a PPPoE
session at a pre-configured interval. By establishing and terminating PPPoE sessions periodically,
you can monitor the operating status of the PPPoE link.
The PPPoE session operating mode is determined by your configuration on the dialer interface:
•Permanent mode—When you configure the link idle time as 0 by using the dialer timer idle
command and do not configure the dialer diagnose command, this mode is specified.
•On-demand mode—When you configure the link idle time as a value other than 0 by using the
dialer timer idle command and do not configure the dialer diagnose command, this mode is
specified.
•Diagnostic mode—When you configure the dialer diagnose command, this mode is specified.
Configuring a dialer interface
Before establishing a PPPoE session, you must first create a dialer interface and configure bundle
dial-on-demand routing (DDR) on the interface. Each PPPoE session uniquely corresponds to a dialer
bundle, and each dialer bundle uniquely corresponds to a dialer interface. Therefore, a PPPoE session
uniquely corresponds to a dialer interface.
For more information about configuring dialer interfaces, bundle DDR, and dialer bundles, see
"Configuring DDR."
Configuring a dialer interface for a PPPoE client
Ste
p
Command
Remarks
1. Enter system view. system-view N/A
2. Create a dialer access group
and configure a dial access
control rule.
dialer-group dialer-group
rule { protocol-name { deny |
permit } | acl { acl-number |
name acl-number }
By default, no dialer group exists.
3. Create a dialer interface and
enter its view. interface dialer number N/A
4. Assign an IP address to the
interface.
ip address { address mask |
ppp-negotiate } By default, no IP address is configured.
5. Enable bundle DDR on the
interface. dialer bundle enable By default, no DDR is enabled.

4
Ste
p
Command
Remarks
6. Associate the interface with
the dial access control rule by
associating the interface with
the corresponding dialer
access group.
dialer-group group-number By default, a dialer interface is not
assigned to any dialer group.
7. Configure the link-idle
timeout timer.
dialer timer idle idle [ in |
in-out ]
The default setting is 120 seconds.
When this timer is set to 0 seconds, the
PPPoE session operates in permanent
mode. Otherwise, the PPPoE session
operates in on-demand mode.
8. Configure the DDR
application to operate in
diagnostic mode.
dialer diagnose [ interval
interval ]
By default, the DDR application operates
in non-diagnostic mode.
When DDR operates in diagnostic mode,
the link-idle timeout timer is ignored.
9. Set the auto-dial interval. dialer timer autodial
autodial-interval
The default setting is 300 seconds.
In permanent or diagnostic mode, DDR
starts the auto-dial timer after the link is
disconnected and originates a new call
when the auto-dial timer expires.
HP recommends that you set a shorter
auto-dial interval for DDR to soon
originate a new call.
Configuring a PPPoE session
Ste
p
Command
Remarks
1. Enter system view. system-view N/A
2. Enter Layer 3 Ethernet
interface/subinterface, Layer 3
virtual Ethernet
interface/subinterface, VLAN
interface, or WLAN Ethernet
interface view.
interface interface-type
interface-number N/A
3. Create a PPPoE session and specify a
dialer bundle for the session.
pppoe-client
dial-bundle-number
number [ no-hostuniq ]
By default, no PPPoE sessions are
created.
The number argument in this command
must take the same value as the
configured dialer interface number.
Resetting a PPPoE session
After you reset a PPPoE session in permanent mode, the device establishes a new PPPoE session when the
autodial timer expires.
After you reset a PPPoE session in on-demand mode, the device establishes a new PPPoE session when
there is a demand for data transmission.

5
To reset a PPPoE session:
Ste
p
Command
Remarks
1. Reset a PPPoE session. reset pppoe-client { all |
dial-bundle-number number } Available in user view.
Displaying and maintaining PPPoE
Execute display commands in any view and reset commands in user view.
Task Command
Display summary information about a PPPoE
session.
display pppoe-client session summary [ dial-bundle-number
number ]
Display the protocol packet statistics for a PPPoE
session.
display pppoe-server session packet [ dial-bundle-number
number ]
Clear the protocol packet statistics for a PPPoE
session.
reset pppoe-server session packet [ dial-bundle-number
number ]
PPPoE client configuration examples
Configuring PPPoE client in permanent mode
Network requirements
As shown in Figure 4, Router A serves as a PPPoE server. Configure Router B as a PPPoE client operating
in permanent mode.
Figure 4 Network diagram
Configuration procedure
1. Configure Router B as the PPPoE client:
# Create dialer access group 1 and configure a dial access control rule for it.
<RouterB> system-view
[RouterB] dialer-group 1 rule ip permit
# Enable bundle DDR on interface Dialer 1.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer bundle enable
# Associate Dialer 1 with dialer access group 1.
[RouterB-Dialer1] dialer-group 1
# Configure Dialer 1 to obtain an IP address through PPP negotiation.

6
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] quit
# Configure a PPPoE session that corresponds to dialer bundle 1 (dialer bundle 1 corresponds to
interface Dialer 1).
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] pppoe-client dial-bundle-number 1
[RouterB-Ethernet1/1] quit
# Configure the PPPoE session to operate in permanent mode.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer timer idle 0
# Set the DDR auto-dial interval to 60 seconds.
[RouterB-Dialer1] dialer timer autodial 60
2. Verify the configuration by displaying summary information about the PPPoE session established
between Router B and Router A (PPPoE server).
[RouterB-Dialer1] display pppoe-client session summary
Bundle ID Interface VA RemoteMAC LocalMAC State
1 1 Eth1/1 VA0 00e0-1400-4300 00e0-1500-4100 SESSION
Configuring PPPoE client in on-demand mode
Network requirements
As shown in Figure 5, Router A serves as a PPPoE server. Configure Router B as a PPPoE client operating
in on-demand mode, and set the link idle-timeout timer to 150 seconds.
Figure 5 Network diagram
Configuration procedure
1. Configure Router B as the PPPoE client.
# Create dialer access group 1 and configure a dial access control rule for it.
<RouterB> system-view
[RouterB] dialer-group 1 rule ip permit
# Enable bundle DDR on interface Dialer 1.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer bundle enable
# Associate Dialer 1 with dialer access group 1.
[RouterB-Dialer1] dialer-group 1
# Configure Dialer 1 to obtain an IP address through PPP negotiation.
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] quit
# Configure a PPPoE session that corresponds to dialer bundle 1 (dialer bundle 1 corresponds to
Dialer 1).
[RouterB] interface ethernet 1/1

7
[RouterB-Ethernet1/1] pppoe-client dial-bundle-number 1
[RouterB-Ethernet1/1] quit
# Set the link-idle timeout timer to 150 seconds.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer timer idle 150
[RouterB-Dialer1] quit
2. Verify the configuration by displaying summary information about the PPPoE session established
between Router B and Router A (PPPoE server).
[RouterB-Dialer1] display pppoe-client session summary
Bundle ID Interface VA RemoteMAC LocalMAC State
1 1 Eth1/1 VA0 00e0-1400-4300 00e0-1500-4100 SESSION
Configuring PPPoE client in diagnostic mode
Network requirements
As shown in Figure 6, Router A serves as a PPPoE server. Configure Router B as a PPPoE client operating
in diagnostic mode, and set the diagnostic interval to 200 seconds.
Figure 6 Network diagram
Configuration procedure
1. Configure Router B as the PPPoE client.
# Create dialer access group 1 and configure a dial access control rule for it.
<RouterB> system-view
[RouterB] dialer-group 1 rule ip permit
# Enable bundle DDR on interface Dialer 1.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer bundle enable
# Associate Dialer 1 with dialer access group 1.
[RouterB-Dialer1] dialer-group 1
# Configure Dialer 1 to obtain an IP address through PPP negotiation.
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] quit
# Configure a PPPoE session that corresponds to dialer bundle 1 (dialer bundle 1 corresponds to
Dialer 1).
[RouterB] interface ethernet 1/1
[RouterB-Ethernet1/1] pppoe-client dial-bundle-number 1
[RouterB-Ethernet1/1] quit
# Configure the PPPoE session to operate in diagnostic mode, and set the diagnostic interval to
200 seconds.
[RouterB] interface dialer 1
[RouterB-Dialer1] dialer diagnose interval 200

8
# Set the DDR auto-dial interval to 10 seconds.
[RouterB-Dialer1] dialer timer autodial 10
2. Verify the configuration by displaying summary information about the PPPoE session established
between Router B and Router A (PPPoE server).
[RouterB-Dialer1] display pppoe-client session summary
Bundle ID Interface VA RemoteMAC LocalMAC State
1 1 Eth1/1 VA0 00e0-1400-4300 00e0-1500-4100 SESSION

9
Configuring L2TP
Overview
The Layer 2 Tunneling Protocol (L2TP) is the most widely used Virtual Private Dialup Network (VPDN)
tunneling protocol. L2TP sets up point-to-point tunnels across a public network (for example, the Internet)
and transmits encapsulated PPP frames (L2TP packets) over the tunnels. With L2TP, remote users (for
example, remote branches and mobile workers) can access the corporate intranets through L2TP tunnels
after connecting to a public network by using PPP.
As a Layer 2 VPN technology, L2TP provides a secure, cost-effective solution for remote users to access
corporate intranets.
Typical L2TP networking
Figure 7 L2TP network diagram
As shown in Figure 7, a typical L2TP network has the following components:
•Remote system—A remote system is usually a remote user's host or a remote branch's device that
needs to access the corporate intranet.
•LAC—An L2TP access concentrator (LAC) is a device with PPP and L2TP capabilities. It is usually a
network access server (NAS) located at a local ISP, which provides access services mainly for PPP
users.
An LAC is an endpoint of an L2TP tunnel and lies between an LNS and a remote system. It
encapsulates packets received from a remote system by using L2TP and then sends the
encapsulated packets to the LNS. It decapsulates packets received from the LNS and then sends
the decapsulated packets to the intended remote system.
•LNS—An L2TP network server (LNS) is both PPP and L2TP capable. It is usually an edge device on
an enterprise network.
An LNS is the other endpoint of an L2TP tunnel. It is the logical termination point of a PPP session
tunneled by the LAC. L2TP extends the termination point of a PPP session from a NAS to an LNS by
establishing a tunnel.

10
L2TP message types and encapsulation structure
L2TP uses the following types of messages:
•Control messages—Used to establish, maintain, and delete L2TP tunnels and sessions. Control
messages are transmitted over a reliable control channel, which supports flow control and
congestion control.
•Data messages—Used to encapsulate PPP frames, as shown in Figure 8. Data messages are
transmitted over an unreliable data channel and are not retransmitted when packet loss occurs.
Data messages can use sequence numbers to reorder packets that are disordered during transport.
Figure 8 Data message format
As shown in Figure 9, both control messages and data messages are encapsulated in UDP datagrams.
Figure 9 L2TP encapsulation structure
L2TP tunnel and session
An L2TP tunnel is a virtual point-to-point connection between an LAC-LNS pair. Multiple L2TP tunnels can
be established between an LNS and an LAC. A tunnel can carry one or more L2TP sessions. Each L2TP
session corresponds to a PPP session and is multiplexed on a tunnel. An L2TP session is established
between the LAC and LNS when an end-to-end PPP session is established between a remote system and
the LNS. Data frames for the PPP session are transmitted over the tunnel between the LAC and LNS.
L2TP tunneling modes and tunnel establishment process
Three tunneling modes are available: NAS-initiated, client-initiated, and LAC-auto-initiated.
NAS-initiated tunneling mode
As shown in Figure 10, a remote system dials in to the LAC through a PPPoE/ISDN network, and the LAC
initiates a tunneling request to the LNS over the Internet.

11
Figure 10 NAS-initiated tunneling mode
A NAS-initiated tunnel has the following characteristics:
•The remote system only needs to support PPP, and does not need to support L2TP.
•Authentication and accounting of the remote system can be implemented on the LAC or the LNS.
Figure 11 Establishment process for NAS-initiated tunnels
As shown in Figure 11, the following workflow is used to establish a NAS-initiated tunnel:
1. A remote system (Host A) initiates a PPP connection to the LAC (Device A).
2. The remote system and LAC perform PPP LCP negotiation.
3. The LAC authenticates PPP user information of Host A by using PAP or CHAP.
(1) Call setup
(2) LCP negotiation
(3) PAP or CHAP
authenticaion
(4) Access request
(5) Access accept
(6) Tunnel setup request
(7) CHAP authentication (challenge/response)
(9) Send user information and LCP negotiation
parameters
(12) CHAP authentication (challenge/response)
(10) Access request
(11) Acesss accept
(13) Access request
(14) Acesss accept
(15) Authentication passes, and assign an IP address
LAC
Device A LNS Device B
RADIUS server A RADIUS server B
Remote system
Host A
(16) Access the enterprise network
(8) Setup a session

12
4. The LAC sends the authentication information (username and password) to its RADIUS server
(RADIUS server A) for authentication.
5. RADIUS server A authenticates the user and returns the result.
6. If the user passes the authentication and the user is determined to be an L2TP user according to the
username or the ISP domain to which the user belongs, the LAC initiates an L2TP tunneling request
to the LNS (Device B).
7. If tunnel authentication is needed, the LAC and LNS send CHAP challenge messages to
authenticate each other before successfully establishing an L2TP tunnel.
8. The LAC and LNS negotiate to establish L2TP sessions.
9. The LAC sends PPP user information and PPP negotiation parameters to the LNS.
10. The LNS sends the authentication information to its RADIUS server (RADIUS server B) for
authentication.
11. RADIUS server B authenticates the user and returns the result.
12. In the case of successful authentication, the LNS authenticates the PPP user by sending a CHAP
challenge if mandatory CHAP authentication is configured on the LNS. The PPP user replies with a
CHAP response.
13. The LNS sends the authentication information to RADIUS server B for authentication.
14. RADIUS server B authenticates the user and returns the result.
15. If the user passes the authentication, the LNS assigns a private IP address to the remote system
(Host A).
16. The PPP user can access internal resources of the enterprise.
In steps 12, 15, and 16, the LAC forwards packets for the remote system and LNS. Host A and LAC
exchange PPP frames, and the LAC and LNS exchange L2TP packets.
Client-initiated tunneling mode
As shown in Figure 12, after being permitted to access the Internet, a remote system running the L2TP
client application (LAC client) directly initiates a tunneling request to the LNS without any dedicated LAC
device. The LAC client has a public IP address to communicate with the LNS through the Internet.
Figure 12 Client-initiated tunneling mode
A client-initiated tunnel has the following characteristics:
•A client-initiated tunnel has higher security because it is established between a remote system and
the LNS.
•The remote system must support L2TP and can communicate with the LNS. This causes poor
expandability.

13
As shown in Figure 13, the workflow for establishing a client-initiated tunnel is similar to that for
establishing a NAS-initiated tunnel. (Details not shown.)
Figure 13 Establishment process for client-initiated tunnels
LAC-auto-initiated tunneling mode
In NAS-initiated mode, a remote system must successfully dial in to the LAC through PPPoE or ISDN.
In LAC-auto-initiated mode, you can use the l2tp-auto-client command on the LAC to trigger the LAC to
initiate a tunneling request to the LNS. When a remote system accesses the internal network, the LAC
forwards data through the L2TP tunnel.
Figure 14 LAC-auto-initiated tunneling mode
An LAC-auto-initiated tunnel has the following characteristics:
•The connection between a remote system and the LAC is not confined to a dial-up connection and
can be any IP-based connection.
•An L2TP session is established immediately after an L2TP tunnel is established. Then, the LAC and
LNS, acting as the PPPoE client and PPPoE server, respectively, perform PPP negotiation.
•An L2TP tunnel can carry only one L2TP session.
•The LNS assigns a private IP address to the LAC instead of to the remote system.
As shown in Figure 15, the workflow for establishing an LAC-auto-initiated tunnel is similar to that for
establishing a NAS-initiated tunnel. (Details not shown.)
(1) Tunnel setup request
(2) CHAP authentication (challenge/response)
(3) Setup a session
(4) LCP negotiation and user authentication
(5) Access request
(6) Acesss accept
(7) Authentication passes, and assign an IP address
LNS
Device A RADIUS server
LAC client
Host A
(8) Access the private network
LAN Internet
Remote system
Host A
Private
network
L2TP tunnel
LAC auto initiated
LAC
Device A LNS Device B
RADIUS server

14
Figure 15 Establishment process for LAC-auto-initiated tunnels
L2TP features
•Flexible identity authentication mechanism and high security—L2TP by itself does not provide
security for connections. However, it has all the security features of PPP and allows for PPP
authentication (CHAP or PAP). L2TP can also cooperate with IPsec to guarantee data security,
strengthening the guard against attacks for tunneled data.
•Multiprotocol transmission—L2TP tunnels PPP frames, which can be used to encapsulate packets of
multiple network layer protocols.
•RADIUS authentication—An LAC or LNS can send the username and password of a remote user to
a RADIUS server for authentication.
•Private address allocation—An LNS can dynamically allocate private addresses to remote users,
facilitating corporate private address management (RFC 1918) and improving security.
•Flexible accounting—Accounting can be simultaneously carried out on the LAC and LNS, allowing
bills to be generated on the ISP side and charging and auditing to be processed on the enterprise
gateway. L2TP can provide accounting data, such as inbound and outbound traffic statistics (in
packets and bytes) and the connection's start time and end time. The AAA server uses this data for
flexible accounting.
•Reliability—L2TP supports LNS backup. When the connection to the primary LNS is torn down, an
LAC can establish a new connection to a secondary LNS. This redundancy enhances the reliability
of L2TP services.
•Issuing tunnel attributes by RADIUS server to LAC—In NAS-initiated mode, the tunnel attributes can
be issued by the RADIUS server to the LAC. To receive these attributes, you only need to enable
L2TP and configure remote AAA authentication for PPP users on the LAC.
When an L2TP user dials in to the LAC, the LAC as the RADIUS client sends the user information to
the RADIUS server. The RADIUS server authenticates the PPP user, returns the result to the LAC, and
issues L2TP tunnel attributes for the PPP user to the LAC. The LAC then sets up an L2TP tunnel and
sessions based on the issued L2TP tunnel attributes.

15
Table 1 Tunnel attributes that can be issued by the RADIUS server
Attribute number Attribute name
Descri
p
tion
64 Tunnel-Type Tunnel type, which can only be L2TP.
65 Tunnel-Medium-Type Transmission medium type for the tunnel, which can
only be IPv4.
67 Tunnel-Server-Endpoint IP address of the LNS.
69 Tunnel-Password Key used to authenticate a peer of the tunnel.
81 Tunnel-Private-Group-ID
Group ID for the tunnel.
The LAC sends this value to the LNS for the LNS to
perform an operation accordingly.
82 Tunnel-Assignment-ID
Assignment ID for the tunnel.
It is used to indicate the tunnel to which a session is
assigned. L2TP users with same
Tunnel-Assignment-ID, Tunnel-Server-Endpoint, and
Tunnel-Password attributes share an L2TP tunnel.
The RADIUS server can issue only one set of the L2TP tunnel attributes in a RADIUS packet.
The RADIUS-issued tunnel attributes will override the tunnel attributes you have manually
configured on the LAC, but not vice versa.
Protocols and standards
•RFC 1661, The Point-to-Point Protocol (PPP)
•RFC 1918, Address Allocation for Private Internets
•RFC 2661, Layer Two Tunneling Protocol "L2TP"
•RFC 2868, RADIUS Attributes for Tunnel Protocol Support
L2TP configuration task list
When you configure L2TP, perform the following operations:
1. Determine the network devices needed according to the networking environment. For
NAS-initiated mode and LAC-auto-initiated mode, configure both the LAC and the LNS. For
client-initiated mode, you only need to configure the LNS.
2. Configure the devices accordingly, based on the intended role (LAC or LNS) on the network.
To configure a device as an LAC in NAS-initiated or LAC-auto-initiated mode, complete the following
tasks:
Tasks at a
g
lance
Remarks
(Required.) Configuring basic L2TP capabilities N/A

16
Tasks at a
g
lance
Remarks
Configuring an LAC
•(Required.) Configuring an LAC to initiate tunneling requests for a
specified user
•(Required.) Specifying LNS IP addresses
•(Required.) Configuring transferring AVP data in hidden mode
•(Optional.) Configuring AAA authentication on an LAC
•(Required.) Configuring an LAC to automatically establish an L2TP
tunnel
The first task is required for
NAS-initiated mode and
unnecessary for LAC-auto-initiated
mode.
The last task is required for
LAC-auto-initiated mode and
unnecessary for NAS-initiated
mode.
(Optional.) Configuring optional L2TP parameters
•Configuring L2TP tunnel authentication
•Setting the Hello interval
•Enabling session flow control
•Configuring the DSCP value of L2TP packets
•Configuring the VPN for a tunnel peer
N/A
To configure a device as an LNS in NAS-initiated, client-initiated, or LAC-auto-initiated mode, complete
the following tasks:
Tasks at a
g
lance
(Required.) Configuring basic L2TP capabilities
Configuring an LNS
•(Required.) Creating a VT interface
•(Required.) Configuring an LNS to accept L2TP tunneling requests from a specified LAC
•(Optional.) Configuring user authentication on an LNS
•(Optional.) Configuring AAA authentication on an LNS
(Optional.) Configuring optional L2TP parameters
•Configuring L2TP tunnel authentication
•Setting the Hello interval
•Enabling session flow control
•Configuring the DSCP value of L2TP packets
•Configuring the VPN for a tunnel peer
Configuring basic L2TP capabilities
Basic L2TP capability configuration includes the following:
•Enabling L2TP—L2TP must be enabled for L2TP configurations to take effect.
•Creating an L2TP group—An L2TP group is intended to represent a group of parameters. This
enables not only flexible L2TP configuration on devices, but also one-to-one and one-to-many
networking applications for LACs and LNSs. An L2TP group has local significance only. However,
you must make sure the relevant settings of the L2TP groups on the LAC and LNS match. For example,
the local tunnel name configured on the LAC must match the tunnel peer name configured on the
LNS.