L2TP Network Server
This chapter provides information about L2TP network servers (LNS).
Topics in this chapter include:
Applicability
Initially, this chapter was initially written based on SR OS Release 11.0.R7, but the CLI in this edition is based on SR OS Release 16.0.R7.
Overview
The Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol commonly used to transport PPP sessions from an initiator known as an L2TP Access Concentrator (LAC) to an L2TP Network Server (LNS). L2TP is typically used for wholesaling residential broadband services. In this scenario, the LAC resides in the wholesaler’s network and has a Layer-2 connection to an access concentrator such as a DSLAM. The LAC responds during the discovery phase (if PPPoE is used) and during PPP Link Control Protocol (LCP) negotiation. The LAC also performs an initial authentication of the subscriber. A successful authentication, typically from RADIUS, indicates to the LAC that PPP frames from this subscriber should be tunneled to an LNS at the indicated IP address. The LAC then tunnels the PPP frames from this subscriber over an L2TP tunnel to the LNS, where the PPP session is actually terminated. In other words, PPP sessions require L2TP tunnels for the sessions to get carried over.
L2TP uses two types of messages; control messages and data messages. Control messages are used in the establishment, maintenance, and tearing down of tunnels and sessions. In order to provide extensibility and maximize interoperability, the payloads of control messages are encoded using Attribute Value Pairs (AVPs), some of which are applicable to all control messages, and some of which are specific to particular control messages. The L2TP header contains sequence number fields that must be present in control messages to allow for a reliable L2TP control channel that guarantees delivery. Data messages are used to encapsulate PPP frames being carried over the tunnel. Data messages are not retransmitted if packet loss occurs.
L2TP has a common fixed header format for both control and data messages, and a Type (T) bit in the header is used to indicate whether the packet is a control (1) or data (0) message. The L2TP packet is then carried in a transport protocol, and although the specifications allow L2TP to be directly encapsulated over Frame Relay, ATM, and UDP/IP, the latter is used almost exclusively.
The objective of this chapter is to provide a generic overview of how to configure the 7750 SR to support the LNS and LTS (L2TP Tunnel Switching) functions.
Example Topology
The example topology used through this chapter is shown in Example Topology. Both the LAC and the LNS participate in IS-IS and LDP, together with PE-1. All three devices form part of AS 64496 and peer using iBGP for the VPN-IPv4 address family. None of these protocols is mandatory for supporting LNS functionality; L2TP packets can ingress the system over any network interface as native IP or encapsulated as IP in MPLS, or through an IES/VPRN IP interface (SAP) as native IP. The MPLS data-plane within the example topology is chosen purely because of its simplicity and flexibility. Tester T1 simulates a DSLAM and one or more PPP clients, and is connected directly to the LAC. Although the LAC in this topology is a 7750 SR router, the configuration requirements of that device are beyond the scope of this example. Tester T2 provides a traffic source/sink capability and is connected directly to PE-1.
Hardware Configuration
To support LNS (and LTS) functionality, at least one MS-ISA card is required, which must be configured as MDA type isa-bb, and must be housed in the carrier IOM. The MS-ISA performs L2TP data-plane encapsulation and de-capsulation, whereas the subscriber processing (Enhanced Subscriber Management or ESM) for PPP sessions is implemented within the carrier IOM.
configure
card 1
card-type iom3-xp
mda 1
mda-type m4-10gb-xp-xfp
no shutdown
exit
mda 2
mda-type isa-bb
no shutdown
exit
no shutdown
exit
exit
The MS-ISA is then configured to become a member of an lns-group. Up to six MS-ISAs can be configured to belong to one or more lns-groups. When two or more MS-ISAs belong to the same lns-group, by default PPP sessions are load-balanced over those MS-ISAs on a per-session basis.
configure
isa
lns-group 1 create
mda 1/2
no shutdown
exit
exit
exit
Configuration
ESM Base Configuration
For completeness, the following outputs contain the base ESM configuration that is applied to subscribers instantiated at the LNS throughout this chapter. Deviations from these base parameters are mentioned explicitly.
The SLA-Profile and Sub-Profile configurations have a minimal set of parameters. The SLA-Profile uses the default ingress/egress QoS policy of 1, while the no qos-marking-from-sap command ensures that any subsequent marking is inherited from the egress QoS policy referenced in the SLA-profile, and not taken from the egress SAP. In order to do on-line accounting through RADIUS, the Sub-Profile also calls the relevant RADIUS accounting policy. Finally, the sub-ident-policy is configured with use-direct-map-as-default for the sub-profile-map and sla-profile-map, which means that the strings passed from RADIUS in the Alc-Subs-Prof-Str and Alc-SLA-Prof-Str Vendor Specific Attributes (VSAs) are interpreted verbatim so they are not used as string input to a mapping function.
configure
subscriber-mgmt
sla-profile "sla-profile-1" create
egress
no qos-marking-from-sap
exit
exit
sub-profile "sub-profile-1" create
radius-accounting
policy "sm-acct-1"
exit
exit
sub-ident-policy "all-subscribers" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
exit
exit
exit
Whilst it is entirely possible to authenticate subscribers locally using a local user database (LUDB), the more widely deployed approach is to use RADIUS, and this approach is therefore used throughout this chapter. The next output shows the authentication policy sm-auth-1 and the RADIUS accounting policy sm-acct-1. Both policies reference the radius-server-policy aaa-radius-1, which provides the context to configure the source-address to use for RADIUS messages and an associated routing context. The RADIUS server policy then references a RADIUS server radius-172.16.1.11, which in turn allows for configuration of the server IP address, the secret key to be used for message exchanges, and any other optional port configuration. In this example also Change of Authorization (COA) is configured at RADIUS server level, through the accept-coa command.
The intention is not to provide a complete description of all of the RADIUS parameters as this would distract from the objective of this chapter.
configure
router
radius-server
server "radius-172.16.1.11" address 172.16.1.11 secret vsecret1 create
accept-coa
pending-requests-limit 1024
exit
exit
exit
aaa
radius-server-policy "aaa-radius-1" create
servers
router "Base"
source-address 192.0.2.2
server 1 name "radius-172.16.1.11"
exit
exit
exit
subscriber-mgmt
authentication-policy "sm-auth-1" create
pppoe-access-method pap-chap
include-radius-attribute
nas-port-id
nas-identifier
access-loop-options
calling-station-id remote-id
exit
radius-server-policy "aaa-radius-1"
exit
radius-accounting-policy "sm-acct-1" create
no queue-instance-accounting
session-accounting interim-update host-update
update-interval 120
include-radius-attribute
circuit-id
framed-ip-addr
nas-identifier
nas-port-id
nas-port-type
sla-profile
sub-profile
subscriber-id
std-acct-attributes
exit
session-id-format number
radius-server-policy "aaa-radius-1"
exit
exit
exit
Basic LNS Configuration
To illustrate the building blocks that are required to implement LNS functionality, a VPRN is used on the LAC and the LNS supporting an L2TP tunnel and terminating PPP sessions at the LNS side of the L2TP tunnel. The required configuration for this VPRN at the LNS is shown in the following output. The unicast VPRN parameters such as route-distinguisher and vrf-import/vrf-export are not discussed here, only the parameters that are relevant to subscriber termination, which are equally applicable to VPRN and/or IES services.
The interface called system is a logical loopback interface and is used as the LNS endpoint address for L2TP signaling. The name of this interface is not important; this interface only must be a loopback interface. The LAC has a corresponding interface with IP address 192.168.0.1. The address of the interface system is also used in the subscriber-interface context as argument to the unnumbered command, meaning this IP address is used for the purpose of IPCP negotiation with incoming PPP sessions. Within the subscriber-interface context, the group-interface has a different definition than a conventional ESM group interface. A conventional group interface contains one or more SAPs belonging to the same port or LAG. However, in the context of LNS, there are no SAPs. The group interface also might terminate sessions within the same L2TP tunnel which are anchored on different MS-ISAs in a common lns-group. To accommodate this, the group-interface has the creation-time attribute lns. This attribute essentially means that the group interface can terminate subscribers from more than one port/LAG; where port/LAG is interpreted as different MS-ISAs.
The group-interface then provides a sap-parameters context that allows for configuration of sub-sla-mgmt parameters that would typically be found under a SAP. These parameters apply to all subscribers terminated on this group interface. In the example shown, only the sub-ident-policy is configured; meaning that other ESM parameters such as sla-profile, sub-profile, and subscriber-id must be obtained from a different source. In this chapter, they are obtained through RADIUS.
The static route black-holes prefix 10.48.127.0/24 ensures this prefix is added to the route-table. Subscribers are allocated /32 addresses from this range, which must be advertised upstream to PE-1 to ensure end-to-end IP connectivity. This is implemented through the vrf-export policy (not shown for conciseness).
Within the l2tp context, an hierarchy of groups and tunnels is defined. Groups reside directly under the l2tp context, and tunnels reside within the group context. Groups are intended to administratively organize tunnels that may share a common use or contain common parameters. The L2TP tunnel characteristics can be inherited from the group context, or overridden within the tunnel context. In the group context shown in the following output, the lns-group 1 command refers to the lns-group previously configured at the ISA level. This is followed by the local-address command that defines the IP address to be used as a source address for L2TP signaling. The ppp context then defines the characteristics to be used when PPP sessions are established. In this case, the authentication mechanism is CHAP, and the previously configured RADIUS authentication-policy is used to authenticate the user. During the PPP session setup, the LAC negotiates LCP and authentication parameters with the subscriber. Two AVPs, the Proxy LCP AVP and the Proxy Authentication AVP allow this information to be forwarded by the LAC to the LNS. This information can be accepted by the LNS, allowing PPP to continue with negotiation of IPCP, or it can be rejected, in which case the LNS initiates a new round of NCP and PPP authentication. The proxy-authentication and proxy-lcp commands allow the information contained in these AVPs to be accepted.
Finally, the tunnel context provides the context for defining L2TP tunnel specific parameters. The peer command defines the far-end (LAC) IP address to which L2TP messages are addressed. The password is used to authenticate the far-end tunnel initiator, and is used in conjunction with the challenge parameter to implement a CHAP-like authentication mechanism. The default behavior is to never challenge the initiator (LAC); the challenge always command is the reverse of this behavior. The remote-name is used to provide an additional level of security. When the Start Control Connection Request (SCCRQ) is received from the LAC initiating the tunnel setup, it carries a mandatory Host Name AVP. The value of this AVP is compared with the name configured in the remote-name, and only tunnels with matching names are accepted. In a similar way, the local-name parameter is used to populate the Host Name AVP sent by the LNS in the SCCRP, and can be used as a similar security feature at the LAC.
When two or more MS-ISAs belong to the same lns-group, PPP sessions are load-balanced over those MS-ISAs on a per-session basis by default. Although it is not shown in the following configuration example, it is worth mentioning that within each L2TP group context, an option exists to load-balance the sessions on a per-L2TP tunnel basis using the load-balance-method per-tunnel command. This can be useful, for example, when multiple sessions are received from a single subscriber (for example, MLPPP member links) which must be handled within the same MS-ISA.
configure
service
vprn 1 customer 1 create
vrf-import "vrf1-import"
vrf-export "vrf1-export"
route-distinguisher 64496:1
auto-bind-tunnel
resolution-filter
ldp
exit
resolution filter
exit
interface "system" create
address 192.168.0.2/32
loopback
exit
subscriber-interface "LNS-SUB-INT" create
unnumbered 192.168.0.2
group-interface "LNS-GROUP-INT" lns create
sap-parameters
sub-sla-mgmt
sub-ident-policy "all-subscribers"
exit
exit
exit
exit
static-route-entry 10.48.127.0/24
black-hole
no shutdown
exit
exit
l2tp
group "L2TP-GROUP-1" create
hello-interval 60
idle-timeout 600
lns-group 1
local-address 192.168.0.2
ppp
authentication chap
authentication-policy "sm-auth-1"
default-group-interface "LNS-GROUP-INT" service-id 1
keepalive 10 hold-up-multiplier 3
proxy-authentication
proxy-lcp
exit
tunnel "L2TP-TUNNEL-1" create
challenge always
local-name "LNS"
peer 192.168.0.1
remote-name "LAC"
password tunnelpwd
no shutdown
exit
no shutdown
exit
no shutdown
exit
no shutdown
exit
exit
exit
As previously described, RADIUS is used to authenticate the subscriber, which upon successful authentication returns the ESM parameters, Subscriber-ID (Alc-Subsc-ID-Str), SLA-Profile (Alc-SLA-Prof-Str), and Sub-Profile (Alc-Subsc-Prof-Str) as needed for instantiating the subscriber in SR OS. These parameters could be obtained locally on the LNS using the def-sub-id, def-sla-profile and def-sub-profile commands under the group-interface>sap-parameters context. This enables a mechanism to provide default parameters in the absence of another source. However, passing them from RADIUS has some benefits, such as:
It is comparatively easy to provide different SLA- and Sub-Profiles to different users, which can be used to differentiate service levels.
If RADIUS infrastructure is available and used to provide ESM parameters, it is relatively easy to extend that infrastructure to provide for mid-session changes of those parameters (such as sla-profile and sub-profile) using a Change of Authorization (CoA).
The following provides an example of a RADIUS users file entry for the test subscriber. In addition to the previously defined ESM parameters, the Alc-Serv-ID VSA is used to define the service number in which this subscriber must be terminated (in this case, VPRN 1 as previously configured), while the Alc-Interface VSA is used to define the relevant group interface within that service. If it is intended that all PPP sessions ingressing on a particular L2TP group are all to be terminated within a common service and group interface, it is not necessary for the RADIUS server to send the Alc-Serv-ID and Alc-Interface VSAs defining the service and group interface.Instead, a default service and group interface can be defined within the ppp context of the l2tp group using the parameter default-group-interface <name> service-id <number>. The remainder of the attributes in the output are well-known standard attributes.
subscriber1@isp.net Cleartext-Password := "letmein"
Alc-Subsc-ID-Str = "subscriber1@isp.net",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Alc-Serv-Id = "1",
Alc-Interface = "LNS-GROUP-INT",
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 10.48.127.27,
L2TP Tunnel Setup
Before the PPP session can be terminated at the LNS, an L2TP tunnel must be established between the LAC and LNS. This is achieved using a three-way control message exchange of Start Control Connection Request (SCCRQ), Start Control Connection Reply (SCCRP), and Start Control Connection Connected (SCCN). All of these messages are explicitly acknowledged by the peer using the sequence numbers (number sent, number received) in the L2TP header, thereby creating a reliable control channel. The acknowledgment can be piggybacked in a corresponding control message, or it can be an explicit acknowledgment using a control packet with only an L2TP header, known as a Zero Length Body (ZLB) message.
The SCCRQ is used to initiate the tunnel between LAC and LNS, and although it can be sent by either the LAC or LNS, it is typically sent by the LAC toward the LNS (as in this example). The SCCRQ contains a number of mandatory AVPs, denoted by the M-bit in the AVP header (set to 1), including Message Type, Protocol Version, Host Name, Framing Capabilities, and Assigned Tunnel ID. It can also contain a number of optional AVPs, such as Vendor Name, and Firmware Revision, which can be ignored by the recipient if they are unrecognized.
1 2019/05/23 16:27:13.662 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 0 session 0, ns 0 nr 0, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
StartControlConnectionRequest(1)
AVP ProtocolVersion(0,2), flags: mandatory, reserved=0
version=1, revision=0
AVP HostName(0,7), flags: mandatory, reserved=0
"LAC"
AVP WindowSize(0,10), flags: mandatory, reserved=0
64
AVP FramingCapabilities(0,3), flags: mandatory, reserved=0
sync=no, async=no
AVP BearerCapabilities(0,4), flags: mandatory, reserved=0
digital=yes, analogue=no
AVP FirmwareRevision(0,6), flags:, reserved=0
4096
AVP VendorName(0,8), flags:, reserved=0
"Nokia"
AVP AssignedTunnelId(0,9), flags: mandatory, reserved=0
10007"
The SCCRP is sent in response to the SCCRQ and is used to indicate that the parameters in the SCCRQ were acceptable and that the establishment of the L2TP tunnel can continue. The SCCRP contains the same mandatory AVPs and can contain the same optional AVPs as the SCCRQ, but an additional optional AVP is the Challenge AVP which is included as a result of the challenge always and password parameters configured within the tunnel context.
2 2019/05/23 16:27:13.662 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, egress)
"L2TP(v2, ctrl, egress): UDP 192.168.0.2:1701 -> 192.168.0.1:1701
tunnel 10007 session 0, ns 0 nr 1, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
StartControlConnectionReply(2)
AVP ProtocolVersion(0,2), flags: mandatory, reserved=0
version=1, revision=0
AVP HostName(0,7), flags: mandatory, reserved=0
"LNS"
AVP WindowSize(0,10), flags: mandatory, reserved=0
64
AVP FramingCapabilities(0,3), flags: mandatory, reserved=0
sync=no, async=no
AVP BearerCapabilities(0,4), flags: mandatory, reserved=0
digital=yes, analogue=no
AVP FirmwareRevision(0,6), flags:, reserved=0
4096
AVP VendorName(0,8), flags:, reserved=0
"Nokia"
AVP AssignedTunnelId(0,9), flags: mandatory, reserved=0
9265
AVP Challenge(0,11), flags: mandatory, reserved=0
0d 12 69 86 37 7b 35 7f d7 00 22 bd ca 25 ad ab
59 d7 33 d5 a1 01 92 4f 22 a9 9a d8 b3 68 55 60
98 96 8c f9 e4 0a 9c ce e3 b9 ed 48 d8 "
The response to the SCCRP, and the completion of the three-way message exchange is the SCCN. The only mandatory AVP for the SCCN is the Message Type, and since the SCCRP contained a Challenge AVP, the SCCN also contains an AVP Challenge Response. If this response is not satisfactory to the LNS, it generates a Stop Control Connection Notification (StopCCN) with a result code indicating that the requester is not authorized, and subsequently removes any associated tunnel state.
3 2019/05/23 16:27:13.664 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 9265 session 0, ns 1 nr 1, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
StartControlConnectionConnected(3)
AVP ChallengeResponse(0,13), flags: mandatory, reserved=0
e6 10 7b 11 36 7d ba fc e6 14 4d 30 3d f0 9a ba "
With a successful three-way exchange completed, the L2TP tunnel is established. A snapshot view of all L2TP tunnels within the relevant routing context can be displayed using the command in the following output. The Loc-Tu-ID and Rem-Tu-ID are the local and remote tunnel IDs passed in the Assigned Tunnel Id AVP in the SCCRP and SCCRQ respectively. The Conn ID, or connection Id, is a locally significant parameter used for identifying a particular tunnel, and is a 32-bit representation of the local tunnel Id (1442 * 65536 = 946470912). The connection ID is for example used in event log entries for this tunnel. If the state is shown as established, then one or more PPP sessions are running over the tunnel. The state can also be establishedIdle meaning that although the tunnel is up and established, there are no PPP sessions active within the tunnel.
*A:LNS# show router 1 l2tp tunnel
===============================================================================
Conn ID Loc-Tu-ID Rem-Tu-ID State Blacklist-state Ses Active
Group Ses Total
Assignment
-------------------------------------------------------------------------------
607191040 9265 10007 establishedIdle not-blacklisted 0
L2TP-GROUP-1 0
L2TP-TUNNEL-1
-------------------------------------------------------------------------------
No. of tunnels: 1
===============================================================================
*A:LNS#
Once a tunnel is established, maintenance and health-checking of that tunnel is achieved using a keepalive mechanism that employs Hello control messages. The Hello message contains only one AVP, the Message Type AVP, which indicates it is a Hello message. The Hello messages operate asynchronously between the peers. There is no echo request and echo response function, but simply a Hello followed by an acknowledgment. The Hello is acknowledged in the same way as other control messages, using either piggybacking or ZLB acknowledgments. This asynchronous behavior allows for either end of the tunnel to be configured for different Hello intervals (they are not negotiated), or even for one end not send Hellos at all.
5 2019/05/23 16:28:11.374 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 9265 session 0, ns 2 nr 1, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
Hello(6)"
6 2019/05/23 16:28:11.374 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, egress)
"L2TP(v2, ctrl, egress): UDP 192.168.0.2:1701 -> 192.168.0.1:1701
tunnel 10007 session 0, ns 1 nr 3, flags:, reserved=0"
The Hello interval at the LNS is configurable under the l2tp, group, or tunnel contexts using the hello-interval parameter. The range is 60 to 3600 seconds, with the default being 60 seconds. The hello-interval infinite option suppresses sending of Hellos. If the system sends a Hello message and does not get an acknowledgment, it will retransmit the Hello message as many times as the value of the max-retries-estab parameter, each time with an exponential back-off. The max-retries-estab parameter can be configured in the l2tp, group, or tunnel contexts. The default value is 5, and if no acknowledgment is received before this value is exceeded, the tunnel is declared down and a StopCCN is sent toward the peer.
The retry interval starts with 1 second and doubles on each retry with a maximum-interval of 8 seconds. For example, using a max-retries-estab value of 7 results in a retry of [1, 2, 4, 8, 8, 8 seconds]
The StopCCN is a message that can be generated by either LAC or LNS and is used to inform its peer that the tunnel is being closed. This implicitly means that all PPP sessions carried within that tunnel are also being closed without any associated control messages for those sessions. The StopCCN must contain the Message Type and Tunnel ID AVPs, and additionally carries a Result Code AVP with result code and error code fields to indicate to the peer the reason for the tunnel closure.
9 2017/06/07 15:19:00.56 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 14442 session 0, ns 2 nr 3, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
StopControlConnectionNotification(4)
AVP ResultCode(0,1), flags: mandatory, reserved=0
result-code: "generalRequestToClearControlConnection"(1),
error-code: "noGeneralError"(0)
error-msg: "operator request"
AVP AssignedTunnelId(0,9), flags: mandatory, reserved=0
11458"
10 2017/06/07 15:19:00.56 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, egress)
"L2TP(v2, ctrl, egress): UDP 192.168.0.2:1701 -> 192.168.0.1:1701
tunnel 11458 session 0, ns 3 nr 3, flags:, reserved=0"
The tunnel Connection Id can be used as an additional argument to display the details of a particular tunnel when multiple tunnels are present. The following output is an example of this taken just after the L2TP tunnel has been closed by the LAC peer, and is intentionally taken at this time to illustrate the purpose of some of the fields shown in the output. The State is moved to closedByPeer, and the Stop CCN Result field and Error Message field respectively contain the result code and error code of the Result Code AVP received from the LAC in the StopCCN. Because the tunnel is now in a closedByPeer state, all state and information related to this tunnel is removed from the system after a period defined by the Destruct Timeout (shown in the output as Destruct TO). The intention of the Destruct Timeout is to retain information about the tunnel closure which might aid operational communities. The default value as shown is 60 seconds, but it can be configured using the destruct-timeout parameter in the l2tp, group, or tunnel contexts. The remainder of the fields in the output are the operational parameters of the tunnel and are self-explanatory.
*A:LNS# show router 1 l2tp tunnel detail
===============================================================================
L2TP Tunnel 607191040
===============================================================================
Connection ID: 607191040
Protocol : v2
State : closedByPeer
IP : 192.168.0.2
UDP : 1701
Peer IP : 192.168.0.1
Peer UDP : 1701
Tx dst-IP : 192.168.0.1
Tx dst-UDP : 1701
Rx src-IP : 192.168.0.1
Rx src-UDP : 1701
Name : LNS
Remote Name : LAC
Assignment ID: L2TP-TUNNEL-1
Group Name : L2TP-GROUP-1
Acct. Policy : N/A
Error Message: operator request
Remote Conn ID : 655818752
Tunnel ID : 9265 Remote Tunnel ID : 10007
Preference : 50 Receive Window : 64
Hello Interval (s): 300 AVP Hiding : never
Idle TO (s) : 600 Destruct TO (s) : 60
Max Retr Estab : 5 Max Retr Not Estab: 5
Cfg'd Sess Limit : unlimited Oper Session Limit: 32767 '
Transport Type : udpIp Challenge : always
Time Started : 05/23/2019 16:27:14 Time Idle : N/A
Time Established : 05/23/2019 16:27:14 Time Closed : 05/23/2019 16:30:15
Stop CCN Result : generalReq General Error : noError
Blacklist-state : not-blacklisted
Set Dont Fragment : true
Failover
State : not-recoverable
Recovery Conn ID : N/A
Recovery state : not-applicable
Recovered Conn ID : N/A
Recovery method : mcs
Track SRRP : (Not specified)
Ctrl msg behavior : handle
Recovery time (ms)
Requested : N/A
Peer : N/A
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No. of tunnels: 1
===============================================================================
*A:LNS#
PPP Session Setup
Once the L2TP tunnel is created, the process of establishing a PPP session can start. Once again, a three-way control message exchange is used for establishing a session within an L2TP tunnel, consisting of the Incoming Call Request (ICRQ), Incoming Call Reply (ICRP), and Incoming Call Connected (ICCN). Given that they are control messages, they are all explicitly acknowledged using piggybacking or ZLB acknowledgments.
The ICRQ is sent from the LAC to the LNS to indicate that it has received an incoming call (PPP session) and that a session needs to be established between the two peers for this call. The ICRQ provides enough information about the call for the LNS to make a decision about whether it should answer the call or not. The ICRQ contains the Message Type and Assigned Session ID AVPs as well as a Call Serial Number AVP, which can be used on both the LAC and LNS as an easy reference to the call for troubleshooting purposes. The ICRQ can also carry optional AVPs including Calling Number and Access Line Information AVPs (RFC 5515) such as Circuit ID, Remote ID, Actual Data Rate Upstream, and Actual Data Rate Downstream.
5 2019/05/23 16:38:49.730 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 12229 session 0, ns 2 nr 1, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
IncomingCallRequest(10)
AVP AssignedSessionId(0,14), flags: mandatory, reserved=0
15859
AVP CallSerialNumber(0,15), flags: mandatory, reserved=0
15550
AVP CallingNumber(0,22), flags: mandatory, reserved=0
"LAC 1/1/3:2"
AVP AgentCircuitId(3561,1), flags:, reserved=0
"circuit0"
AVP AgentRemoteId(3561,2), flags:, reserved=0
"remote0"
AVP ActDataRateUp(3561,129), flags:, reserved=0
2000000
AVP ActDataRateDown(3561,130), flags:, reserved=0
4000000"
The ICRP is sent by the LNS toward the LAC in response to the ICRQ to indicate that the parameters in the ICRQ were acceptable, and that the LAC should go ahead and proceed with the call. The ICRP contains only two AVPs; the Message Type and the Assigned Session ID. The Assigned Session ID values are local to each peer as opposed to a negotiated or agreed-upon value.
7 2019/05/23 16:38:49.731 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, egress)
"L2TP(v2, ctrl, egress): UDP 192.168.0.2:1701 -> 192.168.0.1:1701
tunnel 8826 session 15859, ns 1 nr 3, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
IncomingCallReply(11)
AVP AssignedSessionId(0,14), flags: mandatory, reserved=0
14338"
The final message in the three-way exchange used for establishing sessions within the tunnel is the ICCN. It is sent by the LAC to the LNS to indicate that the call has been answered, so the L2TP session is moved to the established state. It also provides additional information on parameters that were used to answer the call which may not have been available when the ICRQ was sent (although it is likely that in most cases they were available). At a minimum, the ICCN must contain the Message Type, Framing Type, and TX Connect Speed AVPs. The TX Connect Speed defines the speed in bits per second from the perspective of traffic flowing from the LAC toward the subscriber (i.e. the LAC downstream rate) and, for best accuracy, can be derived by the LAC from the PPP Broadband Forum Access Line Characteristic tags inserted by the access node (Appendix C TR-101). The TX Connect Speed can be useful for indirect setting of a Hierarchical QoS (H-QoS) aggregate rate. It is indirect because the LNS cannot infer and set an aggregate rate based directly on the TX Connect Speed AVP, but rather the TX Connect Speed is passed to the RADIUS server (using the include-radius-attribute access-loop-option parameter in the authentication policy), which in turn may pass the aggregate rate to the LNS in a QoS override VSA. This is described further in the QoS section.
A number of optional AVPs can also be present providing information from the LCP negotiation between the LAC and client. These include Initial Receive, Last Transmit and Last Receive LCP Config Requests, together with Proxy Authentication Type, Name, Challenge, and Response. These parameters allow the LNS to either force a renegotiation of LCP, or to continue with the PPP session and move to the IPCP phase. The final AVP present in the ICCN shown is the RX Connect Speed AVP, which is the opposite of the TX Connect Speed and defines the speed in bits per second from the perspective of traffic flowing from the subscriber toward the LAC.
9 2019/05/23 16:38:49.732 CEST MINOR: DEBUG #2001 vprn1 L2TP(v2, ctrl, ingress)
"L2TP(v2, ctrl, ingress): UDP 192.168.0.1:1701 -> 192.168.0.2:1701
tunnel 12229 session 14338, ns 3 nr 2, flags:, reserved=0
AVP MessageType(0,0), flags: mandatory, reserved=0
IncomingCallConnected(12)
AVP FramingType(0,19), flags: mandatory, reserved=0
sync=no, async=no
AVP TxConnectSpeed(0,24), flags: mandatory, reserved=0
4294967295
AVP InitialRxLcpConfReq(0,26), flags:, reserved=0
01 04 05 d4
[1] MRU: 1492
AVP LastTxLcpConfReq(0,27), flags:, reserved=0
01 04 05 d4 03 05 c2 23 05 05 06 3c 32 9f a6
[1] MRU: 1492
[3] Authentication-Protocol: 0xc223 (CHAP), Algorithm = 5 (MD5)
[5] Magic-Number: 0x3c329fa6
AVP LastRxLcpConfReq(0,28), flags:, reserved=0
01 04 05 d4
[1] MRU: 1492
AVP ProxyAuthenType(0,29), flags:, reserved=0
chap(2)
AVP ProxyAuthenName(0,30), flags:, reserved=0
"subscriber1@isp.net"
AVP ProxyAuthenChallenge(0,31), flags:, reserved=0
d2 cb 6f 10 90 61 f5 bf 59 72 e0 d2 4b 8c c5 05
02 5c c5 9e d3 c5 65 d9 f0 08 38 71 d0 a2 75 23
6e 64 b3 7f 45 a9 3f 9e 9b a0 f0 e6 ac
AVP ProxyAuthenId(0,32), flags:, reserved=0
id=1, reserved=0
AVP ProxyAuthenResponse(0,33), flags:, reserved=0
d5 3e 86 2f 2b 50 0d 0b 01 15 5b 0f 6d ec aa fb
AVP RxConnectSpeed(0,38), flags:, reserved=0
4294967295"
On completion of the three-way control message exchange required for session setup, the LNS authenticates the user in the incoming call. In this example, RADIUS is used, which returns the standard and vendor-specific attributes previously defined in the users file. A successful authentication allows the LNS to move to the IPCP phase with the subscriber. In this example, RADIUS returns the IP address in the standard attribute Framed-IP-Address, but equally local pooling with a DHCP server could be used. For conciseness, the IPCP phase is not detailed within this example because the process is reasonably well-known and understood. However, on completion of the IPCP phase, the subscriber is instantiated and the L2TP session becomes active. The Tunnel-ID and Session-ID parameters are locally generated numbers that are passed in L2TP control messages. As previously described, the Connection Id is a locally significant parameter that is a 32-bit representation of the local tunnel Id (6482 * 65536 = 424804352). The ID field is again a locally significant parameter used to identify the L2TP session, and is again represented as a 32-bit number. It is derived from a sum of the Control Connection ID plus the Session ID (424804352 + 26255 = 424830607).
*A:LNS# show router 1 l2tp session
===============================================================================
L2TP Session Summary
===============================================================================
ID Control Conn ID Tunnel-ID Session-ID State
-------------------------------------------------------------------------------
801454082 801439744 12229 14338 established
subscriber1@isp.net
interface: LNS-GROUP-INT
service-id: 1
10.48.127.27
-------------------------------------------------------------------------------
No. of sessions: 1
===============================================================================
*A:LNS#
The PPP session is also recorded in the subscriber-host table of VPRN 1 and a forwarding state of Fwding indicates that all attributes and resources associated with this subscriber are correctly installed and activated within the system. The subscriber username is shown, as is its MAC address and IP address. The IP address has an origin of IPCP. The fact that a MAC address is displayed here is somewhat misleading because this is a PPP over L2TP session, which does not have a MAC address present in any of its headers. When the MS-ISA removes the L2TP header, it converts the PPP packet to PPPoE for ease of subsequent processing. As a result of this, the MS-ISA generates a dummy MAC address, and this is the MAC address shown. The displayed SAP 1/2/lns-esm:1.259 is automatically generated by the system. Each operational MS-ISA that is part of the lns-group creates two internal objects, known as lns-net and lns-esm. These objects are the network-side (lns-net) and the subscriber-side (lns-esm) of each MS-ISA.
When the first L2TP session within this service is established, the system creates one lns-esm SAP where the first two digits indicate the MDA slot (1/2) where the MS-ISA is installed, and the last two numbers are the internal Q-in-Q tags used through the MS-ISA (1.259). This internal Q-in-Q tag value is of little relevance, but for informational purposes is derived from the group interface If index. If there is more than one MS-ISA active in the lns-group, a second session would be load-balanced onto this MS-ISA, and a second lns-esm SAP would be created, until a maximum of six SAPs is reached, which corresponds to the maximum number of supported active MS-ISA boards.
*A:LNS# show service id 1 subscriber-hosts
=============================================================
Subscriber Host table
=============================================================
Sap Subscriber
IP Address
MAC Address PPPoE-SID Origin Fwding State
-------------------------------------------------------------
[1/2/lns-esm:1.259] subscriber1@isp.net
10.48.127.27
00:00:2f:c5:38:02 1 IPCP Fwding
-------------------------------------------------------------
Number of subscriber hosts : 1
=============================================================
*A:LNS#
It is also possible to view the internal lns-net object, shown in the next output as interface name _tmnx_lns-in-1/2 with port number 1/2/lns-net:1*. To further clarify (and reiterate), the lns-esm and lns-net are simply internal objects used to route L2TP traffic through the MS-ISA board. Upstream traffic (subscriber to LNS) ingresses through lns-net into the MS-ISA where the L2TP header is decapsulated before PPP packets are presented to the service group interface through lns-esm. Downstream traffic (LNS to subscriber) passes through lns-esm into the MS-ISA where the PPP packets are encapsulated in L2TP before egressing through lns-net and being routed toward the destination.
*A:LNS# show service id 1 interface
==============================================================================
Interface Table
==============================================================================
Interface-Name Adm Opr(v4/v6) Type Port/SapId
IP-Address PfxState
------------------------------------------------------------------------------
system Up Up/Down VPRN loopback
192.168.0.2/32 n/a
LNS-SUB-INT Up Up/Down VPRN S* subscriber
Unnumbered If[192.168.0.2] n/a
LNS-GROUP-INT Up Up/Down VPRN G* bbg-5.lns-esm
_tmnx_lns-in-1/2 Up Up/Down VPRN 1/2/lns-net:1*
- -
------------------------------------------------------------------------------
Interfaces : 4
==============================================================================
Wholesale/Retail
In the example configuration used so far, the L2TP tunnel/session is terminated in VPRN 1, and the subscriber is also terminated in the same VPRN 1. However, a common requirement is to build per-customer VRFs (VPRNs), particularly for business users. To meet this requirement, the so-called ‛Wholesale/Retail’ model is used, which provides a mechanism to terminate the subscriber in a different service context from the service which actually terminated the L2TP tunnel/session.
To achieve this, a second service is created which becomes the ‛Retail VRF’, or customer-specific VRF, and the previously defined VPRN 1 becomes the Wholesale VRF (which actually requires no further configuration). The necessary configuration for the Retail VRF is as follows and its parameters have been previously explained. Although they may seem obvious, there are a couple of points that are worth revisiting. The vrf-import and vrf-export parameters are used to reference policies to import/export VPN-IPv4/v6 prefixes with the customer-specific Route-Target Extended Communities. Given that a different routing context and unique Route-Targets are used for this Retail VRF, it is perfectly feasible to re-use the same IP address in VPRN 2 as was used in VPRN 1 for the unnumbered subscriber interface. The group interface has a different name from the group interface in VPRN 1, but this is simply for illustration purposes and both group interfaces can have the same name if a standard naming convention is required. More importantly, the group interface must have the creation-time attribute lns to allow subscriber termination without SAPs. The static route black-holes prefix 10.10.148.0/24, ensuring this prefix is added to the route-table. This IP address range is used to allocate addresses to subscribers, and is therefore advertised in VPN-IPv4.
configure
service
vprn 2 customer 1 create
vrf-import "vrf2-import"
vrf-export "vrf2-export"
route-distinguisher 64496:2
auto-bind-tunnel
resolution-filter
ldp
exit
resolution filter
exit
interface "loopback" create
address 192.168.0.2/32
loopback
exit
subscriber-interface "VPRN2-SUB-INT" create
unnumbered 192.168.0.2
group-interface "VPRN2-GROUP-INT" lns create
sap-parameters
sub-sla-mgmt
sub-ident-policy "all-subscribers"
exit
exit
exit
exit
static-route-entry 10.10.48.0/24
black-hole
no shutdown
exit
exit
no shutdown
exit
exit
exit
In addition to the Retail VRF configuration, the RADIUS entry for the subscriber returns Alc-Serv-Id VSA with a value of 2 to indicate the Retail VRF Service Id, while the Alc-Interface VSA refers to the group interface name within that Retail VRF.
subscriber2@isp.net Cleartext-Password := "letmein"
Alc-Subsc-ID-Str = "subscriber2@isp.net",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Alc-Serv-Id = "2",
Alc-Interface = "VPRN2-GROUP-INT",
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 10.10.148.22
In this Wholesale/Retail scenario, the high-level functions are as follows:
The L2TP tunnel and session are terminated in the Wholesale VRF (in this example, VPRN 1).
When the LNS receives the ICCN for the session, it authenticates the user (in this example via RADIUS).
RADIUS returns the Retail VRF service Id and group interface. If RADIUS returns IP address information this address is used for the purpose of IPCP negotiation with the subscriber within the Retail VRF (in this example, VPRN 2). If RADIUS does not return IP address information, it can be derived from either of the following:
A DHCP client function within the group interface, which is used to obtain an IP address from a local or remote DHCP server.
The local-address-assignment feature, which directly accesses a local DHCP server through an internal procedure call (the server pool name must be obtained through RADIUS, LUDB, or default-pool-name).
Once the subscriber is activated, the PPP session and subscriber-host can be seen in VPRN 2. The description field of the show service id 2 ppp session command is however somewhat misleading. It is automatically concatenated from the VPRN that terminated the L2TP tunnel, the tunnel Connection Id, the local tunnel Id, and the L2TP session Id. It should not be misinterpreted as meaning that the subscriber has been terminated in VPRN 1.
*A:LNS# show service id 2 ppp session
===============================================================================
PPP sessions for service 2
===============================================================================
User-Name
Descr.
Up Time Type Termination IP/L2TP-Id/Interface-Id MC-Stdby
-------------------------------------------------------------------------------
subscriber2@isp.net
vprn:1 connid:449518148 tid:6859 sid:6724
0d 00:00:10 oL2tp local 10.10.148.22
-------------------------------------------------------------------------------
No. of PPP sessions: 1
===============================================================================
*A:LNS#
QoS
In the preceding examples, the subscriber PPP sessions terminated by the LNS have been instantiated using the default SAP-ingress/egress QoS policies (policy 1), with a single queue and no use of H-QoS. This section demonstrates the use of slightly more complex QoS policies that employ H-QoS, with the intention of providing an overview of those capabilities.
For subscriber termination in broadband networks, it is fairly commonplace to use one or more policers on ingress, and not apply an aggregate rate limit on ingress (upstream) traffic. Whilst this is possible in SR OS for general ESM subscriber termination, policers are not supported when the system is functioning as an LNS. It is therefore necessary to use one or more queues on ingress with the usual considerations with regard to the use of service-queuing or shared-queuing. Conversely, on egress (downstream) it is common to see more than one queue in use for different services, particularly for business services, with an aggregate rate applied to the subscriber through the use of H-QoS. For example, assume that there are three classes in use; Best-Effort (BE), Assured-Forwarding (AF), and Expedited Forwarding (EF). This section will look at two ways to achieve this. Firstly using a conventional H-QoS scheduler, and secondly using an egress Port-Scheduler.
The SAP-ingress QoS policy classifies traffic into three Forwarding Classes (FCs) and maps those FCs to a single queue. Ingress traffic is not rate-limited (default PIR in queue 1 is max), and queue 1 is not mapped to a parent H-QoS scheduler.
configure
qos
sap-ingress 10 create
queue 1 create
exit
queue 11 multipoint create
exit
fc "af" create
queue 1
exit
fc "be" create
queue 1
exit
fc "ef" create
queue 1
exit
dscp be fc "be"
dscp ef fc "ef"
dscp af31 fc "af"
exit
exit
exit
A scheduler policy is created having a single a tier 1 scheduler with a rate-limit of 8Mb/s.
configure
qos
scheduler-policy "Subscriber-Aggregate-Policy" create
tier 1
scheduler "Aggregrate-Rate" create
rate 8000
exit
exit
exit
exit
exit
The SAP-egress QoS policy performs egress classification and maps classified traffic to the relevant FC, which in turn is mapped to its own queue. All queues are mapped to the previously configured tier 1 scheduler Aggregate-Rate such that queue 3 (EF) is allocated bandwidth first, and queue 1 (BE) and 2 (AF) are allocated bandwidth next in a 1:4 ratio.
configure
qos
sap-egress 10 create
queue 1 create
parent "Aggregrate-Rate" level 2 weight 20
exit
queue 2 best-effort create
parent "Aggregrate-Rate" level 2 weight 80
exit
queue 3 expedite create
parent "Aggregrate-Rate" cir-level 3
rate 1024 cir 1024
exit
fc af create
queue 2
exit
fc be create
queue 1
exit
fc ef create
queue 3
exit
dscp be fc "be"
dscp ef fc "ef"
dscp af31 fc "af"
exit
exit
exit
To this point, the QoS configuration is no different from a typical SAP-level QoS application. To make it applicable to ESM, the previously configured SAP-ingress and SAP-egress QoS policies must be referenced in the ingress/egress contexts of the sla-profile, respectively. Equally, the H-QoS scheduler-policy must be referenced in the ingress/egress contexts of the sub-profile. In this example, H-QoS is only used on egress, and as a result the scheduler-policy is referenced only in the egress context.
configure
subscriber-mgmt
sla-profile "ESM-SLA-PROF" create
ingress
qos 10
exit
exit
egress
qos 10
exit
no qos-marking-from-sap
exit
exit
sub-profile "ESM-SUB-PROF" create
collect-stats
radius-accounting
policy "AAA-ACCT-POLICY"
exit
egress
scheduler-policy "Subscriber-Aggregate-Policy"
exit
exit
exit
exit
exit
The queues assigned to the subscriber through the preceding SAP-ingress/egress QoS policies, together with accumulative statistics can be viewed using the show service active-subscribers subscriber <name> detail command (real time rates can be seen using the monitor command). The H-QoS scheduler hierarchy, with the SAP-egress queues mapped as child queues to a parent scheduler can be validated using the command show qos scheduler-hierarchy subscriber <name> egress. The detail argument as an extension of this command provides a significant amount of detail on real-time bandwidth allocated to each queue by the scheduler in the within-CIR and above-CIR passes. It also provides a useful snapshot on offered traffic loads in Kb/s on a per-queue basis.
*A:LNS# show qos scheduler-hierarchy subscriber "subscriber2@isp.net" egress
===============================================================================
Scheduler Hierarchy - Subscriber subscriber2@isp.net
===============================================================================
Egress Scheduler Policy : Subscriber-Aggregate-Policy
-------------------------------------------------------------------------------
Root (Egr)
| slot(1)
|--(S) : Aggregrate-Rate (Port 1/2/lns-esm Orphan)
| |
| |--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->3
| |
| |--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->2
| |
| |--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->1
| |
|
===============================================================================
*A:LNS#
The advantage of using conventional H-QoS schedulers is that they can be applied universally on ingress and egress to provide a subscriber aggregate rate capability. The disadvantage of this approach is that the aggregate rate defined in the scheduler-policy (or overridden in the sub-profile) cannot be dynamically overridden from RADIUS using the QoS-override VSA (Alc-Subscriber-QoS-Override). If ingress H-QoS is not a requirement, but the ability to override the subscriber egress aggregate-rate is, then H-QoS should be implemented using an egress port-scheduler.
The egress port-scheduler is functionally the same as a conventional H-QoS scheduler in the manner with which it arbitrates bandwidth across its child queues. However, it has some notable differences:
It is applied at the egress port level. Any queue that uses that egress port to which it is applied that is not explicitly mapped to a port-scheduler is considered an orphan queue. Orphan queues are not serviced by the port-scheduler until all of its child queues have been serviced.
Unlike conventional H-QoS schedulers that include only Ethernet overhead, the port-scheduler includes Preamble and Inter-Frame Gap for each packet.
It is supported only on Ethernet ports, and only on egress.
The egress aggregate rate applied to the subscriber can be overridden from RADIUS.
The first bullet point above is significant from an LNS perspective. In general, after ESM handling, downstream traffic for subscribers egresses the system over a physical port. This is not the case for L2TP subscribers, for which the traffic is passed through to the MS-ISA for L2TP encapsulation before egressing the LNS (and in fact could egress the system on any number of physical ports). It is therefore not possible to apply the port-scheduler policy to the egress port in the conventional manner, and what is needed is a mechanism to apply the port-scheduler policy to the logical internal ports that interface to the MS-ISA. To achieve this, an intermediate object known as a port-policy is used, which, when configured, references the port-scheduler policy, and which subsequently is applied to the relevant lns-group.
Create the port-scheduler-policy.
configure
qos
port-scheduler-policy "egress-port-scheduler" create
exit
exit
exit
Create the port-policy and reference the previously configured port-scheduler policy.
configure
port-policy "isa-port-policy" create
egress-scheduler-policy "egress-port-scheduler"
exit
exit
Attach the port-policy to the lns-group containing the MS-ISA.
configure
isa
lns-group 1 create
shutdown
port-policy "isa-port-policy"
no shutdown
exit
exit
exit
Once the port-scheduler policy and port-policy are in place, the subscriber QoS can reference it. The QoS configuration previously used for conventional H-QoS schedulers differs in both the sap-egress policy and sub-profile when an egress port-scheduler is used. The queues within the sap-egress policy are each configured to be parented to the egress port-scheduler using the port-parent keyword (as opposed the parent keyword used for conventional H-QoS schedulers).
configure
qos
sap-egress 10 create
queue 1 create
port-parent level 2 weight 20
exit
queue 2 best-effort create
port-parent level 2 weight 80
exit
queue 3 expedite create
port-parent cir-level 3
rate 1024 cir 1024
exit
fc af create
queue 2
exit
fc be create
queue 1
exit
fc ef create
queue 3
exit
dscp be fc "be"
dscp ef fc "ef"
dscp af31 fc "af"
exit
exit
exit
The sub-profile contains no reference to scheduler policies, but instead contains a per-subscriber egress aggregate rate in Kb/s, defined through the agg-rate-limit parameter.
configure
subscriber-mgmt
sub-profile "sub-profile-1"
egress
no scheduler-policy
agg-rate-limit 8000
exit
exit
exit
exit
Once again, the queues assigned to the subscriber through the preceding SAP-ingress/egress QoS policies, together with accumulative statistics, can be viewed using the show service active-subscribers subscriber <name> detail command (real time rates can be seen using the monitor command). The scheduler SAP-egress queues mapped as child queues to a port-scheduler can be validated using the show qos scheduler-hierarchy subscriber <name> egress command. The detail argument provides a significant amount of detail on bandwidth allocated to each queue by the scheduler in the within-CIR and above-CIR passes. It also provides a useful snapshot on offered traffic loads in Kb/s on a per-queue basis. Alternatively, all of the child queues and orphans mapped to the port-scheduler can be displayed using the show qos scheduler-hierarchy port <slot/mda/lns-esm> command, again with the optional detail argument.
*A:LNS# show qos scheduler-hierarchy subscriber "subscriber2@isp.net" egress
===============================================================================
Scheduler Hierarchy - Subscriber subscriber2@isp.net
===============================================================================
Egress Scheduler Policy :
-------------------------------------------------------------------------------
Root (Egr)
| slot(1)
|--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->3 (Port
1/2/lns-esm)
|
|--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->2 (Port
1/2/lns-esm)
|
|--(Q) : Sub=subscriber2@isp.net:sla-profile-1 2->1/2/lns-esm:1.263->1 (Port
1/2/lns-esm)
|
===============================================================================
*A:LNS#
With the previously configured QoS policies and schedulers available, the aggregate rate limit in use for the subscriber can be viewed using the show service active-subscribers subscriber <name> detail command. There are three fields in this output that are of interest here. The E. Agg Rate Limit field shows the configured rate-limit in the sub-profile and is therefore relatively static. The RADIUS Rate-Limit field shows the aggregate rate received by RADIUS using the Alc-Subscriber-QoS-Override VSA, which overrides any rate limit statically configured in the sub-profile. Finally, the Oper-Rate-Limit shows the static or RADIUS-received rate-limit, minus any other H-QoS adjustments, such as Multicast H-QoS adjustment (snooping on IGMP joins) or ANCP line-rate adjustments.
*A:LNS# show service active-subscribers subscriber "subscriber2@isp.net" detail
| match expression " E. Agg Rate Limit|RADIUS Rate-Limit|Oper-Rate-Limit"
E. Sched. Policy : N/A E. Agg Rate Limit: 8000
RADIUS Rate-Limit: N/A
Oper-Rate-Limit : 8000
Hs-Oper-Rate-Limit : Maximum
*A:LNS#
Overriding the agg-rate-limit defined in the sub-profile can be done as part of the RADIUS Access-Accept, or through a Change of Authorization (CoA), and as previously outlined uses the Alc-Subscriber-QoS-Override VSA. This override function can be used, for example, to reconcile the LNS aggregate rate with the subscriber downstream rate learned through the TxConnectSpeed AVP in the ICCN message from the LAC. This ensures that the LNS does not overwhelm any downstream access node, and ensures that the LNS is responsible for all QoS scheduling in the event of congestion. In the following example, an override of the aggregate rate to 10Mb/s is sent as a CoA.
63 2019/05/24 13:47:00.340 CEST MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Receive
Change of Authorization(43) id 178 len 66 from 172.16.1.11:38256 vrid 1
SESSION ID [44] 22 020DFF000000225CE7D31B
VSA [26] 16 Nokia(6527)
SUBSCRIBER QOS OVERRIDE [126] 14 e:r:rate=10000
"
64 2019/05/24 13:47:00.341 CEST MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Change of Authorization Ack(44) 172.16.1.11:38256 id 178 len 20 vrid 1
"
Re-issuing the show service active-subscribers subscriber <name> detail command after the CoA shows that the RADIUS Rate-Limit field and the Oper-Rate-Limit field both correctly show 10Mb/s.
*A:LNS# show service active-subscribers subscriber "subscriber2@isp.net" detail
| match expression " E. Agg Rate Limit|RADIUS Rate-Limit|Oper-Rate-Limit"
E. Sched. Policy : N/A E. Agg Rate Limit: 8000
RADIUS Rate-Limit: 10000
Oper-Rate-Limit : 10000
Hs-Oper-Rate-Limit : Maximum
*A:LNS#
Propagating QoS Markings to L2TP/MPLS Headers
It is often desirable to mark the L2TP header (DCSP) or MPLS header (EXP) based on the class of service that is carried in the encapsulated subscriber IP payload. In general, when a packet is classified and mapped to an FC on ingress, that FC value is carried in the internal switch fabric header and is present when the packet is egressing the node. In the case of L2TP traffic however, the operation becomes a little more complex due to the fact that traffic transits the MS-ISA board with subscriber QoS implemented ‛mid-chassis’.
In the upstream direction (from subscriber to LNS), traffic arrives encapsulated in L2TP at the ingress IOM, and is passed through the MS-ISA via the internal object lns-net. When traffic exits the MS-ISA through lns-esm as native IP, it is subject to subscriber ingress QoS implemented on the (MS-ISA) carrier IOM. Traffic is classified and mapped to an FC at this point, and that FC mapping is maintained in the switch fabric header. As a result, marking of traffic is effected by the network egress QoS policy.
In the downstream direction (from LNS to subscriber), traffic arrives at the ingress IOM as native IP and is diverted to the MS-ISA via the lns-esm internal object. At the lns-esm, the traffic is subject to subscriber egress QoS. When the traffic is passed through lns-esm to the MS-ISA for L2TP encapsulation, internal Q-in-Q VLAN tags are attached as previously described. As the lns-esm is effectively a SAP-egress, the internal switch fabric header containing the FC marking is removed at this point, and, as a result FC information is lost.
Therefore, in order to allow for FC-continuity through the MS-ISA, the system implements a queue-group at the ingress of lns-net that has a dot1p to FC mapping as shown in Ingress/Egress QoS Processing. Assuming a SAP-egress QoS policy that employs FCs BE, AF and EF, the QoS policy would include the additional configuration to implement the appropriate dot1p marking as shown in the following output. When traffic arrives at lns-net, it is classified and mapped into the appropriate FCs, and the associated FC mapping included in the switch fabric header. At network egress, the L2TP packet is then subject to marking as defined in the network egress QoS policy.
configure
qos
sap-egress 10 create
queue 1 create
exit
queue 2 best-effort create
exit
queue 3 expedite create
exit
fc af create
queue 2
dot1p 2
exit
fc be create
queue 1
dot1p 0
exit
fc ef create
queue 3
dot1p 5
exit
dscp be fc "be"
dscp ef fc "ef"
dscp af31 fc "af"
exit
exit
exit
Framed-Route
The majority of residential services in broadband networks have a single registered 32-bit IPv4 address on the WAN side of the RG and a private (RFC 1918) network on the LAN side. Traffic from the LAN toward the BNG (and Internet) is thereafter subject to Network Address and Port Translation (NAPT). However, a common requirement for delivery of business services is the ability for the BNG to recognize one or more IP subnets on the LAN side of the RG that is not subject to NAT, and the subscriber prefix is a route to a network. This is achieved using the standard RADIUS Framed-Route attribute, or dynamic BGP peering. Both serve the function of allowing one or more subnets to be learned at the LNS with a next-hop IP address of the RG WAN.
To provide an example of the use of Framed-Route, the Retail VRF VPRN 2 is again used, and in fact requires no modification in order to support subscribers with Framed-Routes. In general ESM, where Framed-Route is used, there is a requirement to configure anti-spoof type nh-mac, but for LNS SAPs this is the default. The RADIUS users file is updated to also return a Framed-Route attribute for prefix 10.128.46.0/24 with a next-hop determined by the subscriber IP prefix. The prefix has a metric of 10, and has a tag of value 200, which may be used for example, for routing policy.
subscriber2@isp.net Cleartext-Password := "letmein"
Alc-Subsc-ID-Str = "subscriber2@isp.net",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Alc-Serv-Id = "2",
Alc-Interface = "VPRN2-GROUP-INT",
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 10.10.148.22,
Framed-Route = "10.128.46.0/24 0.0.0.0 10 tag 200",
In SR OS, a prefix learned through the Framed-Route attribute is known internally as a Managed Route. Once the subscriber is instantiated, the presence of the Managed Route can be verified as installed.
*A:LNS# show service id 2 ppp session detail | match "Managed Routes"
post-lines 5
Managed Routes
-------------------------------------------------------------------------------
IP Address Status Metric Tag Pref
-------------------------------------------------------------------------------
10.128.46.0/24 installed 10 200 0
-------------------------------------------------------------------------------
*A:LNS#
The Managed Route can also be seen present in the VPRN routing-table, learned through protocol Managed.
*A:LNS# show router 2 route-table protocol managed
===============================================================================
Route Table (Service: 2)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.128.46.0/24 Remote Managed 00h01m33s 0
10.10.148.22 10
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
*A:LNS#
L2TP Tunnel Switching (LTS)
In general, L2TP tunnels are established directly between LAC and LNS. However, if there are a large number of LAC devices (and therefore a large number of L2TP tunnels), it may be desirable to perform some aggregation of these tunnels before presenting them to the LNS. This is implemented by one or more LNS devices performing the function of an L2TP Tunnel Switch (LTS). The LTS terminates multiple L2TP tunnels from the LAC(s), and sources a single L2TP tunnel toward the target LNS, switching L2TP sessions from one tunnel to another tunnel accordingly.
SR OS supports LTS functionality, and from a configuration perspective, it requires no more than L2TP being enabled (no shutdown) in the required routing context if the relevant attributes are returned from RADIUS. As with LNS functions, at least one MS-ISA is required to support LTS functions. In this example, VPRN 1 is used with the previously defined configuration. To recap, this VPRN has a single L2TP group ‟L2TP-GROUP-1”, and within that group, a single tunnel defined ‟L2TP-TUNNEL-1” that terminates the tunnel from the LAC. To demonstrate LTS functionality, the LAC continues to function as a LAC, the LNS functions as an LTS, and PE-1 becomes the LNS.
The RADIUS users file for subscriber1@isp.net is modified to include a number of additional attributes and VSAs. The Alc-Serv-Id and Alc-Interface define the service ID and group interface where the subscriber is terminated, and this can be any IES or VPRN service. The Alc-Tunnel-Serv-Id VSA identifies the service where the L2TP tunnel is initiated. It can be different from the service where the subscriber is terminated, but id does not need to. If it is a different service, then the minimum requirement is that L2TP is placed in a no shutdown state. In this example VPRN 1 terminates the subscriber, and also initiates the L2TP tunnel. The other attributes are standard attributes defined in RFC 2868 for L2TP tunnel setup. The Tunnel-Assignment-Id attribute is used to maintain the concept of groups and tunnels, where Tunnel-Assignment-Id:0 is used to indicate the group name and Tunnel-Assignment-Id:1 is used to indicate the tunnel name. This provides sufficient information for the LTS to initiate an L2TP tunnel without any additional nodal configuration.
subscriber1@isp.net Cleartext-Password := "letmein"
Alc-Subsc-ID-Str = "subscriber1@isp.net",
Alc-Subsc-Prof-Str = "sla-profile-1",
Alc-SLA-Prof-Str = "sub-profile-1",
Alc-Serv-Id = "1",
Alc-Interface = "LNS-GROUP-INT",
Alc-Tunnel-Serv-Id = 1,
Tunnel-Assignment-Id:0 = "RADIUS-returned-Tunnel-Group",
Tunnel-Type:1 += L2TP,
Tunnel-Medium-Type:1 += IP,
Tunnel-Server-Endpoint:1 += 192.168.0.3,
Tunnel-Password:1 += "letmein",
Tunnel-Assignment-Id:1 += "RADIUS-returned-Tunnel-Name",
Tunnel-Client-Auth-Id = "LTS",
The LAC forwards the PPP session into the LAC to LTS tunnel, and after the LTS receives the ICCN from the LAC, it proceeds in authenticating the subscriber. RADIUS returns the preceding attributes with sufficient information for the LTS to instantiate the subscriber and initiates an L2TP tunnel/session with PE-1, the target LNS. The LNS then authenticates the user once more, this time providing it with IP address information through IPCP negotiation. This interaction between PPP client and LNS is transparent to the LTS, which is responsible for switching PPP packets between L2TP sessions. However, the user is instantiated in the system as a full-fledged subscriber.
*A:LNS# show service id 1 ppp session
===============================================================================
PPP sessions for service 1
===============================================================================
User-Name
Descr.
Up Time Type Termination IP/L2TP-Id/Interface-Id MC-Stdby
-------------------------------------------------------------------------------
subscriber1@isp.net
vprn:1 connid:345328060 tid:5269 sid:18876
0d 00:01:42 oL2tp lac 905456423
-------------------------------------------------------------------------------
No. of PPP sessions: 1
===============================================================================
*A:LNS#
Within VPRN 1, two L2TP tunnels are active. The entry with Connection Id 937033728 belongs to group RADIUS-returned-Tunnel-Group (obtained from the Tunnel-Assignment-Id:0 RADIUS attribute) and has tunnel name RADIUS-returned-Tunnel-Name (obtained from the Tunnel-Assignment-Id:1 RADIUS attribute). This is the tunnel from LTS to LNS, and it is in the established state and has one session active. The entry with Connection Id 560005120 is the statically defined tunnel from the LAC, belonging to the CLI-configured group L2TP-GROUP-1 with tunnel name L2TP-TUNNEL-1. This tunnel is also in the established state, with one session active.
*A:LNS# show router 1 l2tp tunnel
===============================================================================
Conn ID Loc-Tu-ID Rem-Tu-ID State Blacklist-state Ses Active
Group Ses Total
Assignment
-------------------------------------------------------------------------------
345309184 5269 12695 established not-blacklisted 1
L2TP-GROUP-1 1
L2TP-TUNNEL-1
905445376 13816 12071 established not-blacklisted 1
RADIUS-returned-Tunnel-Group 1
RADIUS-returned-Tunnel-Name
-------------------------------------------------------------------------------
No. of tunnels: 2
===============================================================================
*A:LNS#
Equally, within VPRN 1, two L2TP sessions are active for subscriber subscriber1@isp.net. Session 937037337 is carried in Tunnel-ID 14298, which, as shown in the previous output, is the tunnel toward the LNS, while session 560030762 is carried in Tunnel-ID 8545, which is the tunnel toward the LAC.
*A:LNS# show router 1 l2tp session
===============================================================================
L2TP Session Summary
===============================================================================
ID Control Conn ID Tunnel-ID Session-ID State
-------------------------------------------------------------------------------
345328060 345309184 5269 18876 established
subscriber1@isp.net
interface: LNS-GROUP-INT
service-id: 1
905456423
905456423 905445376 13816 11047 established
-------------------------------------------------------------------------------
No. of sessions: 2
===============================================================================
*A:LNS#
IPv6
The deployment of IPv6 into residential broadband networks dictates some design choices, or perhaps even some enforced IPv6 address allocation mechanisms:
Bridged or Routed Residential Gateways (RGs).
Numbered or unnumbered WAN.
Stateful (DHCPv6) or stateless (Stateless Address Auto-Configuration, or SLAAC) address assignment.
The purpose of this example is not to show every possibility, but simply to demonstrate that enabling IPv6 is possible at the LNS, just as if this were a conventional BNG doing PPP Termination and Aggregation (PTA). This example uses a widely adopted approach of dual-stack Routed RG with DHCPv6 Prefix Delegation.
The configuration of VPRN 2 is modified to include some IPv6 parameters. In the subscriber-interface context, the delegated-prefix-len command is set to variable indicating that prefixes delegated to subscribers may be of varying length (the default delegated prefix length is /64). The allow-unmatching-prefixes command tells the subscriber interface to operate in an IPv6 unnumbered mode, allowing IPv6 addresses to be allocated to subscribers that do not fall within the range of any IPv6 subnet defined under the subscriber interface. Within the group-interface context, the ipv6 context places router-advertisements into a no shutdown state and has the managed-configuration flag set indicating that stateful (DHCPv6) address configuration is to be used.
Also a dhcp6 proxy-server is enabled, providing an interworking function between the RADIUS server (where the Delegated Prefix is obtained from) and the DHCPv6 client. The proxy will take the RADIUS-provided prefix and responds to the clients Solicit message with an DHCPv6 Advertise message containing the delegated prefix (IA_PD). Because the DHCPv6 messages from the client need to be received over the subscriber PPP session, the proxy-server is configured to allow this using the client-applications ppp command. Finally, there is a static-route for black-holing the /48 IPv6 prefix. The client is allocated a /64 prefix from this range and this static-route is used to provide an aggregated upstream prefix advertisement.
configure
service
vprn 2
subscriber-interface "VPRN2-SUB-INT" create
ipv6
default-dns 2001:db8:2c41::56
delegated-prefix-len variable
allow-unmatching-prefixes
exit
group-interface "VPRN2-GROUP-INT" lns create
ipv6
router-advertisements
managed-configuration
no shutdown
exit
dhcp6
proxy-server
client-applications ppp
no shutdown
exit
exit
exit
exit
exit
static-route-entry 2a00:8010:1b00::/48
black-hole
no shutdown
exit
exit
no shutdown
exit
exit
exit
The RADIUS users file entry for subscriber2@isp.net is also modified to return the IPv6 Delegated Prefix using the standard attribute Delegated-IPv6-Prefix.
subscriber2@isp.net Cleartext-Password := "letmein"
Alc-Subsc-ID-Str = "subscriber2@isp.net",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Alc-Serv-Id = "2",
Alc-Interface = "VPRN2-GROUP-INT",
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 10.10.148.22,
Delegated-IPv6-Prefix = 2001:db8:1b00:100::/64
After the PPP LCP phase and RADIUS authentication, the LNS is aware that the subscriber also has IPv6 enabled (in this case because it received the Delegated-IPv6-Prefix attribute). As a result, the LNS begins to negotiate both IPCP and IPv6CP with the client. For IPv6CP, only an Interface-ID is negotiated, for which the LNS uses an EUI-64 extended version of the chassis MAC address. Once IPv6CP negotiation is completed, the client can initiate a DHCPv6 Solicit for a delegated prefix (IA_PD option). After a successful Advertise/Request/Reply exchange the subscriber is instantiated as dual-stack IPv4/IPv6.
*A:LNS# show service active-subscribers subscriber "subscriber2@isp.net"
===============================================================================
Active Subscribers
===============================================================================
-------------------------------------------------------------------------------
Subscriber subscriber2@isp.net (sub-profile-1)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
(1) SLA Profile Instance sap:[1/2/lns-esm:1.263] - sla:sla-profile-1
-------------------------------------------------------------------------------
IP Address
MAC Address Session Origin Svc Fwd
-------------------------------------------------------------------------------
10.10.148.22
00:00:14:95:29:18 PPP 1 IPCP 2 Y
2001:db8:1b00:100::/64
00:00:14:95:29:18 PPP 1 DHCP6-PD 2 Y
-------------------------------------------------------------------------------
===============================================================================
*A:LNS#
Conclusion
SR OS offers a comprehensive feature set for LNS implementations. The MS-ISA provides the hardware-assist for L2TP encapsulation/de-capsulation while the carrier IOM implements conventional subscriber management functions.