Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

L2TP for Subscriber Access Overview

L2TP for Subscriber Access Overview

The Layer 2 Tunneling Protocol (L2TP) is a client-server protocol that allows the Point-to-Point Protocol (PPP) to be tunneled across a network. L2TP encapsulates Layer 2 packets, such as PPP, for transmission across a network. An L2TP access concentrator (LAC), configured on an access device, receives packets from a remote client and forwards them to an L2TP network server (LNS) on a remote network. The LNS functions as the logical termination point of the PPP session tunneled by the LAC from the remote client. Figure 1 shows a simple L2TP topology.

Figure 1: Typical L2TP TopologyTypical L2TP Topology

L2TP separates the termination of access technologies, such as cable or xDSL, from the termination of PPP and subsequent access to a network. This separation enables public ISPs to outsource their access technologies to competitive local exchange carriers (CLECs). L2TP provides ISPs the capability to supply VPN service; private enterprises can reduce or avoid investment in access technologies for remote workers.

You can configure your router to act as the LAC in PPP pass-through mode in which the LAC receives packets from a remote client and then forwards them at Layer 2 directly to the LNS. The PPP session is terminated on the LNS. This LAC implementation supports only Point-to-Point Protocol over Ethernet (PPPoE) subscribers over dynamic or static logical interfaces. Figure 2 shows the protocol layer stacking for an L2TP pass-through connection.

Figure 2: Protocol Stacking for L2TP Subscribers in Pass-Through ModeProtocol Stacking for L2TP Subscribers in Pass-Through Mode
Note:

On MX Series routers, the LAC and 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

Certain M Series routers support LNS functions on services PICs. For more information about the L2TP implementation on M Series routers, see L2TP Services Configuration Overview.

The LAC dynamically creates tunnels based on AAA authentication parameters and transmits L2TP packets to the LNS by means of the IP/User Datagram Protocol (UDP). Traffic travels in an L2TP session; a tunnel is an aggregation of one or more sessions. You can also provision a domain map that is used by AAA to determine whether to tunnel or terminate the PPPoE subscriber on the LAC. A one-to-one mapping exists between each PPP subscriber tunneled to the LNS and an L2TP session.

When the LNS is an MX Series router, a LAC-facing peer interface on an MPC provides an IP address for the exchange of IP packets between the tunnel endpoints; the Routing Engine maintains the L2TP tunnels. The Packet Forwarding Engine hosts one or more inline services (si) interfaces. These interfaces function like a virtual physical interface and anchor the L2TP sessions on the LNS. The si interface enables L2TP services without requiring a special services PIC. Finally, another interface is used to transmit the subscriber data to and from the Internet.

The characteristics of the tunnel can originate either from a tunnel profile that you configure or from RADIUS tunnel attributes and vendor-specific attributes (VSAs) from the AAA server accessible at the LAC. You can include a tunnel profile in a domain map, which applies the tunnel profile before RADIUS authentication takes place. You can use RADIUS standard attributes and VSAs to override any or all characteristics configured by the tunnel profile in a domain map. Alternatively, RADIUS can itself apply a tunnel profile when the RADIUS Tunnel-Group VSA [26-64] is specified in the RADIUS login.

Note:

L2TP is not supported over GRE tunnels.

The Virtual-Router VSA [26-1] in the subscriber profile on the service provider AAA server (accessible from the LNS) determines the routing instance in which the L2TP session is brought up on the LNS. When this VSA is not present, the subscriber session comes up in the same routing instance as the tunnel, because the AAA server can be accessed only from the routing instance in which the tunnel terminates on the LNS.

This behavior is different than for DHCP and non-tunneled PPPoE subscribers, which come up in the default routing instance in the absence of the Virtual-Router VSA. For L2TP subscribers, you must include this VSA in the subscriber profile when you want the subscriber session to come up in a different routing instance than the tunnel routing instance.

Starting in Junos OS Release 17.4R1, The LNS includes the following RADIUS attributes when it sends an Access-Request message to the RADIUS server:

  • Tunnel-Type (64)

  • Tunnel-Medium-Type (65)

  • Tunnel-Client-Endpoint (66)

  • Tunnel-Server-Endpoint (67)

  • Acct-Tunnel-Connection (68)

  • Tunnel-Assignment-Id (82)

  • Tunnel-Client-Auth-Id (90)

  • Tunnel-Server-Auth-Id (91)

