Layer 2 Tunneling Protocol (L2TP)

In deployment scenarios with multiple LNS nodes, a list of those LNS nodes can be presented to the LAC during the L2TP session instantiation process (either through CLI or RADIUS). An example of this would be a RADIUS Accept message with a list of tunnel peers:

tunnel.com Auth-Type := Local, Password == "tunnel1"
Tunnel-Type:1 += L2TP,
       Tunnel-Medium-Type:1 += IP,
       Tunnel-Client-Auth-Id:1 += lns_tun,
       Tunnel-Assignment-Id:1 += 1,
     Tunnel-Client-Endpoint:1 += 10.0.0.1,
     Tunnel-Server-Endpoint:1 += 10.0.0.2,
       Tunnel-Password:1 += TUNNELPASS,

         Tunnel-Type:2 += L2TP,
     Tunnel-Medium-Type:2 += IP,
         Tunnel-Client-Auth-Id:2 += lns_tun,
     Tunnel-Assignment-Id:2 += 2, 
        Tunnel-Client-Endpoint:2 += 10.0.0.1,
        Tunnel-Server-Endpoint:2 += 10.0.0.3,
        Tunnel-Password:2 += TUNNELPASS,

               Tunnel-Type:3 += L2TP,
        Tunnel-Medium-Type:3 += IP,
        Tunnel-Client-Auth-Id:3 += lns_tun,
        Tunnel-Assignment-Id:3 += 3, 
        Tunnel-Client-Endpoint:3 += 10.0.0.1,
        Tunnel-Server-Endpoint:3 += 10.0.0.4,
        Tunnel-Password:3 += TUNNELPASS,
               Tunnel-Type:4 += L2TP,

        Tunnel-Medium-Type:4 += IP,
        Tunnel-Client-Auth-Id:4 += lns_tun,
        Tunnel-Assignment-Id:4 += 4, 
        Tunnel-Client-Endpoint:4 += 10.0.0.1,
        Tunnel-Server-Endpoint:4 += 10.0.0.5,
        Tunnel-Password:4 += TUNNELPASS

If the tunnel or the session establishment attempt fails for any reason, a search for additional operational facilities (tunnels or peers) is made to complete the establishment of the tunnel or session that failed in the previous attempt. Sometimes it is required to go beyond this automatic search for the new facilities and place the tunnel or peer in question into a denylist. A tunnel timeout always forces the corresponding peer and the tunnel into the denylist. In addition, a tunnel can be forced into the denylist by specific explicit error codes (CDN, and Stop-CCN) during the tunnel or session initialization phase. A peer is never forced on a denylist because of explicit Result-Code sent by LNS.

Denylisted peers and tunnels are not eligible to serve new incoming L2TP session until they are removed from the denylist. The exception is when all tunnel specs evaluate into a denylisted item. Then, a denylist item (tunnel) is tried.

A peer is always placed into the denylist if:

• An attempt to establish a new tunnel fails because of a time out (SCCRQ and SCCCN timeouts)

• The timeout occurs on any control packet within an already established tunnel. All sessions on such tunnel are terminated (PADT is sent toward the clients, StopCCN is sent toward the LNS). Other tunnels that are terminated on the same peer times out on their own (if the peer is indeed non-operational), for example, the 7750 SR not explicitly tear them down based on the timeout of a single tunnel. The timeout of an existing tunnel is caused by the lack of acknowledgments to be transmitted control packets (ICRQ, ICCN, CDN, Hello).

A tunnel timeout occurs if an acknowledgment is not received after max-retries-established (on an established tunnel) or max-retries-not-established (for the tunnel in the process of being established) retries.

Although there is no configuration option that would control whether a peer can or cannot be denylisted (it is always denylisted on tunnel timeout), the amount of time that a peer remains in the denylist is configurable within the tunnel-selection-blacklist CLI node.

A tunnel spec (that evaluates into a tunnel) is temporary unusable if that corresponding peer or the tunnel is denylisted. The following events trigger placement of the tunnel into the denylist:

