Layer 2 Tunneling Protocol (L2TP)

This chapter provides information about using L2TP, including theory, supported features and configuration process overview.

Note: The information in this section applies only to the 7750 SR.


  • Tunnel spec

    Describes the requirements for a tunnel and is defined as a set of parameters that are used in tunnel setup and selection process. The tunnel-spec is defined in the CLI or can be supplied through RADIUS.

  • Tunnel (instance)

    A run-time object with a unique ID terminating at a specific peer. Any change in the tunnel spec after the tunnel has been created has no bearing on the tunnel itself. The list of tunnels can be obtained using the show router l2tp tunnel command.

  • Peer

    A run-time object that is defined by an ip-address/port combination. Multiple tunnels can be terminated on the same peer. The list of peers can be obtained using the show router l2tp peer command.

L2TP overview

LAC DF bit

The Layer 2 access concentrator (LAC) DF bit is configurable, but by default, it sends all L2TP packets with the DF bit set to 1. Clearing the DF bit allows downstream routers to fragment the L2TP packets. The LAC itself does not fragment L2TP packets. L2TP packets that have a larger MTU size than what the LAC egress ports allows are dropped. The DF bit can also be configured through RADIUS attribute Alc-Tunnel-DF-bit.

Handling L2TP tunnel/session initialization failures

L2TP tunnel/session initialization failover mechanisms on LAC

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: 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 +=,
     Tunnel-Server-Endpoint:1 +=,
       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 +=,
        Tunnel-Server-Endpoint:2 +=,
        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 +=,
        Tunnel-Server-Endpoint:3 +=,
        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 +=,
        Tunnel-Server-Endpoint:4 +=,
        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.

Peer denylist

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.

Tunnel denylists

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.

Tunnel timeout because of peer IP address change

