ON THIS PAGE
Layer 2 Tunneling of PPP Packets
Layer 2 Tunneling Protocol Overview
L2TP is defined in RFC 2661, Layer Two Tunneling Protocol (L2TP).
L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end users and applications. It employs access profiles for group and individual user access, and uses authentication to establish secure connections between the two ends of each tunnel. Multilink PPP functionality is also supported.
The L2TP services are supported on the following routers only:
M7i routers with AS PICs
M10i routers with AS and MultiServices 100 PICs
M120 routers with AS, MultiServices 100, and MultiServices 400 PICs
On MX Series routers, the L2TP access concentrator (LAC) and L2TP network server (LNS) functions are supported only on MPCs; they are not supported on any services PIC or MS-DPC. For details about MPC support for L2TP, see the MX Series Interface Module Reference
For more information, see L2TP Services Configuration Overview.
See Also
L2TP Services Configuration Overview
The statements for configuring L2TP services are found at the following hierarchy levels:
[edit services l2tp tunnel-group group-name]
The L2TP tunnel-group statement identifies an L2TP instance or L2TP server. Associated statements specify the local gateway address on which incoming tunnels and sessions are accepted, the Adaptive Services (AS) Physical Interface Card (PIC) that processes data for the sessions in this tunnel group, references to L2TP and PPP access profiles, and other attributes for configuring window sizes and timer values.
[edit interfaces sp-fpc/pic/port unit logical-unit-number dial-options]
The dial-options statement includes configuration for the l2tp-interface-id statement and the shared/dedicated flag. The interface identifier associates a user session with a logical interface. Sessions can use either shared or dedicated logical interfaces. To run routing protocols, a session must use a dedicated logical interface.
[edit access profile profile-name client name l2tp]
Tunnel profiles are defined at the [edit access] hierarchy level. Tunnel clients are defined with authentication, multilink negotiation and fragmentation, and other L2TP attributes in these profiles.
[edit access profile profile-name client name ppp]
User profiles are defined at the [edit access] hierarchy level. User clients are defined with authentication and other PPP attributes in these profiles. These client profiles are used when local authentication is specified.
[edit access radius-server address]
When you configure authentication-order radius at the [edit access profile profile-name] hierarchy level, you must configure a RADIUS service at the [edit access radius-server] hierarchy level.
For more information about configuring properties at the [edit access] hierarchy level, see the Junos OS Administration Library for Routing Devices. For information about L2TP LAC and LNS configurations on MX Series routers for subscriber access, see L2TP for Subscriber Access Overview in the Junos Subscriber Access Configuration Guide.
L2TP Minimum Configuration
To configure L2TP services, you must perform at least the following tasks:
Define a tunnel group at the
[edit services l2tp]hierarchy level with the following attributes:l2tp-access-profile—Profile name for the L2TP tunnel.ppp-access-profile—Profile name for the L2TP user.local-gateway—Address for the L2TP tunnel.service-interface—AS PIC interface for the L2TP service.Optionally, you can configure
traceoptionsfor debugging purposes.
The following example shows a minimum configuration for a tunnel group with trace options:
[edit services l2tp] tunnel-group finance-lns-server { l2tp-access-profile westcoast_bldg_1_tunnel; ppp-access-profile westcoast_bldg_1; local-gateway { address 10.21.255.129; } service-interface sp-1/3/0; } traceoptions { flag all; filter { protocol udp; protocol l2tp; protocol ppp; protocol radius; } }At the
[edit interfaces]hierarchy level:Identify the physical interface at which L2TP tunnel packets enter the router, for example
ge-0/3/0.Configure the AS PIC interface with
unit 0 family inetdefined for IP service, and configure another logical interface withfamily inetand thedial-optionsstatement.
The following example shows a minimum interfaces configuration for L2TP:
[edit interfaces] ge-0/3/0 { unit 0 { family inet { address 10.58.255.129/28; } } } sp-1/3/0 { unit 0 { family inet; } unit 20 { dial-options { l2tp-interface-id test; shared; } family inet; } }At the
[edit access]hierarchy level:Configure a tunnel profile. Each client specifies a unique L2TP Access Concentrator (LAC) name with an
interface-idvalue that matches the one configured on the AS PIC interface unit;shared-secretis authentication between the LAC and the L2TP Network Server (LNS).Configure a user profile. If RADIUS is used as the authentication method, it needs to be defined.
Define the RADIUS server with an IP address, port, and authentication data shared between the router and the RADIUS server.
Note:When the L2TP Network Server (LNS) is configured with RADIUS authentication, the default behavior is to accept the preferred RADIUS-assigned IP address. Previously, the default behavior was to accept and install the nonzero peer IP address that came into the IP-Address option of the IPCP Configuration Request packet.
Optionally, you can define a group profile for common attributes, for example
keepalive 0to turn off keepalive messages.
The following example shows a minimum profiles configuration for L2TP:
[edit access] group-profile westcoast_users { ppp { keepalive 0; } } profile westcoast_bldg_1_tunnel { client production { l2tp { interface-id test; shared-secret "$ABC123"; # SECRET-DATA } user-group-profile westcoast_users; } } profile westcoast_bldg_1 { authentication-order radius; } radius-server { 192.168.65.63 { port 1812; secret "$ABC123"; # SECRET-DATA } }
See Also
Configuring L2TP Tunnel Groups
To establish L2TP service on a router, you need to identify
an L2TP tunnel group and specify a number of values that define which
access profiles, interface addresses, and other properties to use
in creating a tunnel. To identify the tunnel group, include the tunnel-group statement at the [edit services l2tp] hierarchy level.
If you delete a tunnel group or mark it inactive, all
L2TP sessions in that tunnel group are terminated. If you change the
value of the local-gateway address or the service-interface statement, all L2TP sessions using those settings are terminated.
If you change or delete other statements at the [edit services
l2tp tunnel-group group-name] hierarchy
level, new tunnels you establish will use the updated values but existing
tunnels and sessions are not affected.
This following sections explain how to configure L2TP tunnel groups:
- Configuring Access Profiles for L2TP Tunnel Groups
- Configuring the Local Gateway Address and PIC
- Configuring Window Size for L2TP Tunnels
- Configuring Timers for L2TP Tunnels
- Hiding Attribute-Value Pairs for L2TP Tunnels
- Configuring System Logging of L2TP Tunnel Activity
Configuring Access Profiles for L2TP Tunnel Groups
To validate L2TP connections and session requests, you set up
access profiles by configuring the profile statement at
the [edit access] hierarchy level. You need to configure
two types of profiles:
L2TP tunnel access profile, which validates all L2TP connection requests to the specified local gateway address
PPP access profile, which validates all PPP session requests through L2TP tunnels established to the local gateway address
For more information on configuring the profiles, see the Junos OS Administration Library for Routing Devices. A profile example is included in Examples: Configuring L2TP Services.
To associate the profiles with a tunnel group, include the l2tp-access-profile and ppp-access-profile statements
at the [edit services l2tp tunnel-group group-name] hierarchy level:
l2tp-access-profile profile-name; ppp-access-profile profile-name;
Configuring the Local Gateway Address and PIC
When you configure an L2TP group, you must also define a local address for the L2TP tunnel connections and the AS PIC that processes the requests:
To configure the local gateway IP address, include the
addressstatement at the[edit services l2tp tunnel-group group-name local-gateway]hierarchy level:address address;
To configure the AS PIC, include the
service-interfacestatement at the[edit services l2tp tunnel-group group-name]hierarchy level:service-interface sp-fpc/pic/port;
You can optionally specify the logical unit number along with the service interface. If specified, the unit is used as a logical interface representing PPP sessions negotiated using this profile.
If you change the local gateway address or the service interface configuration, all L2TP sessions using those settings are terminated.
Dynamic class-of-service (CoS) functionality is supported on L2TP LNS sessions or L2TP sessions with ATM VCs, as long as the L2TP session is configured to use an IQ2 PIC on the egress interface. For more information, see the Class of Service User Guide (Routers and EX9200 Switches).
Configuring Window Size for L2TP Tunnels
You can configure the maximum window size for packet processing at each end of the L2TP tunnel:
The receive window size limits the number of concurrent packets the server processes. By default, the maximum is 16 packets. To change the window size, include the
receive-windowstatement at the[edit services l2tp tunnel-group group-name]hierarchy level:receive-window packets;
The maximum-send window size limits the other end’s receive window size. The information is transmitted in the receive window size attribute-value pair. By default, the maximum is 32 packets. To change the window size, include the
maximum-send-windowstatement at the[edit services l2tp tunnel-group group-name]hierarchy level:maximum-send-window packets;
Configuring Timers for L2TP Tunnels
You can configure the following timer values that regulate L2TP tunnel processing:
Hello interval—If the server does not receive any messages within a specified time interval, the router software sends a hello message to the tunnel’s remote peer. By default, the interval length is 60 seconds. If you configure a value of 0, no hello messages are sent. To configure a different value, include the
hello-intervalstatement at the[edit services l2tp tunnel-group group-name]hierarchy level:hello-interval seconds;
Retransmit interval—By default, the retransmit interval length is 30 seconds. To configure a different value, include the
retransmit-intervalstatement at the[edit services l2tp tunnel-group group-name]hierarchy level:retransmit-interval seconds;
Tunnel timeout—If the server cannot send any data through the tunnel within a specified time interval, it assumes that the connection with the remote peer has been lost and deletes the tunnel. By default, the interval length is 120 seconds. To configure a different value, include the
tunnel-timeoutstatement at the[edit services l2tp tunnel-group group-name]hierarchy level:tunnel-timeout seconds;
Hiding Attribute-Value Pairs for L2TP Tunnels
Once an L2TP tunnel has been established and the connection
authenticated, information is encoded by means of attribute-value
pairs. By default, this information is not hidden. To hide the attribute-value
pairs once the shared secret is known, include the hide-avps statement at the [edit services l2tp tunnel-group group-name] hierarchy level:
hide-avps;
Configuring System Logging of L2TP Tunnel Activity
You can specify properties that control how system log messages are generated for L2TP services.
To configure interface-wide default system logging values, include
the syslog statement at the [edit services l2tp tunnel-group group-name] hierarchy level:
syslog { host hostname { services severity-level; facility-override facility-name; log-prefix prefix-value; } }
Configure the host statement with a hostname or IP
address that specifies the system log target server. The hostname local directs system log messages to the Routing Engine. For
external system log servers, the hostname must be reachable from the
same routing instance to which the initial data packet (that triggered
session establishment) is delivered. You can specify only one system
logging hostname.
Table 1 lists the severity levels
that you can specify in configuration statements at the [edit
services l2tp tunnel-group group-name syslog
host hostname] hierarchy level. The levels
from emergency through info are in order from
highest severity (greatest effect on functioning) to lowest.
Severity Level |
Description |
|---|---|
|
Includes all severity levels |
|
System panic or other condition that causes the router to stop functioning |
|
Conditions that require immediate correction, such as a corrupted system database |
|
Critical conditions, such as hard drive errors |
|
Error conditions that generally have less serious consequences than errors in the emergency, alert, and critical levels |
|
Conditions that warrant monitoring |
|
Conditions that are not errors but might warrant special handling |
|
Events or nonerror conditions of interest |
We recommend setting the system logging severity level to error during normal operation. To monitor PIC resource usage,
set the level to warning. To gather information about an
intrusion attack when an intrusion detection system error is detected,
set the level to notice for a specific service set. To
debug a configuration or log Network Address Translation (NAT) events,
set the level to info.
For more information about system log messages, see the System Log Explorer.
To use one particular facility code for all logging to the specified
system log host, include the facility-override statement
at the [edit services l2tp tunnel-group group-name syslog host hostname] hierarchy level:
facility-override facility-name;
The supported facilities include: authorization, daemon, ftp, kernel, user,
and local0 through local7.
To specify a text prefix for all logging to this system log
host, include the log-prefix statement at the [edit
services l2tp tunnel-group group-name syslog
host hostname] hierarchy level:
log-prefix prefix-text;
Configuring the Identifier for Logical Interfaces that Provide L2TP Services
You can configure L2TP services on adaptive services interfaces on M7i, M10i, M120, and MX Series routers only. You must configure the logical interface to be dedicated or shared. If a logical interface is dedicated, it can represent only one session at a time. A shared logical interface can have multiple sessions.
To configure the logical interface, include the l2tp-interface-id statement at the [edit interfaces interface-name unit logical-unit-number dial-options] hierarchy level:
l2tp-interface-id name; (dedicated | shared);
The l2tp-interface-id name configured on the logical
interface must be replicated at the [edit access profile name] hierarchy level:
For a user-specific identifier, include the
l2tp-interface-idstatement at the[edit access profile name ppp]hierarchy level.For a group identifier, include the
l2tp-interface-idstatement at the[edit access profile name l2tp]hierarchy level.
You can configure multiple logical interfaces with the same interface identifier, to be used as a pool for several users. For more information on configuring access profiles, see the Junos OS Administration Library for Routing Devices.
If you delete the dial-options statement settings
configured on a logical interface, all L2TP sessions running on that
interface are terminated.
Example: Configuring Multilink PPP on a Shared Logical Interface
Multilink PPP is supported on either shared or dedicated logical interfaces. The following example can be used to configure many multilink bundles on a single shared interface:
interfaces {
sp-1/3/0 {
traceoptions {
flag all;
}
unit 0 {
family inet;
}
unit 20 {
dial-options {
l2tp-interface-id test;
shared;
}
family inet;
}
}
}
access {
profile t {
client test {
l2tp {
interface-id test;
multilink;
shared-secret "$ABC123"; # SECRET-DATA
}
}
}
profile u {
authentication-order radius;
}
radius-server {
192.168.65.63 {
port 1812;
secret "$ABC123"; # SECRET-DATA
}
}
}
services {
l2tp {
tunnel-group 1 {
l2tp-access-profile t;
ppp-access-profile u;
local-gateway {
address 10.70.1.1;
}
service-interface sp-1/3/0;
}
traceoptions {
flag all;
debug-level packet-dump;
filter {
protocol l2tp;
protocol ppp;
protocol radius;
}
}
}
}
AS PIC Redundancy for L2TP Services
L2TP services support AS PIC redundancy. To configure redundancy,
you specify a redundancy services PIC (rsp) interface in
which the primary AS PIC is active and a secondary AS PIC is on standby.
If the primary AS PIC fails, the secondary PIC becomes active, and
all service processing is transferred to it. If the primary AS PIC
is restored, it remains in standby and does not preempt the secondary
AS PIC; you need to manually restore the services to the primary PIC.
To determine which PIC is currently active, issue the show interfaces
redundancy command.
On L2TP, the only service option supported is warm standby, in which one backup PIC supports multiple working PICs. Recovery times are not guaranteed, because the configuration must be completely restored on the backup PIC after a failure is detected. The tunnels and sessions are torn down upon switchover and need to be restarted by the LAC and PPP client, respectively. However, configuration is preserved and available on the new active PIC, although the protocol state needs to be reestablished.
As with the other AS PIC services that support warm standby,
you can issue the request interfaces (revert | switchover) command to manually switch between primary and secondary L2TP interfaces.
For more information, see Configuring AS or Multiservices PIC Redundancy. For an example configuration, see Examples: Configuring L2TP Services. For information on operational mode commands, see the CLI Explorer.
Examples: Configuring L2TP Services
Configure L2TP with multiple group and user profiles and a pool of logical interfaces for concurrent tunnel sessions:
[edit access]
address-pool customer_a {
address 10.1.1.1/32;
}
address-pool customer_b {
address-range low 10.2.2.1 high 10.2.3.2;
}
group-profile sunnyvale_users {
ppp {
framed-pool customer_a;
idle-timeout 15;
primary-dns 192.168.65.1;
secondary-dns 192.168.65.2;
primary-wins 192.168.65.3;
secondary-wins 192.168.65.4;
interface-id west;
}
}
group-profile eastcoast_users {
ppp {
framed-pool customer_b;
idle-timeout 20;
primary-dns 192.168.65.5;
secondary-dns 192.168.65.6;
primary-wins 192.168.65.7;
secondary-wins 192.168.65.8;
interface-id east;
}
}
group-profile sunnyvale_tunnel {
l2tp {
maximum-sessions-per-tunnel 100;
interface-id west_shared;
}
}
group-profile east_tunnel {
l2tp {
maximum-sessions-per-tunnel 125;
interface-id east_shared;
}
}
profile sunnyvale_bldg_1 {
client white {
chap-secret "$ABC123"; # SECRET-DATA
ppp {
idle-timeout 22;
primary-dns 192.168.65.1;
framed-ip-address 10.12.12.12/32;
interface-id east;
}
group-profile sunnyvale_users;
}
client blue {
chap-secret "$ABC123"; # SECRET-DATA
group-profile sunnyvale_users;
}
authentication-order password;
}
profile sunnyvale_bldg_1_tunnel {
client test {
l2tp {
shared-secret "$ABC123"; # SECRET-DATA
maximum-sessions-per-tunnel 75;
interface-id west_shared;
ppp-authentication chap;
}
group-profile sunnyvale_tunnel;
}
client production {
l2tp {
shared-secret "$ABC123";
ppp-authentication chap;
}
group-profile sunnyvale_tunnel;
}
}
[edit services]
l2tp {
tunnel-group finance-lns-server {
l2tp-access-profile sunnyvale_bldg_1_tunnel;
ppp-access-profile sunnyvale_bldg_1;
local-gateway {
address 10.1.117.3;
}
service-interface sp-1/3/0;
receive-window 1500;
maximum-send-window 1200;
retransmit-interval 5;
hello-interval 15;
tunnel-timeout 55;
}
traceoptions {
flag all;
}
}
[edit interfaces sp-1/3/0]
unit0 {
family inet;
}
unit 10 {
dial-options {
l2tp-interface-id foo-user;
dedicated;
}
family inet;
}
unit 11 {
dial-options {
l2tp-interface-id east;
dedicated;
}
family inet;
}
unit 12 {
dial-options {
l2tp-interface-id east;
dedicated;
}
family inet;
}
unit 21 {
dial-options {
l2tp-interface-id west;
dedicated;
}
family inet;
}
unit 30 {
dial-options {
l2tp-interface-id west_shared;
shared;
}
family inet;
}
unit 40 {
dial-options {
l2tp-interface-id east_shared;
shared;
}
family inet;
}
Configure L2TP redundancy:
interfaces {
rsp0 {
redundancy-options {
primary sp-0/0/0;
secondary sp-1/3/0;
}
unit 0 {
family inet;
}
unit 11 {
dial-options {
l2tp-interface-id east_shared;
shared;
}
family inet;
}
}
}
Tracing L2TP Operations
Tracing operations track all AS PIC operations and record them in a log file in the /var/log directory. By default, this file is named /var/log/l2tpd.
This topic refers to tracing L2TP LNS operations on M Series routers. To trace L2TP LAC operations on MX Series routers, see Tracing L2TP Events for Troubleshooting.
To trace L2TP operations, include the traceoptions statement at the [edit services l2tp] hierarchy level:
traceoptions { debug-level level; file <filename> <files number> <match regular-expression > <size maximum-file-size> <world-readable | no-world-readable>; filter { protocol name; user-name username; } flag flag; interfaces interface-name { debug-level severity; flag flag; } level (all | error | info | notice | verbose | warning); no-remote-trace; }
You can specify the following L2TP tracing flags:
all—Trace everything.configuration—Trace configuration events.protocol—Trace routing protocol events.routing-socket—Trace routing socket events.rpd—Trace routing protocol process events.
You can specify a trace level for PPP, L2TP, RADIUS,
and User Datagram Protocol (UDP) tracing. To configure a trace level,
include the debug-level statement at the [edit services
l2tp traceoptions] hierarchy level and specify one of the following
values:
detail—Detailed debug informationerror—Errors onlypacket-dump—Packet decoding information
You can filter by protocol. To configure filters, include
the filter protocol statement at the [edit services
l2tp traceoptions] hierarchy level and specify one or more of
the following protocol values:
pppl2tpradiusudp
To implement filtering by protocol name, you must also configure
either flag protocol or flag all.
You can also configure traceoptions for L2TP on a specific adaptive
services interface. To configure per-interface tracing, include the interfaces statement at the [edit services l2tp traceoptions] hierarchy level:
interfaces interface-name {
debug-level level;
flag flag;
}
Implementing traceoptions consumes CPU resources and affects the packet processing performance.
You can specify the debug-level and flag statements for the interface, but the options are slightly different
from the general L2TP traceoptions. You specify the debug level as detail, error, or extensive, which provides
complete PIC debug information. The following flags are available:
all—Trace everything.ipc—Trace L2TP Inter-Process Communication (IPC) messages between the PIC and the Routing Engine.packet-dump—Dump each packet’s content based on debug level.protocol—Trace L2TP, PPP, and multilink handling.system—Trace packet processing on the PIC.