1. Explicit termination of the L2TP session that is in the process of being established within this tunnel. The following CDN Result Codes places a tunnel to a denylist (text in parenthesis are CLI keywords that enable specific Result Codes as triggers and [rx,tx] is direction of the messages from the LAC perspective):

   • 02 DisconnectedSeeErrorCode, rx (cdn-err-code)

   • 04 TempMissingFacilities, rx (cdn-tmp-no-facilities)

     Transmit CDN when no session can be allocated

     Audit not yet complete

   • 05 PermanentMissingFacilities, rx (cdn-perm-no-facilities)

     No result code available

   • 06 InvalidDestination, rx (cdn-inv-dest)

     Tunnel is not usable (for example, lns-group is not configured on LNS)

   • 10 NotEstablishedInAllotedTime, tx (tx-cdn-not-established-in-time)

2. Explicit termination of the L2TP tunnel in the process of establishment by Stop-CCN Result-Codes:

   • (1) General request to clear control connection, rx (stop-ccn-other)

   • (2) General error, rx (stop-ccn-err-code)

   • (4) Requester is not authorized to establish a control channel, rx, tx (stop-ccn-other)

   • (5) Protocol version not supported, rx, tx (stop-ccn-other)

   • (6) Requester is being shut down, rx (stop-ccn-other)

Error messages identified by the received Result-Codes can be interpreted as the inability of the LNS to accept additional L2TP sessions within the tunnel (for example because of resource depletion) or to accept additional new tunnels.

The following statements further describe behavior related to the placement of tunnels into the denylist:

• A new L2TP session establishment attempt does not trigger on the tunnel that is in the denylist. Instead, another tunnel is searched according to the configured preference model.

• The tunnel or session initialization failure always triggers the selection mechanism for another tunnel. However, it is possible to control through configuration whether to denylist or not the tunnel for which the L2TP initialization process failed because of specific Result Codes in CDN or Stop CCN messages.

• After the L2TP tunnel or session is established, no events other than the timeout can force the tunnel (and the peer) into the denylist. In other words, a tunnel Stop or Call disconnect message for a stable tunnel or session does not force the tunnel into the denylist.

• Existing sessions within the L2TP tunnel are not purposefully terminated if that the tunnel is forced into the denylist because of an explicit reply from LNS indicating the tunnel or session initialization failure. In other words, although the L2TP tunnel may be denylisted and therefore prevented from serving new L2TP sessions, the existing L2TP session over this tunnel is not affected.

• A peer is not forced into the denylist if the explicit failure response from that peer. Only tunnels are denylisted in that case, if the configuration trigger is enabled. Peers are denylisted only based on timeouts and not explicit responses.

When the end-point is not in the routing table (unreachable through routing), the end-point is marked as permanently unavailable (removed from the L2TP process). Such end-point is never denylisted.

After the L2TP tunnel failover is triggered (timeout or specific L2TP session or tunnel setup error message), a new tunnel spec in the list of available tunnel specs are selected. This tunnel selection mechanism can be controlled with CLI so that the new tunnel-spec is selected from the next preference level. Alternatively, the tunnel selection mechanism can be set to a mode where all the possibilities within the same preference are exhausted, tunnel specs on a higher preference level are tried.

configure router l2tp
configure service vprn <id> l2tp
    next-attempt same-preference-level | next-preference-level

When all tunnels on a specific preference levels are denylisted, then the behavior depends on the configuration option as per the following:

• next-attempt = next-preference

  Only one tunnel spec from the current preference level is tried before switching to the next preference level.

• next-attempt = same-preference

  All tunnel specs are tried before switching to the next preference level.

Tunnel probing refers to the mechanism where the denylisted tunnel or an end-point can be selected to serve only a single L2TP session initialization request. Only if this single L2TP session is successfully established over the selected tunnel, the tunnel can be removed from the denylist and consequently can serve new L2TP sessions. The tunnel is eligible for probing after its preconfigured time in the denylist has expired.