When the peer address is changed mid-session (for example, from configured IP@ to the new IP@, and then subsequently the tunnel times-out, the new peer would be placed in the denylist by default. The tunnel itself would not be placed in the denylist because it is originally tied to a different peer address that it is not in the denylist. As such it would be eligible for selection the next time a new session request for it arrives. To block selection of this failed tunnel, optionally (by configuration) force it into the denylist.

This behavior can be enabled with the following CLI:

configure router l2tp
configure service vprn <id> l2tp
        add-tunnel on <reason> [<reason>...(up to 7 max)]
<reason> : cdn-err-code|cdn-inv-dest|cdn-tmp-no-facilities|cdn-perm-no-

Tunnel selection mechanism

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

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.

Controlling the size of the denylist

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

Displaying the content of a denylist

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
Peer IP:
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
977207296                    14911     0         closed             0
  base_lac_base_lns                                                 1
No. of tunnels: 1

show router l2tp tunnel detail
L2TP Tunnel Status
Connection ID: 831782912
State        : closedByPeer
IP           :
Peer IP      :
Tx dst-IP    :
Rx src-IP    :
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

Generating a trap when the denylist is full

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

Premature removal of denylisted entries

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.

Manual purging of entities within the denylist

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-
clear router <id> l2tp group <tunnel-group-name> [tunnel <tunnel-name>] tunnel-
clear router <id> l2tp tunnel <connection-id> tunnel-selection-blacklist

CDN result code overwrite

When the number of L2TP sessions reaches the configured maximum value, the LNS sends an out-of-resource Result Code (4 or 5) in a CDN (Call-Disconnect-Notify) message to the LAC. This would trigger the LAC to fail over to another LNS that has the resources available. Similarly, when the tunnel is not usable because of the invalid destination CDN error, the Result-Code 6 is sent from the LNS.

Certain third-party LAC implementations trigger tunnel failover only when they receive Result Code 2 in CDN messages (and not 4,5 or 6). To support those scenarios, the LNS in the 7750 SR can overwrite result Codes 4, 5 and 6 with result Code 2 just before they are sent to the LAC. Result Codes can be overwritten only during the L2TP session initialization phase. These codes have the following meanings and are described in RFC 2661, 4.4.2:

  • 2

    Call disconnected for the reason indicated in error code

  • 4

    Call failed because of the lack of appropriate facilities being available (temporary condition)

  • 5

    Call failed because of the lack of appropriate facilities being available (permanent condition)

  • 6

    Invalid Destination

This functionality is enabled on LNS with the following CLI hierarchy:

configure router l2tp
configure service vprn <id> l2tp
   replace-result-code {cdn-tmp-no-facilities | cdn-prem-no-facilities | cdn-inv-
    no replace-result-code

LNS proxy

LNS offers a proxy LCP (with the proxy-lcp command) function where LCP-related information is cached temporarily in the LNS during the ICCN phase where L2TP control messages are exchanged between the LAC and LNS. The LNS can then use the cached information to bypass the LCP negotiation and immediately start the authentication state with the client. Furthermore, proxy authentication (using the proxy-authentication command) can also be enabled on the LNS to bypass authentication and the client can immediately start the IPCP negotiation phase. If the proxy LCP information conflicts from the LNS configuration, then the LNS forces the client to re-start LCP negotiation. LCP negotiation is not restarted in the proxy LCP mode when:

  • MRU is missing in the LastTxLcpConfReq AVP

  • The magic number is missing in LastTxLcpConfReq AVP

  • Async-Control-Character-Map (ACCM) with value = 0x00000000 is present in LastTxLcpConfReq and LastRxLcpConfReq AVP's

  • Address-and-Control-Field-Compression (ACFC) is present in LastTxLcpConfReq and LastRxLcpConfReq. Note that PPP frames with and without address and control field (0xFF03) in the PPP header are accepted. LCP frames without 0xFF03 are also accepted as valid frames.

Also, proxy-authentication that fails then forces the client to re-start the LCP negotiation again.


Layer 2 Tunneling Protocol (L2TP) allows for PPP sessions to be carried over an IP network.

Each L2TP session transports PPP frames, irrespective of link-layer encapsulation, allows the LNS to terminate PPP sessions that were PPPoE. L2TP is carried over IPv4 packets in UDP datagrams (default port 1701).

If session data is not reliably delivered, that is, if there is a packet loss, there is no retransmission, a sequence numbers is used within each L2TP session to identify packet loss and re-ordering.

L2TP consists of the following concepts:

  • L2TP tunnels — L2TP tunnel is a connection between one LAC (L2TP Access Concentrator) and one LNS (L2TP network server) that share a common control channel.

  • L2TP sessions — Within each L2TP tunnel, there exists one or more L2TP sessions (one PPP session corresponds to exactly one L2TP session)

L2TP tunnels provide an IP transport for PPP frames between LAC and LNS. In some existing networks, BGP/MPLS VPNs (VPRN in SR OS) are used to contain the L2TP traffic (and the routes associated with the LAC and LNS) into a dedicated routing instance.

Like the LNS implementation, L2TP LAC in a VPRN allows L2TP control and data traffic to be sourced from and received by any valid IP interface within the VPRN (including loopback and interface addresses). L2TP frames may ingress a network port (with up to five MPLS tags) or access ports with SAPs associated with the VPRN IP interfaces.

Non-hitless multi-chassis LAC resiliency

In dual-homed PPPoEv4/v6 wholesale/retail environment over L2TP, the subscriber-hosts are synchronized by the Multi-Chassis Synchronization (MCS) protocol. The failover detection mechanism can be implemented by SRRP or Layer 3 MC-LAG with SRRP. When an interface or an entire node fails, the new multi-chassis active BNG (SRRP master state) sends PADT to all sessions that were moved over from the failed node.

In the event of an interface-only failure, CDN is sent toward the LNS to terminate sessions on the LNS.

The PPPoE sessions are reestablished on the new multi-chassis active BNG, but because PADT was sent to clients the recovery time is faster (no need to wait for PPPoE session timeout). On the network side (toward the LNS) an existing tunnel toward the LNS can be used to re-establish the sessions or if none exists, a new tunnel is established. Then there is no need for a redundant interface.


The L2TP tunnel carrying the sessions must always be terminated on the multi-chassis active LAC (SRRP master state).

In the event of nodal failure, the sessions within the old tunnel on the LAC times out (CDN cannot be sent from the new multi-chassis active LAC because there is no tunnel state preserved across redundant LAC nodes). During the time-out period, the LNS must maintain double the amount of failed sessions (stale ones plus the new ones). This model is shown in Non-hitless interface/node protection on the LAC .

Figure 1. Non-hitless interface/node protection on the LAC

Per-ISP egress L2TP DSCP reclassification

Wholesale providers can deliver Internet access to directly connected PPP users through third party ISPs. This involves the users connecting to an L2TP Access Concentrator (LAC) with their traffic being tunneled to and from an L2TP Network Server (LNS) in their ISP.

If there is a requirement to support per-ISP (and per-subscriber host) QOS control for downstream traffic on the LAC toward the users based on the DSCP marking in the L2TP header, the use-ingress-l2tp-dscp command must be configured within the sla-profile selected for the users. An example topology is shown in ISP Internet access through wholesale provider.

Figure 2. ISP Internet access through wholesale provider

The downstream traffic arrives at the LAC with:

  • An MPLS header (because of the VRF encapsulation). This contains EXP bits which are set based on the wholesale provider’s QOS scheme.

  • An L2TP header (because of the L2TP tunnel to the ISP). This contains DSCP bits in its IP header which are set by the originating ISP.

  • A user IP packet header. This contains DSCP bits which could be set by the ISP or by the originating Internet application.

The network ingress on the LAC would normally use the MPLS EXP bits for traffic QoS classification, however, this matches the wholesale provider’s QoS scheme.

It is possible to apply the ler-use-dscp parameter at the LAC network ingress to classify based on the L2TP header DSCP, but this would require the QoS schemes used by all ISPs, and the wholesale provider, to have a consistent interpretation of the DSCP bits.

If the standard egress IP reclassification is used, the QOS would be dependent on the DSCP in the user packet.

Configuring the use-ingress-l2tp-dscp parameter in the sla-profile of the ISP1 and ISP2 users forces the egress QoS control to be based on the DSCP from the L2TP header received on the LAC (which is set by ISP1/ISP2). This provides per-ISP (and per-subscriber host) QoS control for downstream traffic on the LAC toward the users.

Traffic steering on L2TP LAC

Traffic steering on L2TP LAC allows wholesale providers to forward L2TP-encapsulated packets going to and coming from LNS to Value-Added Services (VAS).

Traffic steering on L2TP LAC consists of the following components:

  • A steering profile contains steering configuration (Access/VAS routers and next hop) information that is applied to the subscriber host for the PPPoE/L2TP session.

  • For steered traffic all PPP packets to and from the PPPoE host that have a steering profile attached are forwarded through VAS. PPP packets include LCP/NCP control packets, LCP echo and echo reply, and user data packets.

  • Non-steered traffic consists of packets for the L2TP control channel and PPP packets of the subscriber host that do not have a steering profile

  • For the base router (can also be a VPRN), the routing instance terminates subscriber host and L2TP tunnels or sessions to LNS

  • For an access VAS router, the routing instance forwards upstream (to LNS) steered traffic to VAS and receives downstream (to subscriber) steered traffic from VAS.

    An access VAS router must be a VPRN. A base routing instance cannot be specified as an access VAS router.

  • For a network VAS router (optional), the routing instance receives upstream (to LNS) steered traffic from VAS and forwards downstream (to subscriber) steered traffic to VAS.

    The creation of a network VAS router is not mandatory and a base router can also perform the same function.

  • In a network VAS next hop, the next-hop IP address to reach VAS from the network VAS Router or Base Router for downstream traffic. This address must be specified in the steering profile.

Traffic steering on L2TP LAC shows traffic steering on L2TP LAC.

Figure 3. Traffic steering on L2TP LAC

Steering activation and deactivation

Traffic steering can be activated by the LUDB and RADIUS Access-Accept/CoA messages that include the Alc-Steering-Profile VSA.

Steering can be deactivated by a RADIUS CoA that includes an Alc-Remove-Override VSA to remove Alc-Steering-Profile generated by an AAA server or BNG node itself using a CLI command.

The following CLI example shows the activation of a steering profile:

tools perform subscriber-mgmt coa alc-subscr-id subscriber-
1 attr evs,241,6527,25=”steering-profile-1”

The following CLI example shows the deactivation of a steering profile:

tools perform subscriber-mgmt coa alc-subscr-id subscriber-
1 attr 6527,238="deactivate 241.26.6527.25"

Steering states

Each PPPoE/L2TP session has an operational state of traffic steering that prevents a traffic black hole caused by problems such as an incorrectly configured network or a temporary VAS outage.

The steering states are:

  • Non-steered

    a steering profile is not applied to the session and traffic steering is not performed

  • Steered

    a steering profile is applied to the session and traffic steering is performed

  • Steering-failure a steering profile is applied to the session but traffic steering is not performed, possibly because of a misconfiguration of the steering profile, L2TP, or IP routing

As the conditions to perform traffic steering are met or lost, the steering state transitions in and out of steering failure.

Configuring traffic steering on L2TP LAC

The following steps show the commands used to configure traffic steering on L2TP LAC.

  1. Enable L2TP on a base router.

                  no shutdown
  2. Create VAS routers and interfaces.

         vprn 100 customer 1 create
             description ‟VAS router for access”
             route-distinguisher 65001:100
             vrf-target target:65001:100
                 no shutdown
             interface ‟L2TP LAC endpoint”
             interface ‟Access interface to VAS”
                 vas-if-type to-from-access
             static-route-entry next-hop
         vprn 200 customer 1 create
             description ‟VAS router for network”
             route-distinguisher 65001:200
             vrf-target target:65001:200
             interface ‟Network interface to VAS”
             static-route-entry next-hop

    The L2TP endpoint IP addresses used by the base router and the access router must be the same.

    The VAS-facing interface on the access router must be configured as vas-if-type to-from-access to avoid a traffic loop between BNG and VAS.

  3. Configure the steering profile.

             steering-profile ‟SP1” create
                 access router 100
                 network next-hop router 200
  4. (Optional) Configure the LUDB host entry for the steered L2TP/PPPoE session.

             local-user-db "LAC-steering"
                     match-list sap-id
                     host "lag-1:1" create
                             sap-id "lag-1:1"
                         auth-policy "AUTH1"
                         pre-auth-policy "PRE1"
                         steering-profile ‟SP1”
                         identification-strings 254 create
                             sla-profile-string "SLA1"
                             sub-profile-string "SUB1"
                         no shutdown

L2TP tunnel RADIUS accounting

L2TP tunnel accounting shows an L2TP tunnel RADIUS accounting configuration.

Figure 4. L2TP tunnel accounting

When L2TP tunnel accounting is enabled, except for host or sla-profile-based accounting packets and attributes, the following are additional accounting packets and attributes:

  • Accounting packets:

    • tunnel-start/stop/reject

    • tunnel-link-start/stop/reject

    There are no interim updates for L2TP tunnel/session accounting.

  • RADIUS accounting attributes:

    • Tunnel-Assignment-Id (LAC only)

    • Acct-Tunnel-Connection

    • Acct-Tunnel-Packets-Lost

These attributes were added into current account-start/stop/interim-update packets (host accounting/sla-profile accounting)

Tunnel level accounting and session level accounting can be enabled or disabled independently.

New accounting packets and related RADIUS attribute list are described in L2TP tunnel accounting behavior .

Some considerations of RADIUS attributes are described in RADIUS attributes value considerations.

Accounting packets list

L2TP tunnel accounting behavior describes L2TP tunnel accounting behavior along with some key RADIUS attributes (apply for both LAC and LNS):

Table 1. L2TP tunnel accounting behavior
Act-packet When Key attributes


A new L2TP tunnel is created











A new L2TP tunnel creation failed











An established L2TP tunnel is removed





















An L2TP session is created


Acct-Session-Id — This is the same as Acct-Session-id in access-request of host auth


Service-Type — Framed









Acct-Tunnel-Connection — See RADIUS attributes value considerations


A new L2TP session creation is failed

Acct-Session-Id — Should be as same as Acct-Session-id in access-request of host auth











An established L2TP session is removed


Acct-Session-Id — Should be as same as Acct-Session-id in access-request of host auth


Service-Type — Framed




















  • Errors occur if there are multiple hosts sharing the same sla-profile instance and then these hosts go to different tunnel.

  • 7750 SRs have an internal limitation of 500 pps for accounting messages. This feature shares the same limitation.

RADIUS attributes value considerations

  • The value of Acct-Tunnel-Connection uniquely identifies an L2TP session. To match LAC and LNS accounting records, the value of Acct-Tunnel-Connection is determined by a method shared by LAC and LNS. This means for a specific L2TP session, Acct-Tunnel-Connection from the LAC and LNS are the same.

  • Current ESM statistics are used in tunnel link and tunnel level accounting. This applies to the standard attribute and the 7750 SR’s own VSA.

  • Tunnel level accounting statistics must aggregate all session statistics that belong to the tunnel.


    There could be sessions come and go before tunnel is down, so system need to remember the stats of every session that has been created within the tunnel.

    This applies for both standard attribute and 7750 SR’s own VSA.

  • The value of Acct-Tunnel-Packets-Lost is the aggregation of all discarded packets on both ingress and egress.

  • L2TP tunnel accounting on LAC can be enabled from RADIUS using the Alc-Tunnel-Acct-Policy VSA. This attribute overrides the locally configured L2TP RADIUS accounting policy.

  • See 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for attributes that are applicable in RADIUS L2TP tunnel accounting.

MLPPP on the LNS side

With MLPPP, the counter on LNS side is only available for the bundle, not for each link, so the SR OS’s behavior is:

  • For each new link session system sends a tunnel-link-start.

  • For each link session that is deleted system sends a tunnel-link-stop.

  • For all link sessions except the last one system reports 0 for all counters.

  • For the last link session, system reports the actual counters for the bundle.

LNS reassembly

LNS reassembly is supported in the BB-ISA. Fragments are collected and reassembled. After the entire L2TP packet is reassembled, the packet is either decapsulated or sent to the CPM without change.

The delivery of the L2TP packets to the BB-ISA depends on the specific fields in the L2TP header. The forwarding decision on the ingress LNS side in the upstream direction (LAC->LNS) is based on the tunnel-id or session-id combination and the T-bit (message type bit – control or data) in L2TP header.

Control type messages are delivered directly to the CPM. CPM performs L2TP decapsulation and processes the message (tunnel or session setup/teardown related messages or tunnel hellos). The CPM provides forwarding information to the forwarding plane (ingress/egress IOM and the carrier IOM) and to the BB-ISA (tunnel-src plus tunnel-id/session-id plus generated-mac-addr and SAP).

Data type messages are delivered directly to the BB-ISA. The BB-ISA decapsulates the L2TP packets and forwards them to the carrier IOM as a quasi-PPPoE frame (ESM forwarding module).

Because the LAC fragments the packets in the upstream direction, the L2TP header is preserved only in the first fragment. Therefore, the crucial forwarding information needed by LNS is lost in all consecutive fragments. If a fragments ends up in the wrong BB-ISA with no reassembly context for the fragment, the fragment is dropped.

Similarly, the information whether to forward the fragment to the BB-ISA (data packet) or the CPM (control packet) is lost.

To support LSN reassemble, the following configuration limitations are imposed:

  • Only one pair of active/standby BB-ISAs are supported. This way all fragments are forwarded to the same active BB-ISA that maintains all reassembly contexts for all fragments.

  • All fragments, regardless of the packet type, are forwarded to the active BB-ISA. After the L2TP packet is reassembled, it is determined whether the packet is:

    • A data packet — The packet is decapsulated and a quasi PPPoE packet is forwarded to the carrier IOM (ESM function).

    • A control packet — The packet is not decapsulated but instead it is forwarded as L2TP packet to the CPM.

The lns-reassembly commands that inform the ingress forwarding plane that all L2TP packets should be sent to the BB-ISA are configured in the config>router>l2tp and config>service>vprn>l2tp contexts.

LNS subscriber policers

Policer support

LNS subscribers’ SLA profiles support policers. In the egress direction, HQoS manageable policers are also supported.

The following QoS features are supported for LNS subscribers:

  • ingress policer with h-pol

  • egress policer with h-pol

  • policer-hqos-manageable

  • policer-output-queue

  • egress queuing, policer to local queue

  • egress queuing, bypass policers

  • egress queuing, flow based