Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

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.

Note:

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 traceoptions for debugging purposes.

    The following example shows a minimum configuration for a tunnel group with trace options:

  • 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 inet defined for IP service, and configure another logical interface with family inet and the dial-options statement.

    The following example shows a minimum interfaces configuration for L2TP:

  • At the [edit access] hierarchy level:

    • Configure a tunnel profile. Each client specifies a unique L2TP Access Concentrator (LAC) name with an interface-id value that matches the one configured on the AS PIC interface unit; shared-secret is 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 0 to turn off keepalive messages.

    The following example shows a minimum profiles configuration for L2TP:

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.

Note:

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

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:

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 address statement at the [edit services l2tp tunnel-group group-name local-gateway] hierarchy level:

  • To configure the AS PIC, include the service-interface statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

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.

Note:

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-window statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

  • 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-window statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

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-interval statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

  • Retransmit interval—By default, the retransmit interval length is 30 seconds. To configure a different value, include the retransmit-interval statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

  • 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-timeout statement at the [edit services l2tp tunnel-group group-name] hierarchy level:

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:

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:

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.

Table 1: System Log Message Severity Levels

Severity Level

Description

any

Includes all severity levels

emergency

System panic or other condition that causes the router to stop functioning

alert

Conditions that require immediate correction, such as a corrupted system database

critical

Critical conditions, such as hard drive errors

error

Error conditions that generally have less serious consequences than errors in the emergency, alert, and critical levels

warning

Conditions that warrant monitoring

notice

Conditions that are not errors but might warrant special handling

info

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:

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:

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:

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-id statement at the [edit access profile name ppp] hierarchy level.

  • For a group identifier, include the l2tp-interface-id statement 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.

Note:

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:

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.

Note:

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:

Configure L2TP redundancy:

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.

Note:

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:

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 information

  • error—Errors only

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

  • ppp

  • l2tp

  • radius

  • udp

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:

Note:

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.