This behavior ensures that the new session initialization requests are not buffered while waiting for the tunnel to transition into operational state. Buffering would incur session setup delay and in the worst case it would cause session timeout if the L2TP tunnel cannot be established.

Without tunnel probing enabled, tunnels are automatically removed from the denylist upon the expiry of the preconfigured timer. New consecutive L2TP session initialization requests for such tunnels are always buffered.

The size of the denylist and the time that an item remains ineligible for selection within the denylist, is configurable.

configure router l2tp
configure service vprn <id> l2tp tunnel-selection-blacklist
        max-time    1..60 (minutes) 
        max-list-length unlimited | 1..65535

The content of a denylist along with the remaining time that each entity is confined to the denylist can be displayed with the following command:

show router <id> l2tp peer blacklisted|not-blacklisted|selectable 

The following displays denylist information.

show router l2tp peer 10.100.0.2
===============================================================================
Peer IP: 10.100.0.2
===============================================================================
Roles capab/actual: LAC LNS /LAC  -     Draining          : false
Tunnels           : 1                   Tunnels Active    : 0
Sessions          : 1                   Sessions Active   : 0
Reachability      : blacklisted         Time Unreachable  : 01/31/2013 08:55:06
Time Blacklisted  : 01/31/2013 08:55:06 Remaining (s)     : 34
===============================================================================
Conn ID                      Loc-Tu-ID Rem-Tu-ID State              Ses Active
  Group                                                             Ses Total
    Assignment
-------------------------------------------------------------------------------
977207296                    14911     0         closed             0
  base_lac_base_lns                                                 1
    t1
-------------------------------------------------------------------------------
No. of tunnels: 1
===============================================================================


show router l2tp tunnel detail
===============================================================================
L2TP Tunnel Status
===============================================================================
Connection ID: 831782912
State        : closedByPeer
IP           : 10.0.0.1
Peer IP      : 10.100.0.2
Tx dst-IP    : 10.100.0.2
Rx src-IP    : 10.100.0.2
Name         : lac
Remote Name  :
Assignment ID: t1
Group Name   : base_lac_base_lns
Acct. Policy : l2tp-base
Error Message: N/A
                                        Remote Conn ID    : 4294901760
Tunnel ID         : 12692               Remote Tunnel ID  : 65535
UDP Port          : 1701                Remote UDP Port   : 1701
Preference        : 50                  Receive Window    : 64
Hello Interval (s): 300
Idle TO (s)       : 5                   Destruct TO (s)   : 60
Max Retr Estab    : 5                   Max Retr Not Estab: 5
Session Limit     : 32767               AVP Hiding        : sensitive
Transport Type    : udpIp               Challenge         : never
Time Started      : 01/31/2013 08:56:58 Time Idle         : 01/31/2013 08:56:58
Time Established  : N/A                 Time Closed       : 01/31/2013 08:56:58
Stop CCN Result   : reqShutDown         General Error     : noError
Blacklist-state   : blacklisted
Blacklist Time    : 01/31/2013 08:56:58 Remaining (s)     : 49
-------------------------------------------------------------------------------
No. of tunnels: 1
===============================================================================

A log is generated when the denylist reaches its max limit of items. The log event is tmnxL2tpTunnelSelectionBlacklistFull.

When the total number of supported tunnels and peers in a denylist and when the LAC, in general, has reached its maximum, on the new session initialization request, the oldest tunnel entry in the denylist is removed from the denylist regardless if the denylist max-time has expired.

The items can be manually purged from the denylist using the following commands.

clear router <id> l2tp tunnel-selection-blacklist
clear router <id> l2tp peer <ip-address> [udp-port <port>] tunnel-selection-
blacklist
clear router <id> l2tp group <tunnel-group-name> [tunnel <tunnel-name>] tunnel-
selection-blacklist
clear router <id> l2tp tunnel <connection-id> tunnel-selection-blacklist