In earlier releases, the LNS includes those attributes only in the accounting records it sends to the RADIUS server. In the Access-Request messages, they can be used to correlate on the RADIUS server the session from the LAC to the LNS.

The LAC supports RADIUS-initiated mirroring, which creates secure policies based on certain RADIUS VSAs, and uses RADIUS attributes to identify a subscriber whose traffic is to be mirrored. (This feature is not supported for an LNS configured on an MX Series router.)

The LAC and the LNS support unified ISSU. When an upgrade is initiated, the LAC completes any L2TP negotiations that are in progress but rejects any new negotiations until the upgrade has completed. No new tunnels or sessions are established during the upgrade. Subscriber logouts are recorded during the upgrade and are completed after the upgrade has completed.

L2TP Terminology

Table 1 describes the basic terms for L2TP.

Table 1: L2TP Terms

Term

Description

AVP

Attribute value pair (AVP)—Combination of a unique attribute—represented by an integer—and a value containing the actual value identified by the attribute.

Call

A connection (or attempted connection) between a remote system and the LAC.

LAC

L2TP access concentrator (LAC)—A node that acts as one side of an L2TP tunnel endpoint and is a peer to the LNS. The LAC sits between an LNS and a remote system and forwards packets to and from each.

LNS

L2TP network server (LNS)—A node that acts as one side of an L2TP tunnel endpoint and is a peer to the LAC. The LNS is the logical termination point of a PPP connection that is being tunneled from the remote system by the LAC.

Peer

In the L2TP context, either the LAC or LNS. The LAC’s peer is an LNS, and vice versa.

Proxy authentication

PPP pre-authentication performed by the LAC on behalf of the LNS. The proxy data is sent by the LAC to the LNS containing attributes such as authentication type, authentication name, and authentication challenge. The LNS responds with the authentication results.

Proxy LCP

Link Control Protocol (LCP) negotiation that is performed by the LAC on behalf of the LNS. The proxy is sent by the LAC to the LNS containing attributes such as the last configuration attributes sent and received from the client.

Remote system

An end system or router attached to a remote access network, which is either the initiator or recipient of a call.

Session

A logical connection created between the LAC and the LNS when an end-to-end PPP connection is established between a remote system and the LNS.

Note:

There is a one-to-one relationship between established L2TP sessions and their associated PPP connections.

Tunnel

A connection between the LAC-LNS pair consisting of a control connection and 0 or more L2TP sessions.

L2TP Implementation

L2TP is implemented on four levels:

  • Source—The local router acting as the LAC.

  • Destination—The remote router acting as the LNS.

  • Tunnel—A direct path between the LAC and the LNS.

  • Session—A PPP connection in a tunnel.

When the router has established destinations, tunnels, and sessions, you can control the L2TP traffic. Making a change to a destination affects all tunnels and sessions to that destination; making a change to a tunnel affects all sessions in that tunnel. For example, closing a destination closes all tunnels and sessions to that destination.

Sequence of Events on the LAC

The router acting as the LAC creates destinations, tunnels, and sessions dynamically, as follows:

  1. The client initiates a PPP connection with the router.

  2. The router and the client exchange Link Control Protocol (LCP) packets. The LAC negotiates on behalf of the LNS; this is known as proxy LCP.

  3. The LAC authenticates the client on behalf of the LNS; this is known as proxy authentication. By using either a local database related to the domain name or RADIUS authentication, the router determines either to terminate or to tunnel the PPP connection.

  4. If the router discovers that it should tunnel the session, it does the following:

    1. Sets up a new destination or selects an existing destination.

    2. Sets up a new tunnel or selects an existing tunnel.

      When a shared secret is configured in either the tunnel profile or the RADIUS attribute Tunnel-Password [69]—depending on which method is used to configure the tunnel—the secret is used to authenticate the tunnel during the establishment phase. The LAC includes the Challenge AVP in the SCCRQ message sent to the LNS. The LNS returns the Challenge Response AVP in the SCCRP message. If the response from the LNS does not match the value expected by the LAC, then tunnel authentication fails and the tunnel is not established.

    3. Opens a new session.

  5. The router forwards the results of the LCP negotiations and authentication to the LNS.

A PPP connection now exists between the client and the LNS.

Note:

The router discards received packets if the size of the variable-length, optional offset pad field in the L2TP header is too large. The router always supports packets that have an offset pad field of up to 16 bytes, and may support larger offset pad fields, depending on other information in the header. This restriction is a possible, although unlikely, cause of excessive discarding of L2TP packets.

Note:

When the LAC terminates a PPP session, it generates a PPP disconnect cause and includes this information in the PPP Disconnect Cause Code (AVP 46) when it sends a Call-Disconnect-Notify (CDN) message to the LNS. The code value is 0, which indicates a global error with no information available.

Sequence of Events on the LNS

A router acting as an LNS might be set up as follows:

  1. The LAC initiates a tunnel with the router acting as the LNS.

  2. The LNS verifies that a tunnel with this LAC is valid: the destination is configured, the hostname and the tunnel password are correct.

  3. The LNS completes the tunnel setup with the LAC.

  4. The LAC sets up a session and initiates a session request to the LNS.

  5. The LNS uses a static interface or creates a dynamic interface to anchor the PPP session.

  6. If they are enabled and present, the LNS accepts the proxy LCP and the proxy authentication data and passes them to PPP.

  7. PPP processes the proxy LCP, if it is present, and, if the proxy LCP is acceptable, places LCP on the LNS in opened state without renegotiation of LCP.

  8. PPP processes the proxy authentication data, if it is present, and passes the data to AAA for verification. (If the data is not present, PPP requests the data from the peer.)

    Note:

    When the proxy LCP is not present or not acceptable, the LNS negotiates LCP with the peer. When LCP renegotiation is enabled on the LNS, the LNS ignores any pre-negotiated LCP parameters and renegotiates both the LCP parameters and PPP authentication with the PPP client.

  9. The LNS passes the authentication results to the peer.

Retransmission of L2TP Control Messages

L2TP peers maintain a queue of control messages that must be sent to the peer device. After the local peer (LAC or LNS) sends a message, it waits for a response from the remote peer. If a response is not received, the local peer retransmits the message. This behavior allows the remote peer more time to respond to the message.

You can control the retransmission behavior in the following two ways:

  • Retransmission count—You can configure how many times an unacknowledged message is retransmitted by the local peer. Increasing the count provides more opportunities for the remote peer to respond, but also increases the amount of control traffic. For tunnels that have been established, include the retransmission-count-established statement at the [edit services l2tp tunnel] hierarchy level. For tunnels that are not yet established, include the retransmission-count-not-established statement.

  • Retransmission interval—You can configure how long the local peer waits for the first response to a control message. If a response is not received within the first timeout interval, then the retransmission timer doubles the interval between each successive retransmission up to a maximum of 16 seconds. Increasing the interval gives the remote peer more time to respond, but also spends more resources on a potentially unavailable peer. Include the minimum-retransmission-interval statement at the [edit services l2tp tunnel] hierarchy level.

The local peer continues retransmitting the control message until one of the following occurs:

  • A response is received within the current waiting period.

  • The maximum retransmission count is reached.

If the maximum count is reached and no response has been received, the tunnel and all its sessions are cleared.

Note:

Reaching the maximum interval of 16 seconds does not halt retransmissions. The local peer continues to wait 16 seconds after each subsequent retransmission.

The following examples describe the retransmission behavior in different circumstances:

  • Example 1—The retransmission count is three and the minimum retransmission interval is 1 second.

    1. The local peer sends a control message.

    2. The local peer waits 1 second, but receives no response.

    3. The local peer retransmits the control message. This is the first retransmission.

    4. The local peer waits 2 seconds, but receives a response before the interval expires.

    5. Retransmission stops because a response is received within the interval.

  • Example 2—The retransmission count is two and the minimum retransmission interval is 8 seconds.

    1. The local peer sends a control message.

    2. The local peer waits 8 seconds, but receives no response.

    3. The local peer retransmits the control message. This is the first retransmission.

    4. The local peer waits 16 seconds, but receives no response.

    5. The local peer retransmits the control message. This is the second retransmission.

    6. The local peer again waits 16 seconds, because the interval cannot increase beyond 16, but receives no response.

    7. Retransmission stops because the maximum retransmission count of two was reached.

    8. The tunnel and all its sessions are cleared.

Configuring Retransmission Attributes for L2TP Control Messages

You can control the retransmission of unacknowledged L2TP control messages by configuring how many times the local peer retransmits the message and how long it waits for a response before retransmission.

L2TP peers maintain a queue of control messages that must be sent to the peer device. After the local peer (LAC or LNS) sends a message, it waits for a response from the remote peer. If a response is not received within the minimum retransmission interval, the local peer retransmits the message and waits for double the retransmission interval. Each time it retransmits the message, the peer doubles how long it waits, up to a maximum of 16 seconds.

If no response is received, the local peer continues to send the message until the number of retransmissions matches the retransmission count. In this case, retransmissions stop and the tunnel and all its sessions are cleared.

Best Practice:

Before you downgrade to a Junos OS Release that does not support these statements, we recommend that you explicitly unconfigure the feature by including the no retransmission-count-established statement and the no retransmission-count-non-established statement at the [edit services l2tp tunnel] hierarchy level.

Best Practice:

During a unified in-service software upgrade (unified ISSU) on an MX Series router configured as the LAC, the LAC does not respond to control messages from the LNS. This can result in dropping LAC L2TP sessions. You can avoid this situation by ensuring that the maximum retransmission count on the LNS is set to 16 or higher.

To set the maximum retransmission count for established tunnels:

  • Configure the count.

To set the maximum retransmission count for non-established tunnels:

  • Configure the count.

To set the minimum interval between retransmissions:

  • Configure the interval.

For example, the following configuration specifies that established tunnels have a maximum retransmission count of three and a minimum retransmission interval of two seconds:

With this sample configuration, the following sequence applies to each control message sent by the LAC or LNS:

  1. The local peer sends the control message and waits for a response from the remote peer.
  2. If the response is not received within the minimum interval of 2 seconds, the local peer retransmits the message. This is the first retransmission.
  3. If the response is not received within 4 seconds, the local peer retransmits the message. This is the second retransmission.
  4. If the response is not received within 8 seconds, the local peer retransmits the message. This is the third and final retransmission, because the maximum count has been reached.
  5. If the response is not received within 16 seconds, the tunnel and all its sessions are cleared.

Enabling Tunnel and Global Counters for SNMP Statistics Collection

By default, SNMP polling is disabled for L2TP statistics. As a consequence, the L2TP tunnel and global counters listed in Table 2 have a default value of zero.

Table 2: SNMP Counters for L2TP Statistics

Counter Name

Type

jnxL2tpTunnelStatsDataTxPkts

Tunnel

jnxL2tpTunnelStatsDataRxPkts

Tunnel

jnxL2tpTunnelStatsDataTxBytes

tunnel

jnxL2tpTunnelStatsDataRxBytes

Tunnel

jnxL2tpStatsPayloadRxOctets

Global

jnxL2tpStatsPayloadRxPkts

Global

jnxL2tpStatsPayloadTxOctets

Global

jnxL2tpStatsPayloadTxPkts

Global

You can enable collection of these statistics by including the enable-snmp-tunnel-statistics statement at the [edit services l2tp] hierarchy level. When enabled, the L2TP process polls for these statistics every 30 seconds for 1000 sessions. The potential age of the statistics increases with the number of subscriber sessions; the data is refreshed more quickly as the number of sessions decreases. For example, with 60,000 sessions, none of these statistics can be more than 30 minutes old.

Best Practice:

The system load can increase when you enable these counters and also use RADIUS interim accounting updates. We recommend you enable these counters when you are using only SNMP statistics.

To enable L2TP statistics collection for SNMP:

  • Enable statistics collection.

Verifying and Managing L2TP for Subscriber Access

Purpose

View or clear information about L2TP tunnels and sessions.

Best Practice:

The all option is not intended to be used as a means to perform a bulk logout of L2TP subscribers. We recommend that you do not use the all option with the clear services l2tp destination, clear services l2tp session, or clear services l2tp tunnel statements in a production environment. Instead of clearing all subscribers at once, consider clearing subscribers in smaller group, based on interface, tunnel, or destination end point.

Action

  • To display a summary of L2TP tunnels, sessions, errors, and control and data packets:

  • To display the L2TP destinations:

  • To clear all L2TP destinations:

  • To clear statistics for all L2TP tunnels belonging to a destination, tunnels belonging to a specified local-gateway address, and tunnels belonging to a specified peer-gateway address:

  • To display the L2TP sessions:

  • To clear all L2TP sessions, the session with a specified local session ID, or sessions associated with the local gateway specified by an IP address or name:

  • To clear statistics for all L2TP sessions, the session with a specified local session ID, or sessions associated with the local gateway specified by an IP address or name:

  • To display the L2TP tunnels:

  • To clear all L2TP tunnels, the tunnel with a specified local tunnel ID, or tunnels associated with the local gateway specified by an IP address or name:

  • To clear statistics for all L2TP tunnels, the tunnel with a specified local tunnel ID, or tunnels associated with the local gateway specified by an IP address or name:

Related Documentation