L2TPv2 Technical Overview

This section provides an overview of the operation of the L2TP. Note that although voluntary tunnel mode is discussed, the focus remains on compulsory tunnel mode.

L2TP uses two kinds of messages:

• Control messages Used in L2TP tunnel and session setup, maintenance, and teardown. Control messages are reliably transmitted in-band over a control connection between the LAC and the LNS. Only one control connection is required for each L2TP tunnel regardless of the number of data sessions.

• Data messages Used to transport PPP frames between the LAC and the LNS. Each PPP connection is carried over a separate data session within the L2TP tunnel.

Note that many PPP connections can be carried over a single L2TP tunnel between the LAC and the LNS (theoretically 65,535 connections).

Figure 4-3 shows the control connection and data session between the LAC and the LNS.

Figure 4-3. Control Connection and Data Session Between the LAC and the LNS

[View full size image]

According to RFC 2661, L2TP messages can be carried via a number of packet transports, including UDP, Frame Relay, and ATM. This chapter focuses on transport over UDP.

Figure 4-4 shows the overall format of L2TP packets for both control and data messages.

Note that although a L2TP payload is shown in Figure 4-4, there is one L2TP message that does not include a payload. This is the Zero-Length-Body Acknowledgment (ZLB Ack). ZLB Acks are used to explicitly acknowledge control channel messages.

Control and data message types share a common header.

Figure 4-5 illustrates the L2TP message header.

The L2TP header consists of the following bits and fields:

• The T bit indicates what type of message it is. If the T bit is set to 0, it is a data message, and if the T bit is set to 1, it is a control message.

• The L bit indicates whether the Length field is present. If the L bit is set to 1, the Length field is present. The Length field must be present in all control messages.

• The next two bits in the header (shown as x) must be set to zero. All bits marked as x are reserved for future use and must be set to 0.

• The S bit is the sequence bit, and if set to 1 the Ns (Next sent) and Nr (Next received) fields must be present. The S bit must be set to 1 for control messages.

• The Offset (O) bit, if set to 1, mandates the presence of the Offset field. The Offset bit must be set to zero for all control messages.

• The P bit is the priority bit and indicates whether this message should receive preferential treatment. The P bit is used only with data messages and, therefore, must be set to 0 for all control messages. An example of the usage of the P bit is with LCP Echo-Requests. LCP Echo-Request messages are used as keepalives on the PPP link, and any delay in their processing could potentially lead to the link being dropped.

• The Ver field is 4 bits long and indicates the version of the protocol being used. In this case, the version must be set to 2. You might be a bit confused as to why this is version 2 of L2TP. What happened to version 1 of L2TP, you might be asking. In fact, version 1 was not L2TP at all but instead was L2F. Remember that L2TP is derived from both PPTP and L2F.

• If the L bit is set to 1, after the Ver field comes the Length field. The Length field is 16 bits long and indicates the total length for the message in octets.

• The Tunnel ID and Session ID fields are both 16 bits long. The Tunnel ID uniquely identifies the tunnel. This identifier is locally significant only. Therefore, the same tunnel could have different tunnel IDs at either end. The local tunnel ID is passed by either the LAC or the LNS to its peer in the Assigned Tunnel ID AVP during tunnel setup.

  Figure 4-6 illustrates Tunnel IDs.

  Figure 4-6. L2TP Tunnel IDs

  

  
  

  In Figure 4-6, the L2TP tunnel between SP_LAC1 and CorpX_LNS is identified by tunnel ID 52 at the SP_LAC1 end and by tunnel ID 62 at the CorpX_LNS end.

  Similarly, the tunnel from SP_LAC2 and CorpX_LNS is identified by tunnel ID 51 at the SP_LAC2 end and by tunnel ID 61 at the CorpX_LNS end.

• The Session ID uniquely identifies the data session within the overall tunnel. Again, Session IDs are locally significant only. The same PPP session can have a different Session ID at either end of the tunnel. Local session IDs are passed to the L2TP peer in the Assigned Session ID AVP during session setup.

  Figure 4-7 illustrates session IDs.

  Figure 4-7. L2TP Session IDs

  [View full size image]
  
  
  

  In Figure 4-7, the data session used to carry PPP frames from remote access client A over the L2TP tunnel to the LNS is identified by Session ID 1 at the LAC and by Session ID 11 at the LNS.

  Similarly, the data session used to transport PPP frames from remote access client B over the L2TP tunnel to the LNS is identified by Session ID 2 at the LAC and by Session ID 12 at the LNS.

• After the Session ID come the Ns (Next sent) and Nr (Next received) fields. The Ns field is 16 bits long and indicates the sequence number for this data or control message. The Nr field is also 16 bits long and indicates the sequence number of the next message to be received. Nr serves as an acknowledgment of all messages received with sequence numbers of up to one less than the number specified.

• The two final fields in the message header are the Offset size and Offset pad fields. The Offset size field and the Offset pad field are present only if the O bit is set to 1. The Offset size field indicates the size of the offset pad in octets. The Offset pad is the padding itself. The data to be contained within the Offset pad is undefined in RFC 2661.

Now that the common packet header has been examined, it is now time to examine more closely the precise makeup of the control and data messages. The next section begins with the composition of L2TP control messages.

L2TP Control Messages

Control messages are used to establish, maintain, and tear down L2TP tunnels.

Table 4-1 summarizes the L2TP control message types.

Table 4-1. L2TP Control Message Types

Message Type	Description	Function
1	Start-Control-Connection-Request (SCCRQ)	Control Channel Setup
2	Start-Control-Connection-Reply (SCCRP)	Control Channel Setup
3	Start-Control-Connection-Connected (SCCCN)	Control Channel Setup
4	Stop-Control-Connection-Notification (StopCCN)	Control Channel Teardown
6	Hello (HELLO)	Control Channel Maintenance
7	Outgoing-Call-Request (OCRQ)	Data Session Setup (Outgoing Calls)
8	Outgoing-Call-Reply (OCRP)	Data Session Setup (Outgoing Calls)
9	Outgoing-Call-Connected (OCCN)	Data Session Setup (Outgoing Calls)
10	Incoming-Call-Request (ICRQ)	Data Session Setup (Incoming Calls)
11	Incoming-Call-Reply (ICRP)	Data Session Setup (Incoming Calls)
12	Incoming-Call-Connected (ICCN)	Data Session Setup (Incoming Calls)
14	Call-Disconnect-Notify (CDN)	Data Session Teardown
15	WAN-Error-Notify (WEN)	Call Status
16	Set-Link-Info (SLI)	Call Status

Note that the precise function of each message type is discussed in the following sections.

Control messages are made up of the common packet header and a number of AVPs. AVPs are constructs that are used to indicate the value of a particular variable (the attribute). AVPs allow the L2TP to be very extensible.

AVPs have a common encoding format, as illustrated in Figure 4-8.

Figure 4-8. L2TP AVP Encoding Format

[View full size image]

The bits and fields that make up the L2TP AVP encoding format are as follows:

• The mandatory (M) bit indicates whether recognition of an AVP is mandatory. If the M bit is set (1) on a particular AVP associated with the session, and that AVP is not recognized by the receiving peer, the session must be dropped. If, however, the M bit is not set (0) and the AVP is not recognized by the receiving peer, the AVP can simply be ignored.

  Similarly, if the M bit is set on an AVP associated with the overall tunnel and the AVP is not recognized by the receiving peer, the entire tunnel must be torn down.

  Finally, if the M bit is not set on an AVP associated with an entire tunnel and the AVP is not recognized, it can simply be ignored.

• The hidden (H) bit, if set to 1, indicates that the value or data in the AVP should be hidden. The hiding of data in AVPs is particularly useful when passing sensitive data such as passwords.

  The method of encoding used by hidden AVPs involves hashing the data using the Message Digest 5 (MD5) algorithm, and XORing the resulting values. The precise mechanics of the algorithm are detailed in section 4.3 of RFC 2661.

• The four bits labeled RSVD are reserved bits and must be set to 0.

• The Length field is ten bits long and indicates the overall length of the AVP in octets. The minimum length of the AVP is six. If the length of the AVP is six, the attribute value field itself is not present.

The Vendor-ID field is 16 bits long and allows vendors to implement their own AVPs. The vendor IDs themselves correspond to SMI Network Management Private Enterprise Codes (see RFC 1700). If the value of the vendor-ID field is 0, then the AVP is one of those defined in RFC 2661.

• The Attribute Type field is 16 bits long and indicates the type of message or data being passed in the AVP.

• The Attribute Value field (which is of variable length) indicates the precise value of the message or data being passed in the AVP.

Thirty-eight AVPs are defined in RFC 2661. These fall into the following categories:

• AVPs applicable to all control messages

• The Result Code AVP

• Control connection management AVPs

• Call management AVPs

• Proxy LCP and authentication AVPs

• Call status AVPs

AVPs Applicable to All Control Messages

AVPs applicable to all control messages can, as the category suggests, be carried in any control messages.

Table 4-2 summarizes AVPs applicable to all control messages.

Table 4-2. AVPs Applicable to All Control Messages

Attribute Type	Attribute Name	Description	Present In
0	Message Type	Identifies the control message type	All message types
36	Random Vector	Used with hidden AVPs	All message types

Note, in particular, the Message Type AVP. This must be carried in every control message and is used to specify the control message type itself. See Table 4-1 for a list of message type values carried in this AVP.

Result Code AVP

The Result Code AVP sits in its own category.

Table 4-3 shows a description of the Result Code AVP.

Table 4-3. Result Code AVP

Attribute Type	Attribute Name	Description	Present In
1	Result Code	Indicates the reason for control channel or session teardown. This AVP can also contain an Error Code and Error Message.	CDN / StopCCN

The precise meaning of the result code depends on whether it is carried within the StopCCN or CDN message.

Table 4-4 shows result codes carried in StopCCN messages.

Table 4-4. Result Codes Carried in StopCCN Messages

Result Code	Description
1	General request to clear control connection
2	General error (Error code indicates problem see Table 4-6)
3	Control channel already exists
4	Requestor is not authorized to establish a control channel
5	Protocol version of requestor is not supported
6	Requestor is being shut down
7	Finite state machine error

Table 4-6. Error Code Values

Error Code	Description
0	No general error
1	No control connection exists yet for this LAC/LNS pair
2	Length is wrong
3	One of the fields was out of range or reserved field was nonzero
4	Insufficient resources to handle this operation now
5	The session ID is invalid in this context
6	A generic vendor-specific error occurred on the LAC
7	Try another (the LAC should try another LNS)
8	Session or tunnel was shut down because of receipt of unknown AVP with M-bit set (Error code should contain offending attribute)

Table 4-5 shows result codes carried in CDN messages.

Table 4-5. Result Codes Carried in CDN Messages

Result Code	Description
1	Call disconnected because of loss of carrier
2	Call disconnected for reason indicated by error code (see Table 4-6)
3	Call disconnected for administrative reasons
4	Call failed because of lack of appropriate facilities (temporary condition)
5	Call failed because of lack of appropriate facilities (permanent condition)
6	Invalid destination
7	Call failed because of no carrier detected
8	Call failed because of detection of busy tone
9	Call failed because of lack of dial tone
10	Call was not established within time allotted by LAC
11	Call was connected but no appropriate framing was detected

In addition to the Result Code itself, an Error Code and Error Message can also optionally be carried in the Result Code AVP.

Table 4-6 shows possible Error Code values.

Error messages, if carried, contain human-readable text.

Control Connection Management AVPs

Control connection management AVPs are carried in control messages during control connection setup and teardown.

Table 4-7 summarizes control connection management AVPs.

Table 4-7. Control Connection Management AVPs

Attribute Type	Attribute Name	Description	Present In
2	Protocol Version	Indicates protocol version and revision	SCCRQ / SCCRP
3	Framing Capabilities	Indicates acceptable framing types	SCCRQ / SCCRP
4	Bearer Capabilities	Indicates bearer device types supported	SCCRQ /SCCRP
5	Tie Breaker	Tie breaker in the event of both L2TP peers attempting to set up a tunnel concurrently	SCCRQ
6	Firmware Revision	Indicates the firmware revision	SCCRQ / SCCRP
7	Hostname	Hostname of the LAC or LNS	SCCRQ / SCCRP
8	Vendor Name	String describing type of LAC or LNS	SCCRQ / SCCRP
9	Assigned Tunnel ID	Indicates local tunnel ID to peer	SCCRQ / SCCRP/ StopCCN
10	Receive Window Size	Specifies receive window size to peer (used for flow control)	SCCRQ / SCCRP
11	Challenge	Authentication challenge used during tunnel authentication	SCCRQ / SCCRP
13	Challenge Response	Response to authentication challenge received from peer	SCCRP / SCCCN

Note, in particular, attribute types 11 and 13 (Challenge and Challenge Response). These are used during tunnel authentication.

Call Management AVPs

Call management AVPs are carried in control messages used for data session setup and teardown.

Table 4-8 shows call management AVPs.

Table 4-8. Call Management AVPs

Attribute Type	Attribute Name	Description	Present In
12	Q.931 Cause Code	Indicates ISDN Q.931 cause code in the case of unsolicited call disconnection	CDN
14	Assigned Session ID	Indicates local Session ID to peer	ICRP / ICRQ / OCRQ / OCRP/ CDN
15	Call Serial Number	Indicates globally significant identifier for this call	ICRQ / OCRQ
16	Minimum BPS	Indicates lowest acceptable line speed (bits per second)	OCRQ
17	Maximum BPS	Indicates highest acceptable line speed (bits per second)	OCRQ
18	Bearer Type	Indicate bearer type for call (analog or digital)	ICRQ / OCRQ
19	Framing Type	Indicates framing type for call (synchronous or asynchronous)	ICCN / OCRQ / OCCN
21	Called Number	Number to be called (OCRQ), or called number (ICRQ)	ICRQ / OCRQ
22	Calling Number	The number from which the call was made	ICRQ
23	Sub-Address	Indicates additional dialing information	ICRQ / OCRQ
24	(TX) Connect Speed	(Transmit) speed of facility for call connection attempt	ICCN / OCCN
38	RX Connect Speed	(Receive) Speed of facility for call connection	ICCN / OCCN
25	Physical Channel ID	Identifies physical channel used for call (vendor-specific encoding)	ICRQ / OCRP
37	Private Group ID	Indicates customer group with which call is associated	ICCN
39	Sequencing Required	Indicates that Sequence Numbering must be present on data channel	ICCN / OCCN

Proxy LCP and Authentication AVPs

Proxy LCP and authentication AVPs are carried in the Incoming-Call-Connected (ICCN) message.

During initial call setup between the remote access client and the LAC, the Link Control Protocol (LCP) is negotiated, and the remote access client is partially authenticated.

LCP parameters, together with authentication information, are passed to the LNS by the LAC during data session setup using proxy LCP and authentication AVPs. This information can be used by the LNS to rapidly initialize LCP and authentication, without having to renegotiate them with the remote access client.

Note, however, that should it chose to do so, the LNS can renegotiate both LCP and authentication with the remote access client.

Table 4-9 summarizes proxy LCP and authentication AVPs.

Table 4-9. Proxy LCP and Authentication AVPs

Attribute Type	Attribute Name	Description	Present In
26	Initial Received LCP CONFREQ	Initial CONFREQ received by LAC from remote access client	ICCN
27	Last Sent LCP CONFREQ	Final LCP CONFREQ sent by LAC to remote access client	ICCN
28	Last received LCP CONFREQ	Final LCP CONFREQ received by LAC from remote access client	ICCN
29	Proxy Authen Type	Indicates authentication type used by LAC with remote access client	ICCN
30	Proxy Authen Name	Specifies the name used by the remote access client during authentication with the LAC	ICCN
31	Proxy Authen Challenge	Indicates the challenge sent by the LAC to the remote access client during authentication	ICCN
32	Proxy Authen ID	Specifies the ID used during authentication between the LAC and remote access client	ICCN
33	Proxy Authen Response	Specifies the authentication response received by the LAC from the remote access client	ICCN

Call Status AVPs

Call status AVPs are carried in control messages to communicate error information or negotiated Asynchronous Control Character Map (ACCM) values.

Table 4-10 shows call status AVPs.

Table 4-10. Call Status AVPs

Attribute Type	Attribute Name	Description	Present In
34	Call Errors (WEN)	Used by LAC to communicate error information to the LNS	WEN
35	ACCM (SLI)	Used by the LNS to communicate ACCM to LAC	SLI

AVPs are sent in combination depending upon the specific control message type being sent. The function of specific control messages is explained in the following sections.

Now that the format of both control and data message types has been detailed, it is time to examine the behavior of L2TP with regard to tunnel establishment, maintenance, and teardown.

L2TP Tunnel (Control Connection) Establishment

The establishment of a L2TP tunnel involves the reception of a call from a remote system on the LAC (assuming an incoming call), the establishment of a control connection between the LAC and the LNS, and the establishment of data sessions to carry PPP frames between remote access clients and the LNS.

As mentioned, the first event involved with tunnel establishment is the reception of a call from a remote access client on the LAC. The LAC then negotiates the LCP, and partially authenticates the remote access client. Information regarding LCP negotiation and authentication is later passed to the LNS during session setup.

Based upon the domain name of the remote access client (contained within the remote access client's username), the Dialed Number Identification Service (DNIS) string, or the complete remote access client username (if using per-user virtual private dialup networks [VPDN]), the LAC associates the PPP call to a L2TP tunnel to a particular LNS.

Note that the DNIS is the number that the remote access client dials to connect to the LAC, and it is passed to the LAC in ISDN Q.931 messages during call setup.

When using per-user VPDN, the LAC sends the complete remote access client username to the AAA server, and the AAA server sends back tunnel information for that username.

Figure 4-9 illustrates call reception, LCP negotiation, and partial authentication.

Once the LAC has associated the remote access client's PPP session with a L2TP tunnel, it begins to forward the PPP session over the tunnel, if it already exists. If the tunnel does not yet exist, the LAC begins the establishment of the tunnel.

This section assumes that there is no existing tunnel between the LAC and the LNS. It is worth emphasizing at this point that a tunnel between a particular LAC and LNS is capable of carrying multiple PPP sessions within it.

The first stage in the establishment of the L2TP tunnel between the LAC and the LNS is the setup of the control connection. Setup of the control connection is initiated by the LAC using a Start-Control-Connection-Request (SCCRQ) message. Assuming that the LNS has sufficient resources, and the LAC is authorized to build a tunnel, the LNS responds with a Start-Control-Connection-Reply (SCCRP) message. The SCCRP message indicates to the LAC that it can proceed with control connection establishment. The LAC then responds to the LNS with a Start-Control-Connection-Connected (SCCCN) message. This is used to confirm the establishment of the control connection. Finally, if there are no other messages waiting in the queue to be sent from the LNS to the LAC, the LNS acknowledges the SCCCN using a ZLB ACK message.

Information contained within AVPs that is exchanged by the LAC and the LNS during L2TP tunnel setup includes (but is not limited to) L2TP version number, hostname, assigned tunnel IDs, as well as authentication challenges and challenge responses (if authentication is enabled). For a complete list of AVPs that can be exchanged in SCCRQ, SCCRP, and SCCCN messages, see Table 4-7.

It is worth noting that RFC 2661 does define an optional tunnel authentication mechanism. This allows the LNS to authenticate the LAC and vice-versa before allowing establishment of the tunnel. The password used in tunnel authentication takes the form of a single shared secret. This password is also used with AVP hiding (if enabled).

Note that AVP hiding can be enabled on Cisco routers using the l2tp hidden command (under the VPDN group).

Figure 4-10 illustrates establishment of the control connection between the LAC and the LNS.

Once the control connection has been established between the LAC and the LNS, data session establishment is ready to begin.

L2TP Session Establishment

Session establishment involves the establishment of a data session over the tunnel. PPP frames passing between the remote access client and the LNS are then carried over this data session.

The first message in the establishment of a data session is the Incoming-Call-Request (ICRQ) message. If there are sufficient resources available and the new session should be administratively permitted, the LNS responds to the LAC's ICRQ message with an Incoming-Call-Reply (ICRP) message. The LAC then responds with an ICCN message. This indicates that the LAC is proceeding with session establishment. If no other messages are waiting to be sent to the LAC, the LNS acknowledges the ICCN with a ZLB Ack.

During session setup, information contained in AVPs that is exchanged between the LAC and the LNS includes (but is not limited to) assigned session IDs, called number, calling number, connect speed, as well as proxy LCP and authentication information. See Tables 4-8 and 4-9 for a complete list of AVPs that can be exchanged in ICRQ, ICRP, and ICCN messages.

Figure 4-11 shows establishment of an L2TP session between the LAC and the LNS.

At this point, the L2TP tunnel and a data session within it to transport PPP frames have been established between the LAC and the LNS. The LAC now begins to forward PPP frames from the remote access client over the L2TP tunnel to the LNS.

It is worth briefly examining in what form PPP frames from the remote access client are forwarded over the tunnel (data session). The LAC does not send the complete PPP frame received from the remote access client to the LNS. Instead, redundant information such as Frame Check Sequence (FCS), link framing, and transparency bytes are stripped from the PPP frames received from the remote access client. The resulting PPP frame is encapsulated in a L2TP packet and forwarded over the tunnel to the LNS. The same process happens in reverse for PPP frames being forwarded from the LNS to the remote access client.

Once a data session has been established, LCP negotiation and PPP authentication are completed, and Network Control Protocol (NCP) negotiation takes place between the remote access client and the LNS.

Figure 4-12 illustrates LCP negotiation, PPP authentication, NCP negotiation, and PPP frame forwarding between the remote access client and the LNS.

L2TP Tunnel Maintenance

Now that the setup of the L2TP tunnel and data sessions has been described, it is now time to describe the mechanism that is used to maintain the tunnel.

RFC 2661 describes a keepalive mechanism used to maintain the L2TP tunnel during an extended period of inactivity. This keepalive mechanism takes the form of L2TP hello control messages sent over the control connection. If no other messages are waiting to be sent, hello messages are acknowledged with a ZLB Ack.

Figure 4-13 illustrates the keepalive mechanism used between the LAC and the LNS.

Note that L2TP hello messages can be sent by either the LAC or the LNS.

There a default inactivity interval of 60 seconds before a hello message is sent.

L2TP Session Teardown

Session teardown can occur for a number of reasons. The most common is that the remote access client disconnects from the LAC.

Session teardown can be initiated by either the LAC or the LNS and is signaled by the Call-Disconnect-Notify (CDN) message. Upon receipt of the CDN, the L2TP peer acknowledges with a ZLB Ack message, assuming that no other messages are waiting to be transmitted.

Figure 4-14 illustrates session teardown.

The reason for the session teardown is given by the reason code carried in the CDN (see Table 4-5).

L2TP Tunnel Teardown

There are a number of reasons for tunnel teardown. One reason might be that the last data session within the tunnel is terminated, although teardown is not mandatory. Also, a tunnel might be torn down if it is manually cleared.

Tunnel teardown can be signaled by either the LAC or the LNS using the Stop-Control-Connection-Notification (StopCCN) message. If no other messages are waiting to be transmitted, the L2TP peer will acknowledge the StopCCN with a ZLB Ack.

Figure 4-15 shows tunnel teardown.

The reason for the tunnel teardown is given by the reason code carried in the StopCCN (see Table 4-4).

Other L2TP Messages

Other message types used on the control connection are the WAN-Error-Notify (WEN) message and the Set-Link-Info (SLI) message.

WEN Message

The WEN message is used by the LAC to inform the LNS when errors occur on the PPP interface connected to the remote access client. Note that this error message should not be sent more than once every 60 seconds.

Assuming that no other messages are waiting to be transmitted, the L2TP peer acknowledges receipt of the WEN with a ZLB Ack message.

Figure 4-16 illustrates transmission of the WEN message.

SLI Message

The SLI message is sent by the LNS to the LAC to set PPP negotiated options. At present in L2TPv2, the SLI message can be used only to update the PPP ACCM.

Assuming that no other messages are waiting to be transmitted, receipt of the SLI is acknowledged with a ZLB Ack message.

Figure 4-17 illustrates transmission of the SLI message from the LNS to the LAC.

Outgoing Calls

L2TP has the additional capability of making outgoing calls. This means that the LNS can signal the LAC to place an outgoing call to a remote client.

Outgoing call initiation is signaled by the LNS to the LAC using an Outgoing-Call-Request (OCRQ) message. Upon receipt of the OCRQ, the LAC determines whether proper facilities exist to make the outgoing call. If those facilities exist, the LAC responds to the LNS using an Outgoing-Call-Reply (OCRP) message. The LAC then attempts to complete the outgoing call and, if successful, informs the LNS using an Outgoing-Call-Connected (OCCN) message. If no other messages are waiting to be transmitted, the OCCN is acknowledged by the LNS with a ZLB Ack message.

Information contained within AVPs that is exchanged by the LNS and the LAC during outgoing call setup includes (but is not limited to) assigned session IDs, minimum and maximum bits per second (bps), bearer type, called number, and connect speed. For a complete list of AVPs that may be exchanged in OCRQ, OCRP, and OCCN messages, see Table 4-8.

Figure 4-18 illustrates outgoing call initiation.

Note that Figure 4-18 assumes that a L2TP tunnel has already been established between the LAC and the LNS.

L2TP Security

Although the only inherent security provided by L2TP itself (as distinct from PPP) is tunnel authentication and hidden AVPs, additional security can be provided by configuring the L2TP tunnel over IPSec. IPSec can provide packet level security via the Encapsulating Security Payload (ESP) or the Authentication Header (AH) protocols.

ESP is a protocol that can provide confidentiality, data origin authentication, antireply, and data integrity services. AH can provide data integrity, data origin authentication, and antireply services.

Figure 4-19 shows L2TP tunnel security using IPSec.

For more information on L2TP security, see RFC 3193. For more information on IPSec, see Chapter 8, "Troubleshooting IPSec VPNs."

Configuring L2TPv2

Although L2TPv2 configuration is not the primary objective of this chapter, it is worthwhile to review basic L2TPv2 configuration on Cisco routers. L2TPv2 configuration is discussed in this section.

Configuring L2TP Compulsory Tunnel Mode

There are several steps in the configuration of both the LAC and the LNS in compulsory tunnel mode. Each will be examined in turn.

Configuring the LAC

The steps involved in the configuration of the L2TP LAC are summarized below. Note that this configuration assumes that the LAC is configured with a Primary Rate ISDN interface, together with internal digital (MICA) modems.

The next few sections discuss each step in depth.

Step 1: Configure the E1/T1 Controllers

The first step is the configuration of the E1 or T1 controllers. This involves specifying the framing, linecode, clock source, and timeslots. These parameters should be configured per your service provider's specifications.

Example 4-1 shows an example of the configuration of an E1 Controller.

Example 4-1. Configuring the E1 Controller

controller E1 0/0
 pri-group timeslots 1-31

You'll notice in this configuration that only the pri-group timeslots are specified. This is because this configuration is making use of the default framing (CRC4), linecode (HDB3), and clock source (line). To modify framing, linecode, and clock source, use the framing {crc4 | no-crc4}[australia], linecode {ami | hdb3}, and clock source {line | internal | loop-timed} commands, respectively.

Step 2: Configure Global ISDN Parameters

After configuring the E1 or T1 controller, the next step is to configure global ISDN parameters. In this case, only configuration of the global ISDN switch-type is required.

Example 4-2 shows configuration of global ISDN parameters.

Example 4-2. Configuring the Global ISDN Switch Type

isdn switch-type primary-net5

The ISDN switch-type configured is Primary-net5, a switch-type common in Europe, Australia, New Zealand, and Asia.

Again, the ISDN switch type should be configured per your service provider's recommendation.

Step 3: Configure the D Channels

The next step is to configure the ISDN D channel or channels.

Example 4-3 shows configuration of a D channel.

Example 4-3. Configuring the D channel

interface Serial0/0:15
 no ip address
 encapsulation ppp
 isdn switch-type primary-net5
 isdn incoming-voice modem

No IP address is applied to interface serial 0/0:15 in Example 4-3 because no ISDN calls are being terminated on this LAC. PPP encapsulation is then applied using the encapsulation ppp command.

The ISDN switch-type is set with the command isdn switch-type primary-net5. Note that the ISDN switch-type applied to an interface takes precedence over that applied globally, although in this case they are the same.

The isdn incoming-voice modem causes incoming asynchronous calls to be rerouted to the internal digital (MICA) modems.

Step 4: Configure Parameters for Asynchronous Lines

Once the D channel configuration has been completed, the next step is the configuration of the modems and their corresponding asynchronous lines.

Example 4-4 shows configuration of the asynchronous lines.

Example 4-4. Configuring the Asynchronous Lines

line 3338
 modem InOut
 modem autoconfigure type mica
 autoselect ppp

The first line in Example 4-4 (line 33-38) allows lines 33 to 38 to be configured in one go. Lines 33 to 38 correspond to the six internal MICA modems installed on the LAC. The show line command can be used to confirm the line numbering of internal modems.

The next line shows the modem InOut command. The modem InOut command is used to configure the modems so that they are able to both receive and make calls.

Following modem InOut is modem autoconfigure type mica. This command allows the LAC to configure the internal modems automatically.

In the last line is the autoselect ppp command. This allows PPP to be autodetected and configured on the line.

Step 5: Configure Group Asynchronous Interfaces

Once the modem lines have been configured, it is time to configure the corresponding asynchronous interfaces. Logical configuration, such as IP addresses, is applied to the asynchronous interfaces. Again, the most efficient way to configure the asynchronous interfaces is in a group.

Example 4-5 shows configuration of the asynchronous interfaces.

Example 4-5. Configuring the Asynchronous Interfaces

interface Group-Async1
 no ip address
 encapsulation ppp
 async mode interactive
 no peer default ip address
 ppp authentication chap
 group-range 33-38

The first command is no ip address. The no ip address command is required in this example because no PPP connections from remote access clients are being terminated locally on the LAC (rather than being tunneled to the LNS).

Next is encapsulation ppp. This command is used to apply PPP encapsulation.

The next command is async mode interactive. This allows remote users connecting to the asynchronous interfaces to start interactive mode on the line. Should you wish to limit remote users so that an interactive session cannot be started, the command async mode dedicated should be used. The async mode dedicated command allows only PPP or SLIP sessions (but not exec sessions) on the interface.

The no peer default ip address command is used to ensure that no IP address is supplied by the LAC to the remote access client. IP addresses are supplied to remote access clients by the LNS.

The next line of the configuration in Example 4-5 contains the command ppp authentication chap. This command is used to configure the Challenge Handshake Authentication Protocol (CHAP) on the asynchronous interfaces. CHAP authentication is assumed throughout this chapter. You might be wondering why, if the PPP session from remote access clients are to be tunneled from the LAC to the LNS, CHAP authentication is required on the LAC at all. It's required to authenticate partially L2TP remote access clients.

When the remote access client dials in to the LAC, the LAC partially authenticates the remote access client. This partial authentication consists of a CHAP challenge sent by the LAC and a response from the remote access client. Contained within the response message is the remote access client's username, and within that, its domain name (in the format @domain_name). The domain name is then used to associate the remote access client's PPP session to the appropriate L2TP tunnel.

Note that it is also possible to associate the remote access client's PPP session with the appropriate tunnel using the DNIS or the complete username (with per-user VPDN). The DNIS corresponds to the number dialed by the remote access client to connect to the LAC.

The final command in Example 4-5 is group-range 33-38. This command is used to apply the group-async configuration to each of the internal digital modem lines in turn.

Step 6: Configure Remote AAA (Optional)

The next optional step in configuring the LAC is the configuration of remote authentication, authorization, and accounting (AAA).

Two methods that can be used for remote AAA are the Remote Authentication Dial-In User Service (RADIUS) and Terminal Access Controller Access Control Server plus (TACACS+). In this environment, RADIUS is more common.

PPP connections (from remote access clients and tunneled by the LAC) are terminated on the LNS. Therefore, remote AAA is necessary on the LAC only if you are configuring per-user VPDN or you are using tunnel definitions (tunnel configuration stored on a AAA server). If you are terminating some PPP connections locally on the LAC rather than tunneling them to the LNS, remote AAA may also be useful.

Example 4-6 shows a sample remote AAA configuration.

Example 4-6. Configuring Remote AAA

aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.20.10.5 auth-port 1645 acct-port 1646 key cisco

The first line in Example 4-6 is the aaa new-model command. This command is simply used to enable remote AAA on the LAC.

The next command in Example 4-6 is aaa authentication login default group radius local, which configures the default method list for logins to the LAC. The first authentication method used with the default method list is RADIUS. Should the RADIUS server be unreachable, the LAC defaults to local authentication to authenticate login users.

The default method list is applied on any lines not explicitly configured with another method list. Note that the aaa authentication login default group radius local command is not necessary for L2TPv2 but is included here as part of a complete AAA configuration.

Next is the aaa authentication ppp default group radius command. This command configures the default method list for PPP authentication on the LAC. The method list specifies RADIUS authentication.

The fourth line in the configuration (aaa authorization network default group radius) is used to configure authorization for network connections from the LAC. Once again, network authorization is configured using the default method list. In this case, RADIUS is specified by the method list for authorization of network connections.

Following network authorization, AAA accounting is configured for network connections using the default method list (aaa accounting network default start-stop group radius). Accounting is configured on start and stop events. This means that an accounting notification is sent to the RADIUS server when a network connection is initiated. Similarly, an accounting notification is also sent to the RADIUS server when that network connection is terminated.

The aaa accounting network default start-stop group radius command is again not necessary for L2TPv2 but is shown as part of a complete AAA configuration.

The final line of the configuration is the radius-server host command. This command is used to specify the IP address of the RADIUS server (in this case 10.20.10.5). You also notice that the port on which authentication and authorization requests are sent is UDP port 1645, with accounting requests being sent on UDP port 1646. These two ports are the defaults for Cisco routers, but note that some RADIUS servers might require you to configure authentication and authorization on port 1812 and accounting on port 1813.

The final part of the radius-server host command is the key parameter. This corresponds to the secret key used to authenticate communications between the RADIUS server and the LAC. This key is also used to encrypt user passwords sent to the RADIUS server.

See "Case Study 1: Misconfigured L2TP Tunnel Definition on an AAA RADIUS Server" for more details on tunnel definitions and Cisco.com for more details on per-user VPDN.

Step 7: Globally Enable VPDNs

The next step in the configuration of the LAC is to enable VPDNs globally, of which L2TP is one type. Other types are L2F and PPTP.

To enable VPDNs globally, use the following command:

vpdn enable

Step 8: Configure VPDN Groups

The final mandatory step in the configuration of the LAC is the configuration of the L2TP tunnel itself. The configuration of the L2TP tunnel can be stored locally on the LAC in the form of a VPDN group, or it can be stored on the RADIUS server in the form of a tunnel definition.

Example 4-7 shows an example of the configuration of a VPDN group.

Example 4-7. Configuring the VPDN Group

vpdn search-order domain
vpdn-group 1
 request-dialin
  protocol l2tp
  domain mjlnet.com
 initiate-to ip 172.16.5.5
 l2tp tunnel password cisco

The first command in Example 4-7 is vpdn search-order domain. This command is optional, and it is used to specify that the LAC will attempt to associate the remote access client's PPP session with an L2TP tunnel using a domain name. The default search order is DNIS, then domain.

Note that the dnis string VPDN group configuration command can be used to associate a DNIS string (number) with an L2TP tunnel.

The second line in the configuration is the command vpdn-group 1. This command is used to begin the configuration of the VPDN group 1. The 1 is actually the VPDN group name.

In line 3 is the request-dialin command. The request-dialin command is used to configure the LAC to accept remote access client PPP sessions and attempt to tunnel them to a specified LNS.

Following request-dialin is the protocol l2tp command. It will come as no surprise to learn that this command is used to specify that the VPDN protocol to be used when building tunnels is L2TP.

The fifth line of the configuration is domain mjlnet.com. This command is used to configure the VPDN group so that any remote access clients with a domain name corresponding to mjlnet.com will have their PPP sessions tunneled to the LNS specified in this VPDN group. Note that it is possible to specify more than one domain name per VPDN group.

The next line is the initiate-to ip 172.16.5.5 command, which is used to specify the address of the LNS to which the tunnel will be built.

The final command is l2tp authentication password cisco, which is used to specify the shared secret used to authenticate the LNS to the LAC and the LAC to the LNS. In this example, the shared secret is cisco.

Example 4-8 shows a complete basic configuration for a LAC.

Example 4-8. Complete Basic LAC Configuration

CalCity_LAC#show running-config
Building configuration...
Current configuration : 1896 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname CalCity_LAC
!
logging buffered 16384 debugging
enable secret 5 $1$FLX7$fBY0xo2WPq/bpSLs/IlVw0
!
username mark password 7 05080F1C2243
ip subnet-zero
no ip source-route
!
no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2TP)
vpdn enable
! Match the remote access client's domain for client to tunnel assignment
vpdn search-order domain
!
! Configure the VPDN group for domain mjlnet.com to 172.16.5.5 (the LNS)
vpdn-group 1
 request-dialin
  protocol l2tp
  domain mjlnet.com
 initiate-to ip 172.16.5.5
 l2tp tunnel password 7 045802150C2E
!
! Configure the PRI switch type
isdn switch-type primary-net5
!
! Configure the E1 controller
controller E1 0/0
 pri-group timeslots 1-31
!
interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 duplex auto
 speed auto
!
! Configure the D channel
interface Serial0/0:15
 no ip address
 encapsulation ppp
 isdn switch-type primary-net5
 isdn incoming-voice modem
 no peer default ip address
 ppp authentication chap
!
! Configure the group asynchronous interface
interface Group-Async1
 ip unnumbered FastEthernet0/0
 encapsulation ppp
 async mode interactive
 no peer default ip address
 ppp authentication chap
 group-range 33 38
!
! Static route for IP reachability to the LNS (172.16.5.5)
ip route 172.16.5.0 255.255.255.0 172.16.1.2
!
ip classless
no ip http server
ip pim bidir-enable
!
no cdp run
!
line con 0
 password 7 13081D1E050910
 logging synchronous
 login
!
! Configure parameters for asynchronous lines
line 33 38
 modem InOut
 modem autoconfigure type mica
 autoselect ppp
line aux 0
line vty 0 4
 password 7 0456010A012458
 login
!
end

Note that in Example 4-8, a static route is used for IP reachability between the LAC and the LNS.

That completes the examination of LAC configuration.

Configuring the LNS

Configuration of the LNS can be summarized as follows:

Step 1: Globally Enable VPDNs

The first step in the configuration of the LNS is to globally enable VPDNs on the LNS.

VPDNs can be globally enabled on the LNS using the following command:

vpdn enable

Step 2: Configure VPDN Groups

After globally enabling VPDNs, the next step is the configuration of the VPDN group or groups.

Example 4-9 shows the configuration of a VPDN group.

Example 4-9. Configuring the VPDN Groups

vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp tunnel password cisco

The first line in the configuration given in Example 4-9 is the vpdn-group name command. In this example, 1 is the VPDN group name.

The next line is the accept-dialin command. This command is used on the LNS to specify that tunnels and sessions will be accepted from the LAC.

The next part of the configuration is the specification of the VPDN protocol. This is configured using the protocol l2tp command.

The fourth line is the virtual-template virtual-template_number command. In this example, this command causes any PPP sessions inbound through the tunnel from the LAC to be terminated on virtual-access interfaces with configuration cloned (copied) from virtual template interface 1.

Virtual-access interfaces are virtual interfaces that are dynamically created as required and take their configuration from a virtual template interface. One virtual access interface is created per PPP session.

Once the virtual template interface has been specified, the next step is to allow termination of VPDN tunnels from the specified LAC, using the terminate-from hostname command. In this case, VPDN tunnels from CalCity_LAC are allowed.

The final step is the shared L2TP tunnel password. This is configured using the l2tp authentication password command.

If you do not wish to use tunnel authentication, it can be disabled using the no l2tp tunnel authentication command (on both the LAC and LNS). Note that disabling L2TP tunnel authentication is not, generally speaking, a good idea, for obvious reasons.

Step 3: Configure the Virtual Templates

After configuring the VPDN group, the next step is the configuration of the virtual template interface.

Example 4-10 shows the configuration for a virtual template interface.

Example 4-10. Configuring Virtual Template Interfaces

interface Virtual-Template1
 ip unnumbered Ethernet1/0
 peer default ip address pool SKYDANCE_POOL
 ppp authentication chap
 ppp multilink

The configuration of the virtual template interface begins with the command ip unnumbered ethernet 0/0. This is used to specify that the IP address configured on the Ethernet 0/0 interface should be borrowed for the virtual template interface. In this case, the LNS has only two interfaces (see Example 4-15), but if your LNS has more than two interfaces, a loopback interface is a better choice for use with the ip unnumbered command (it is always up).

Next is the peer default ip address pool pool_name command. This specifies that remote access clients should be assigned an IP address from the specified pool, which in this example is SKYDANCE_POOL.

Another option for IP address assignment is the Dynamic Host Configuration Protocol (DHCP). This can be specified using the peer default ip address dhcp and ip dhcp-server {server_name | server_ip_address} commands.

Example 4-11 shows the configuration for assigning IP addresses to remote access clients using DHCP.

Example 4-11. Assigning IP Addresses to Remote Access Clients Using DHCP

ip dhcp-server 172.16.4.1
!
interface Virtual-Template1
 peer default ip address dhcp
!

In Example 4-11, the ip dhcp-server {server_name | server_ip_address} global configuration command is used to specify the DHCP server name or IP address. The peer default ip address dhcp interface configuration command is then used to specify that addresses should be assigned to clients using DHCP.

The third line in the configuration (in Example 4-10) is the ppp authentication chap command. This command ensures that PPP sessions from remote access clients are authenticated using CHAP.

The final command in the configuration of virtual template is the optional ppp multilink command. This command enables multilink PPP (MP).

Note that it is also possible to store user-specific interface configuration on a AAA server, and this configuration is downloaded to the Home Gateway as remote access clients connect. For some examples of this (in the form cisco-avpair = "lcp:interface-config=") refer to the document entitled "Configuring Virtual Profiles" on www.cisco.com.

Another command that might be useful on the virtual template interface is the mtu command. This can help to prevent fragmentation of large packets sent over the L2TP tunnel, which can cause high CPU overhead as fragmentation and reassembly is handled at the process level. Fragmentation can occur because of the tunnel protocol overhead added by L2TP itself (40 bytes without sequencing).

When the mtu command is configured in conjunction with the lcp renegotiation (VPDN group) command, the LNS is allowed to renegotiate the Maximum Receive Unit (MRU) with the remote access client, although this is effective with only some client operating systems. MRU is negotiated as part of LCP, and by default, LCP is negotiated only between the remote access client and the LAC. The LAC then informs the LNS of negotiated LCP options during L2TPv2 session setup.

It is also worth noting that cloning of virtual access interfaces on the LNS can cause high CPU overhead. This can be reduced using the virtual-template template_number pre-clone number command to preclone virtual access interfaces.

Step 4: Create IP Pools and Configure DNS/WINS Server Addresses

The next step is the configuration of the local IP address pool and BootP DNS and WINS server addresses. Note that although in this case a local IP address pool is used, IP address assignment via DHCP (see "Step 3: Configure the Virtual Templates") or from a AAA server can also be used. Example 4-12 shows the configuration of a local IP address pool and DNS and WINS server addresses.

Example 4-12. Configuring the IP Address Pool and DNS/WINS Server Addresses

ip local pool SKYDANCE_POOL 10.1.1.1 10.1.1.50
async-bootp dns-server 10.2.2.99
async-bootp nbns-server 10.2.2.100

In Example 4-12, an IP address pool named SKYDANCE_POOL is created. The pool name must correspond to that given in the virtual template interface configuration. In this case, there are 50 IP addresses in the local IP address pool (10.1.1.1 to 10.1.1.50). DNS and WINS server addresses are also specified (10.2.2.99 and 10.2.2.100, respectively).

Step 5: Configure Either Local Authentication or Remote AAA

The last step in the configuration of the LNS is the configuration of either local authentication or remote AAA for remote access clients.

Local authentication can be configured by simply specifying usernames and passwords.

Example 4-13 shows the configuration of usernames and passwords for local authentication.

Example 4-13. Configuring Local Authentication

username TATEBAYASHI@mjlnet.com password cisco1
username joebloggs@mjlnet.com password cisco2
username ltahoe@mjlnet.com password cisco3

A more scalable solution is to configure remote AAA on the LNS. In this example, RADIUS is used for remote AAA.

Example 4-14 shows a sample configuration for remote AAA.

Example 4-14. Configuring Remote AAA

aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.20.10.5 auth-port 1645 acct-port 1646 key cisco

The aaa new-model command is used to enable AAA on the LNS.

The second command in the configuration is the aaa authentication login default group radius local, which configures the default method list for logins to the LNS. The first authentication method in the default method list is RADIUS. If the RADIUS server is unreachable, then the LNS will default to local authentication.

The aaa authentication login default group radius local command is not required for L2TPv2 but is shown here as part of a complete AAA configuration.

Next comes the aaa authentication ppp default group radius command, which defines a default method list for PPP. The method specified for authentication is RADIUS.

The fourth line in the configuration contains the command aaa authorization network default group radius, which configures a default method list for network connections, with RADIUS specified for authorization.

The aaa accounting network default start-stop group radius command is next. Accounting is configured on start and stop events. When a network connection is initiated, an accounting notification is sent to the RADIUS server. Furthermore, when that network connection is terminated, an accounting notification is also sent to the RADIUS server. Again, the aaa accounting network default start-stop group radius is not required for L2TPv2 but is shown as part of a complete AAA configuration.

The final command is radius-server host, which specifies the IP address of the RADIUS server, as well as the UDP ports for authentication/authorization and accounting (1645 and 1646, respectively).

The key parameter is the secret key used to authenticate communications between the RADIUS server and the LNS. It is also used to encrypt user passwords sent to the RADIUS server.

Example 4-15 shows a complete basic configuration for the LNS using local authentication.

Example 4-15. Complete Basic LNS Configuration

Skydance_LNS#show running-config
Building configuration...
Current configuration : 2224 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Skydance_LNS
!
logging buffered 16384 debugging
enable secret 5 $1$48vv$OokKQ69up4Kf95QMo.k5L.
!
username mark password 7 121A0C041104
! Configure the username and password database for remote access clients
username TATEBAYASHI@mjlnet.com password 7 14141B180F0B
username joebloggs@mjlnet.com password 7 00071A150754
username ltahoe@mjlnet.com password 7 1043080B0E
ip subnet-zero
no ip source-route
ip cef
!no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2TP)
vpdn enable
!
!  Configure the VPDN group for CalCity_LAC
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp tunnel password 7 01100F175804
!
! Configure the DNS and WINS server addresses
async-bootp dns-server 10.2.2.99
async-bootp nbns-server 10.2.2.100
!
interface Ethernet1/0
 ip address 172.16.5.5 255.255.255.0
 no ip redirects
 no ip proxy-arp
!
interface Ethernet1/1
 ip address 10.2.2.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
!
!
! Configure the virtual template
interface Virtual-Template1
 ip unnumbered Ethernet1/0
 peer default ip address pool SKYDANCE_POOL
 ppp authentication chap
 ppp multilink
!
! Static route for IP reachability to the LAC (CalCity_LAC)
ip route 172.16.1.0 255.255.255.0 172.16.5.1
!
! Configure the IP address pool
ip local pool SKYDANCE_POOL 10.1.1.1 10.1.1.50
ip classless
no ip http server
ip pim bidir-enable
!
no cdp run
!
line con 0
 password 7 05060C032F495A logging synchronous
 login
line aux 0
line vty 0 4
 password 7 07022B40400C0D
 login
!
end

As a final word before completing this section, many problems can be avoided by configuring both the LAC and the LNS incrementally. For example, when configuring the LAC, first configure and verify basic asynchronous dialin. Then configure and enable VPDN groups. Also, even if the intent is to use remote AAA, it might be a good idea first to configure local authentication to test the VPDN configuration before introducing remote AAA.

Configuring L2TP Voluntary Tunnel Mode

Configuration of L2TP voluntary tunneling mode is similar to that of compulsory tunneling mode. The main difference is that the Cisco router acts as the LNS, with a remote access client acting as the LAC. The configuration of the LNS remains largely the samethe difference is the configuration of the VPDN group.

Example 4-16 shows the configuration of the VPDN group in voluntary tunneling mode.

Example 4-16. VPDN Group Configuration for L2TP Voluntary Tunnel Mode

vpdn-group 1
!
 accept-dialin
  protocol l2tp
  virtual-template 1
 no l2tp tunnel authentication

There are two differences in the configuration of the VPDN group when compared to that for compulsory tunnel mode:

• The terminate-from command is not required.

• L2TP tunnel authentication is disabled with the command no l2tp tunnel authentication.

In this case, PPP authentication (configured on the virtual template interface using the ppp authentication command) is used to authenticate the client/LAC.

Configuring IPSec Protection for L2TP in Compulsory Tunnel Mode with Preshared Keys

The configuration of IPSec for L2TP with preshared keys can be broken down into six steps. The steps are as follows:

Example 4-17 shows the configuration of IPSec on the LAC.

Example 4-17. Configuring IPSec on the LAC

!
 vpdn-group 1
  request-dialin
  protocol l2tp
  domain mjlnet.com
 initiate-to ip 172.16.5.5
 l2tp security crypto-profile l2tp
 l2tp tunnel password cisco
!

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key mark address 172.16.5.5
!

crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
 mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
 set transform-set l2tptransform
!

interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
 duplex auto
 speed auto
 crypto map l2tpcryptomap
!

In highlighted line 1, IPSec protection for L2TP tunnels is configured. Note the policy name referenced (l2tp).

Highlighted lines 2 and 3 show the configuration of the IKE policy. This policy configures authentication with preshared keys, encryption as DES, Diffie-Hellman group 1 (768-bit), and the lifetime as 86,400 seconds (1 day). All of these parameters are the defaults, except for preshared key authentication, and so are not displayed in the configuration.

Configuration of the preshared key (mark) and peer address (the LNS, 172.16.5.5) is shown in highlighted line 4. Note that this preshared key (mark) is not secure, and is used for illustrative purposes only.

The transform set is configured next (highlighted lines 5 and 6). The name of the transform set is l2tptransform, and it specifies ESP DES encryption and SHA-1 authentication. Note that the mode is configured as transport. This is because the L2TP packets are being protected, and the L2TP tunnel terminates on the LNS.

Highlighted lines 7 and 8 define the crypto map. The crypto map is called l2tpcryptomap and specifies that ISAKMP will be used to establish IPSec security associations. The profile keyword designates this crypto map as a template so that individual crypto maps can be created on demand. The profile name is l2tp. Additionally, the set transform-set transform-set-name command is used to specify that the transform set called l2tptransform should be used.

Finally, in highlighted line 9, the crypto map is configured on the interface (Fast Ethernet 0/0) on which the IPSec tunnel will be established.

Configuration of the LNS is almost identical.

Example 4-18 shows the configuration of IPSec on the LNS.

Example 4-18. Configuring IPSec on the LNS

vpdn enable
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp security crypto-profile l2tp
 l2tp tunnel password cisco
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key mark address 172.16.1.1
!

crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
 mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
 set transform-set l2tptransform
!
interface Ethernet1/0
 ip address 172.16.5.5 255.255.255.0
 duplex half
 crypto map l2tpcryptomap
!

As you can see, the only difference in the configuration is that the address of the LAC (172.16.1.1) is specified as the peer address.

One additional consideration when protecting the L2TP tunnel using IPSec is the additional IPSec tunnel overhead. This overhead can cause fragmentation of large packets transmitted over the L2TP tunnel. See the section entitled "Configuring the LNS," as well as Chapter 8 for more details. Also see Chapter 8 if you want to configure IPSec with digital certificates instead of preshared keys.

Configuring IPSec Protection for L2TP in Voluntary Tunnel Mode with Preshared Keys

Certain client/LACs, such as Microsoft Windows 2000, protect L2TP with IPSec by default. To support client/LACs configured for L2TP over IPSec, the LNS must also be configured to support IPSec.

Example 4-19 shows a sample configuration for L2TP over IPSec in voluntary tunnel mode using preshared keys.

Example 4-19. Configuring L2TP over IPSec in Voluntary Tunnel Mode

vpdn enable
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 l2tp security crypto-profile l2tp
 no l2tp tunnel authentication
!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key mark address 0.0.0.0 0.0.0.0
!

crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
 mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
 set transform-set l2tptransform
!

interface Ethernet1/0
 ip address 172.16.5.5 255.255.255.0
 duplex half
 crypto map l2tpcryptomap
!

Again, the IPSec configuration is identical to that for compulsory tunnel mode, with the exception that the peer address is configured as a wildcard (0.0.0.0).

Also, if you want to configure IPSec with digital certificates instead of preshared keys, see Chapter 8.

Troubleshooting L2TPv2

If you want to troubleshoot L2TP in a fast and efficient manner, a good knowledge of the underlying theory of operation and configuration is essential. In addition, if the LAC is receiving calls from remote access clients on dialin lines, it is also essential to have a good knowledge of ISDN and asynchronous modems.

Before detailing end-to-end troubleshooting of L2TP, it is worth briefly re-examining the overall tunnel establishment model for L2TP.

Figure 4-20 shows the L2TP tunnel establishment model.

Figure 4-20. L2TP Tunnel Establishment

[View full size image]

Figure 4-20 illustrates the following steps:

These ten steps detail what should happen when a L2TP tunnel is established. However, as you can see, there are many things that can go wrong.

Before diving into the troubleshooting of L2TP, it is worth summarizing some of the potential problems that can occur in compulsory tunnel mode.

Together, Figure 4-21 and Table 4-11 illustrate some potential problems that can occur in L2TP compulsory tunnel mode.

Table 4-11. Potential Problems at Each Point Along the Tunnel

Potential Problems at the Remote Access Client	Potential Problems at the LAC	Potential Problems in Service Provider Backbone	Potential Problems at the LNS
OS Issues	Cabling issue	Cabling/physical layer issue	Cabling issue
Incorrect modem driver	ISDN configuration	Data link issue	Data link issue
DUN misconfigured	Modem configuration	IP connectivity "broken"	Tunnel protocol mismatch
TCP/IP not installed	Authentication	IP/UDP/L2TP blocked (ACL/Firewall)	Tunnel authentication
TCP/IP not bound to dialup networking adapter	Tunnel protocol mismatch		Resource issue
Modem Issues	Wrong IP address for LNS		Virtual template misconfiguration
Not switched on	Tunnel authentication		PPP authentication mismatch
Cabling issue	AAA server issues		Authentication failure

Remember that the problems noted in Table 4-11 are just some of the things that can go wrong. However, if you have a good understanding of the underlying operation of L2TP and its configuration, you should have an excellent foundation for quickly and efficiently troubleshooting L2TP end-to-end.

In Table 4-11, you will notice that some of the issues relate to the remote access client operating system and modem. It is not the intent of this chapter to detail troubleshooting of remote access client operating systems. Instead, this chapter focuses on the troubleshooting of L2TP on Cisco routers.

The flowchart in Figure 4-22 describes the troubleshooting process used with L2TP version 2. You can use this flowchart to access quickly the section of the chapter relevant to problems you are experiencing on your network.

Figure 4-22. L2TP Troubleshooting Flowchart

[View full size image]

The following sections detail end-to-end troubleshooting of L2TP, beginning with call reception on the LAC.

Call Reception on the LAC

The first step in troubleshooting compulsory tunnel mode is to confirm that calls are being successfully received on the LAC. This section assumes that the LAC is configured with a Primary Rate ISDN interface, together with internal digital (MICA) modems.

Figure 4-23 illustrates reception of the remote access client's call on the LAC.

Call reception on the LAC is a multistep process. Therefore, troubleshooting also consists of several steps.

The first step is the reception of the call on the Primary Rate ISDN interface. Therefore, the first thing that you need to do is to confirm that the Primary Rate ISDN interface is in fact active and ready to receive calls. A very good command for verifying the status of the ISDN interface is the show isdn status command.

Example 4-20 shows an example of "good" output from the show isdn status command.

Example 4-20. "Good" Output of the show isdn status Command

CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
    dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
    ACTIVE
    Layer 2 Status:
    TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
    0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Number of L2 Discards = 0, L2 Session ID = 2
    Total Allocated ISDN CCBs = 0
CalCity_LAC#

The first highlighted line in Example 4-20 shows the globally configured isdn switch-type (Primary-net5).

The next highlighted line shows that the ISDN switch type is configured on interface serial 0/0:15. In this case, the switchtype is primary-net 5. You should make sure that the switch type corresponds to that specified by your service provider.

Highlighted line 3 shows the status of the physical layer of the ISDN interface. The status is ACTIVE, indicating that physical connectivity has been established.

Highlighted line 4 shows the Layer 2 status of the interface. The status is MULTIPLE FRAME ESTABLISHED. This is good. It indicates that the primary rate interface has established communications with the ISDN switch at the service provider Central Office (CO).

The final highlighted line shows that there are currently zero active Layer 3 calls. Of course, if remote access clients were connected, then this would show one or more active Layer 3 calls.

That is an example of good output from the show isdn status command. Now it is time to have a look at the output when things are not so good.

Example 4-21 shows the output of the show isdn status command when things are not so good.

Example 4-21. Not So Good Output of the show isdn status Command

CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
    dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
    DEACTIVATED
    Layer 2 Status:
    TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
    Layer 3 Status:
    0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0x0
    Number of L2 Discards = 0, L2 Session ID = 4
    Total Allocated ISDN CCBs = 0
CalCity_LAC#

The first thing that should draw your eye as you are looking down the output is the status of Layer 1. The status is DEACTIVATED (highlighted line 1). This indicates that there is a problem with physical connectivity on the primary rate ISDN interface.

To gain further insight into the problem, you can use the show controller e1 0/0 command, as demonstrated in Example 4-22.

Example 4-22. show controller e1 Command Shows a Loss of Signal

CalCity_LAC#show controller e1 0/0
E1 0/0 is down.
  Applique type is Channelized E1 - balanced
  Transmitter is sending remote alarm.
  Receiver has loss of signal.
  alarm-trigger is not set
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  Data in current interval (60 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 42 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 42 Unavail Secs

Highlighted line 1 shows that E1 0/0 is down. In the second highlighted line, the transmitter is sending a remote alarm. Additionally, the third highlighted line shows that the receiver has loss of signal.

A loss of signal usually indicates a cable problem. In this case, the cable is replaced and the status of the controller is checked again.

Example 4-23 shows the status of the E1 controller after replacing the cable.

Example 4-23. show controller e1 Command Shows No Alarms

CalCity_LAC#show controller e1 0/0
E1 0/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  Data in current interval (899 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

As you can see in the first highlighted line, the E1 is now up. Also, in the second highlighted line, you can see that no alarms are detected.

The show isdn status command is again used to check overall status.

Example 4-24 shows the output of the show isdn status command.

Example 4-24. ISDN Layer 2 Status Is Now MULTIPLE_FRAME_ESTABLISHED

CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
    dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
    ACTIVE
    Layer 2 Status:
    TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
    0 Active Layer 3 Call(s)
    Active dsl 0 CCBs = 0
    The Free Channel Mask:  0xFFFF7FFF
    Number of L2 Discards = 0, L2 Session ID = 4
    Total Allocated ISDN CCBs = 0
CalCity_LAC#

The first highlighted line indicates that Layer 1 is now ACTIVE. Furthermore, highlighted line 2 shows that Layer 2 status is now MULTIPLE_FRAME_ESTABLISHED.

The issue has been resolved.

It is worth remembering that most E1 (and T1) controller problems are caused by incorrect configuration of framing, line code, or clock source. Always make sure that these parameters are configured per your service provider's recommendations. Additionally, ensure that the ISDN switch type and encapsulation are set correctly.

Now that you have verified that the Primary Rate Interface (PRI) is functioning correctly, it is time to verify correct call reception on the interface.

ISDN call signaling is performed using the ISDN Q.931 protocol. To check that call setup is functioning correctly, the best command to use is the debug isdn q931 command.

Example 4-25 shows some good output from the debug isdn q931 command.

Example 4-25. Good Output of the debug isdn q931 Command

CalCity_LAC#debug isdn q931
ISDN Q931 packets debugging is on
CalCity_LAC#
Feb  5 20:16:58.690 UTC: ISDN Se0/0:15: RX <- SETUP pd = 8  callref = 0x0014
Feb  5 20:16:58.690 UTC:         Sending Complete
Feb  5 20:16:58.690 UTC:         Bearer Capability i = 0x8090A3
Feb  5 20:16:58.694 UTC:         Channel ID i = 0xA98381
Feb  5 20:16:58.694 UTC:         Calling Party Number i = 0xA1, '1111', Plan:ISDN,
   Type:National
Feb  5 20:16:58.694 UTC:         Called Party Number i = 0xA1, '7777', Plan:ISDN,
   Type:National
Feb  5 20:16:58.698 UTC:         Low Layer Compat i = 0x8090A3
Feb  5 20:16:58.706 UTC: ISDN Se0/0:15: llc valid, speed 64, call type is VOICE
speed:0 async:N
Feb  5 20:16:58.762 UTC: ISDN Se0/0:15: TX -> CALL_PROC pd = 8  callref = 0x8014
Feb  5 20:16:58.762 UTC:         Channel ID i = 0xA98381
Feb  5 20:16:58.766 UTC: ISDN Se0/0:15: TX -> ALERTING pd = 8  callref = 0x8014
Feb  5 20:16:58.766 UTC: ISDN Se0/0:15: TX -> CONNECT pd = 8  callref = 0x8014
Feb  5 20:16:58.794 UTC: ISDN Se0/0:15: RX <- CONNECT_ACK pd = 8  callref = 0x0014
Feb  5 20:16:58.802 UTC: ISDN Se0/0:15: CALL_PROGRESS: CALL_CONNECTED call id 0x14, bchan
 0, dsl 0
Feb  5 20:16:58.806 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 20:17:04.806 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111
Feb  5 20:17:28.402 UTC: %LINK-3-UPDOWN: Interface Async34, changed state to up
Feb  5 20:17:34.674 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async34, changed
 state to up
CalCity_LAC#

In the first highlighted line, a Call Setup message is received (RX) on the ISDN D channel (serial 0/0:15).

Highlighted line 2 shows the number of the calling party (the remote access client). In this case, the number of the calling party is 1111.

Highlighted line 3 shows the called party number. The called party number is the number that the remote access client dialed to connect to the LAC (7777).

Call reception proceeds normally, and in highlighted line 4, you can see that serial interface 0/0:0 connected to 1111 (the remote access client).

The call from the remote access client has been successfully received on the ISDN interface. To verify whether the call is successfully switched internally to the digital modems, the debug modem command can be used.

Example 4-26 shows the output of the debug modem command.

Example 4-26. Verifying Call Reception on the Digital Modems

CalCity_LAC#debug modem
Modem control/process activation debugging is on
CalCity_LAC#
Feb  5 20:21:25.810 UTC: Modem 1/2 Mica: configured for Answer mode, with Null signaling,
 0x0 tone detection.
Feb  5 20:21:25.810 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
   to 1111
Feb  5 20:21:25.898 UTC: Modem 1/2 Mica: in modem state CALL_SETUP
Feb  5 20:21:26.978 UTC: Modem 1/2 Mica: in modem state CONNECT
Feb  5 20:21:31.374 UTC: Modem 1/2 Mica: in modem state LINK
Feb  5 20:21:31.810 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111
Feb  5 20:21:42.722 UTC: Modem 1/2 Mica: in modem state TRAINUP
Feb  5 20:21:50.718 UTC: Modem 1/2 Mica: in modem state EC_NEGOTIATING
Feb  5 20:21:51.214 UTC: Modem 1/2 Mica: in modem state STEADY
Feb  5 20:21:51.226 UTC: Modem 1/2 Mica: CONNECT at 48000/28800 (Tx/Rx), V90,
   LAPM, V42bis
Feb  5 20:21:51.946 UTC: TTY35: DSR came up
Feb  5 20:21:51.946 UTC: tty35: Modem: IDLE->(unknown)
Feb  5 20:21:51.950 UTC: TTY35: Autoselect started
Feb  5 20:21:51.950 UTC: TTY35: create timer type 0, 120 seconds
Feb  5 20:21:53.354 UTC: TTY35: Autoselect sample 7E
Feb  5 20:21:53.354 UTC: TTY35: Autoselect sample 7EFF
Feb  5 20:21:53.354 UTC: TTY35: Autoselect sample 7EFF7D
Feb  5 20:21:53.358 UTC: TTY35: Autoselect sample 7EFF7D23
Feb  5 20:21:53.358 UTC: TTY35 Autoselect cmd:  ppp negotiate
Feb  5 20:21:53.358 UTC: TTY35: destroy timer type 0
Feb  5 20:21:53.358 UTC: TTY35: EXEC creation
Feb  5 20:21:53.362 UTC: TTY35: create timer type 1, 600 seconds
Feb  5 20:21:53.362 UTC: TTY35: destroy timer type 1
Feb  5 20:21:53.362 UTC: TTY35: no timer type 0 to destroy
Feb  5 20:21:55.362 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb  5 20:22:00.454 UTC: Modem 1/2 Mica: PPP escape_map: Tx map = 0, Rx map = 0
Feb  5 20:22:01.626 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async35,
   changed state to up
Feb  5 20:22:12.330 UTC: Modem 1/2 Mica: in modem state SS_SHIFTINGSPEED
Feb  5 20:22:15.046 UTC: Modem 1/2 Mica: in modem state STEADY
Feb  5 20:22:15.054 UTC: Modem 1/2 Mica: SpeedShifted to 48000/31200 (Tx/Rx)
CalCity_LAC#

In highlighted line 1, interface serial 0/0:0 is connected to the remote access client. Soon after, in highlighted line 2, one of the MICA modems goes off the hook.

Then in highlighted line 3, the modem is connected at a transmit and receive speed of 48,000 bps and 28,800 bps, respectively.

From highlighted line 4 to highlighted 7, the modem samples the data arriving on the line and, in highlighted line 8, autodetects PPP.

In highlighted line 9, interface async 35 changes state to up. Interface async 35 is the logical interface associated with the modem on line 35.

Finally, in highlighted line 10, the line protocol on interface async 35 changes state to up, and the logical interface is connected to the remote access client.

If the debug modem command does not produce any output, two things that you should check are that the isdn incoming voice-modem command is configured on the ISDN D channel and that the modem InOut command is configured on the modem lines.

At this point, call reception has been successful, and the LAC is ready to begin PPP negotiation with the remote access client.

Troubleshooting PPP on the LAC

If call reception on the LAC is successful, you are now ready to move on to debugging PPP negotiation between the remote access client and the LAC.

Before examining the relevant troubleshooting commands for PPP negotiation, it is worth briefly looking at what form PPP negotiation takes between the remote access client and the LAC.

Figure 4-24 illustrates PPP negotiation between the remote access client and the LAC.

PPP negotiation consists of LCP negotiation, authentication (optionally), and NCP negotiation. LCP negotiation and partial authentication take place between the remote access client and the LAC. NCP negotiation occurs between the remote access client and the LNS.

LCP Negotiation Between the Remote Access Client and the LAC

The first part of PPP negotiation is LCP negotiation. There are a number of useful commands you can use when verifying PPP negotiation on the LAC.

The first command that can be used is the show user command, as demonstrated in Example 4-27.

Example 4-27. Verifying Active Lines on the LAC

CalCity_LAC#show user
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00
  36 tty 36    ltahoe@mjl Async interface          -
  Interface      User        Mode                     Idle     Peer Address
CalCity_LAC#

Highlighted line 1 shows that user ltahoe@mjlnet.com is connected to line 36.

If more detail is required about the user, use the show caller user command.

Example 4-28 shows output from the show caller user command.

Example 4-28. Verifying Caller Information on the LAC

CalCity_LAC#show caller user ltahoe@mjlnet.com
  User: ltahoe@mjlnet.com, line tty 36, service Async
        Active time 00:01:00, Idle time 00:00:04
  Timeouts:            Absolute  Idle      Idle
                                 Session   Exec
      Limits:          -         -         00:10:00
      Disconnect in:   -         -         -
  TTY: Line 36, running PPP on As36
  Line: Baud rate (TX/RX) is 115200/115200, no parity, 2 stopbits, 8 databits
  Status: Ready, Active, No Exit Banner, Async Interface Active
          HW PPP Support Active, Modem Detected
  Capabilities: Modem Callout, Modem RI is CD,
                Line usable as async interface, Modem Autoconfigure
                Integrated Modem
  Modem State: Ready, Modem Configured
  User: ltahoe@mjlnet.com, line As36, service PPP
        Active time 00:00:50, Idle time 00:00:00
  Timeouts:            Absolute  Idle
      Limits:          -         -
      Disconnect in:   -         -
  PPP: LCP Open, CHAP (<- none)
  IP: Local 172.16.1.1
  VPDN: NAS , MID 13, MID Unknown
        HGW , NAS CLID 0, HGW CLID 0, tunnel open
  Counts: 84 packets input, 5453 bytes, 0 no buffer
          4 input errors, 4 CRC, 0 frame, 0 overrun
          66 packets output, 2322 bytes, 0 underruns
          0 output errors, 0 collisions, 3 interface resets
CalCity_LAC#

In highlighted line 1, you can see that remote access client ltahoe@mjlnet.com is connected to asynchronous line 36, and that the service running on that line is PPP.

Additionally, in highlighted line 2, you can see that the LCP state is open. This means that LCP has been successfully negotiated between remote access client ltahoe@mjlnet.com and the LAC.

In highlighted line 2, you can see that partial CHAP authentication has taken place between the LAC and the remote access client.

If LCP negotiation is unsuccessful between the LAC and the remote access client, you can use the debug ppp negotiation command to see what went wrong.

Examples 4-29 to 4-41 show successful LCP negotiation between LAC and remote access client.

Example 4-29. Successful LCP Negotiation Between the LAC and the Remote Access Client

CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb  5 20:39:21.269 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 20:39:27.265 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111
Feb  5 20:39:50.837 UTC: %LINK-3-UPDOWN: Interface Async33, changed state to up
Feb  5 20:39:50.837 UTC: As33 PPP: Treating connection as a dedicated line
Feb  5 20:39:50.837 UTC: As33 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]

In highlighted line 1, interface serial 0/0:0 is connected to the remote access client (1111). Shortly thereafter, in highlighted line 2, interface async 33 changes state to up.

In highlighted line 3, the PPP phase is ESTABLISHING. PPP negotiation is about to commence. The first stage of PPP negotiation is LCP negotiation.

The LAC now sends an LCP Configure-Request (CONFREQ) to the remote access client as shown in Example 4-30 (the O indicates that the CONFREQ is outgoing).

Example 4-30. Outbound CONFREQ from the LAC

Feb  5 20:39:50.837 UTC: As33 LCP: O CONFREQ [Closed] id 20 len 25
Feb  5 20:39:50.837 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:50.837 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:50.837 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:50.841 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:50.841 UTC: As33 LCP:    ACFC (0x0802)

The CONFREQ in Example 4-30 is used by the LAC to indicate to the remote access client which LCP options it would like to configure. The LCP options are shown in the five following lines. These options are ACCM, Authentication Protocol, MagicNumber, Protocol Field Compression (PFC), and Address and Control Field Compression (ACFC).

It is worth taking a quick look at these options. The first LCP option specified in the CONFREQ is ACCM. The ACCM LCP option is used to specify how data sent over the link will be escaped. Escaping data sent over the link ensures that certain data patterns that could otherwise be misinterpreted by the receiving modem as commands are avoided. In this case, the ACCM that the LAC would like to use on the link has a value of 0x000A0000. This particular ACCM is often used over lines with XON/XOFF software flow control.

The hexadecimal number contained within the parentheses (0x0206000A0000) is the numerical value of the LCP option (0x02, ACCM), the overall length (0x06), and the ACCM itself (0x000A0000). Note that the option number, length, and value encoding format is common to PPP options.

The second LCP option in the CONFREQ is authentication protocol (0x03). The authentication protocol specified is MD5 CHAP (0xC22305).

MagicNumber is next (0x05). This LCP option is used to detect looped back links. The actual MagicNumber sent by the LAC is 0x12072037.

PFC (0x07) is the fourth LCP option in the CONFREQ. This indicates that the LAC can receive PPP protocol fields that are compressed.

The final LCP option specified is ACFC (0x08). PPP frames are normally sent with leading HDLC Address and Control fields. In this case, the LAC is telling the remote access client that it can receive PPP frames without these HDLC fields.

The remote access client responds with an LCP Configure-Ack (CONFACK) (incoming [I]) as shown in Example 4-31.

Example 4-31. Inbound CONFACK from the Remote Access Client

Feb  5 20:39:50.961 UTC: As33 LCP: I CONFACK [REQsent] id 20 len 25
Feb  5 20:39:50.965 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:50.965 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:50.965 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:50.965 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:50.965 UTC: As33 LCP:    ACFC (0x0802)

In the CONFACK (Example 4-31), the remote access client acknowledges the CONFREQ sent by the LAC (note that it has the same id [20] as the CONFREQ in Example 4-30). Once again, the next five lines in the output show the LCP options contained in the CONFACK. The LCP options contained in CONFACK are almost exactly the same as those in the LAC's CONFREQ. There is, however, one minor difference. You will notice that the MagicNumber specified is different than that specified in the LAC's CONFREQ message. This is good. If the number were the same, it would indicate a looped line.

In Example 4-32, the remote access client sends an LCP CONFREQ to the LAC.

Example 4-32. Inbound CONFREQ from the Remote Access Client

Feb  5 20:39:51.829 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 2 len 50
Feb  5 20:39:51.829 UTC: As33 LCP:    ACCM 0x00000000 (0x020600000000)
Feb  5 20:39:51.829 UTC: As33 LCP:    MagicNumber 0x06E435E9 (0x050606E435E9)
Feb  5 20:39:51.829 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:51.829 UTC: As33 LCP:    ACFC (0x0802)
Feb  5 20:39:51.829 UTC: As33 LCP:    Callback 6  (0x0D0306)
Feb  5 20:39:51.829 UTC: As33 LCP:    MRRU 1614 (0x1104064E)
Feb  5 20:39:51.833 UTC: As33 LCP:    EndpointDisc 1 Local
Feb  5 20:39:51.833 UTC: As33 LCP:     (0x13170190699D7655924F3481F6E9E6D7)
Feb  5 20:39:51.833 UTC: As33 LCP:     (0x6EFD0A00000000)

The LCP options contained in the remote access client's CONFREQ (Example 4-32) have all been described previously, with the exception of Callback (0x0D), Multilink-Maximum-Reconstructed-Receive-Unit (MRRU) (0x11), and Multilink-Endpoint-Discriminator (ED) (0x13).

With the Callback option, the remote access client indicates that it would like to be called back. The MRRU and ED options are used with MP.

The LAC responds by sending a Configure-Reject (CONFREJ) to the remote access client, as demonstrated in Example 4-33. This CONFREJ is used by the LAC to reject both Callback and MRRU.

Example 4-33. Outbound CONFREJ from the LAC

Feb  5 20:39:51.833 UTC: As33 LCP: O CONFREJ [ACKrcvd] id 2 len 11
Feb  5 20:39:51.833 UTC: As33 LCP:    Callback 6  (0x0D0306)
Feb  5 20:39:51.833 UTC: As33 LCP:    MRRU 1614 (0x1104064E)
Feb  5 20:39:52.837 UTC: As33 LCP: TIMEout: State ACKrcvd

Shortly after sending the CONFREJ, the LAC sends another CONFREQ to the remote access client, as shown in Example 4-34.

Example 4-34. Second CONFREQ from the LAC

Feb  5 20:39:52.837 UTC: As33 LCP: O CONFREQ [ACKrcvd] id 21 len 25
Feb  5 20:39:52.837 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:52.837 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:52.837 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:52.837 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:52.837 UTC: As33 LCP:    ACFC (0x0802)

Again, the LCP options specified by the LAC in the CONFREQ in Example 4-34 are ACCM, Authentication Protocol, MagicNumber, PFC, and ACFC. This is simply a reiteration of the first CONFREQ sent by the LAC.

In Example 4-35, the remote access client again acknowledges the LCP options sent in the LAC's CONFREQ.

Example 4-35. Second CONFACK from the Remote Access Client

Feb  5 20:39:52.949 UTC: As33 LCP: I CONFACK [REQsent] id 21 len 25
Feb  5 20:39:52.949 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:52.949 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:52.953 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:52.953 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:52.953 UTC: As33 LCP:    ACFC (0x0802)
Feb  5 20:39:54.837 UTC: As33 LCP: TIMEout: State ACKrcvd

The LAC now sends yet another CONFREQ with the same LCP options, as shown in Example 4-36.

Example 4-36. Third CONFREQ from the LAC

Feb  5 20:39:54.837 UTC: As33 LCP: O CONFREQ [ACKrcvd] id 22 len 25
Feb  5 20:39:54.837 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:54.837 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:54.837 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:54.837 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:54.837 UTC: As33 LCP:    ACFC (0x0802)

Once again, in Example 4-37, the remote access client acknowledges the CONFREQ from the LAC with a CONFACK.

Example 4-37. Third CONFACK from the Remote Access Client

Feb  5 20:39:54.945 UTC: As33 LCP: I CONFACK [REQsent] id 22 len 25
Feb  5 20:39:54.945 UTC: As33 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  5 20:39:54.945 UTC: As33 LCP:    AuthProto CHAP (0x0305C22305)
Feb  5 20:39:54.945 UTC: As33 LCP:    MagicNumber 0x12072037 (0x050612072037)
Feb  5 20:39:54.945 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:54.945 UTC: As33 LCP:    ACFC (0x0802)

What is happening here? Why is the LAC resending the CONFREQ in Examples 4-34 and 4-36? The answer can be found by looking a little more closely at the debug output. Notice the timeouts all the way back in Examples 4-33 and 4-35LCP is timing out on the LAC.

The LAC receives another CONFREQ from the remote access client in Example 4-38. This contains the same options specified in the previous CONFREQ (Example 4-32).

Example 4-38. Second CONFREQ from the Remote Access Client

Feb  5 20:39:55.829 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 3 len 50
Feb  5 20:39:55.829 UTC: As33 LCP:    ACCM 0x00000000 (0x020600000000)
Feb  5 20:39:55.829 UTC: As33 LCP:    MagicNumber 0x06E435E9 (0x050606E435E9)
Feb  5 20:39:55.829 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:55.829 UTC: As33 LCP:    ACFC (0x0802)
Feb  5 20:39:55.829 UTC: As33 LCP:    Callback 6  (0x0D0306)
Feb  5 20:39:55.829 UTC: As33 LCP:    MRRU 1614 (0x1104064E)
Feb  5 20:39:55.829 UTC: As33 LCP:    EndpointDisc 1 Local
Feb  5 20:39:55.833 UTC: As33 LCP:     (0x13170190699D7655924F3481F6E9E6D7)
Feb  5 20:39:55.833 UTC: As33 LCP:     (0x6EFD0A00000000)

Once again, the LAC rejects both the Callback and MRRU options by sending a CONFREJ message, as shown in Example 4-39.

Example 4-39. The LAC Again Rejects Callback and MRRU

Feb  5 20:39:55.833 UTC: As33 LCP: O CONFREJ [ACKrcvd] id 3 len 11
Feb  5 20:39:55.833 UTC: As33 LCP:    Callback 6  (0x0D0306)
Feb  5 20:39:55.833 UTC: As33 LCP:    MRRU 1614 (0x1104064E)

Another CONFREQ is received from the remote access client in Example 4-40.

Example 4-40. Third CONFREQ from the Remote Access Client

Feb  5 20:39:55.945 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 4 len 43
Feb  5 20:39:55.945 UTC: As33 LCP:    ACCM 0x00000000 (0x020600000000)
Feb  5 20:39:55.945 UTC: As33 LCP:    MagicNumber 0x06E435E9 (0x050606E435E9)
Feb  5 20:39:55.945 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:55.945 UTC: As33 LCP:    ACFC (0x0802)
Feb  5 20:39:55.945 UTC: As33 LCP:    EndpointDisc 1 Local
Feb  5 20:39:55.945 UTC: As33 LCP:     (0x13170190699D7655924F3481F6E9E6D7)
Feb  5 20:39:55.949 UTC: As33 LCP:     (0x6EFD0A00000000)

The CONFREQ shown in Example 4-40 is the third sent by the remote access client, but if you look closely, you will see that it no longer contains the Callback and MRRU options rejected by the LAC (compare with Example 4-38).

In Example 4-41, the LAC acknowledges the remote access client's CONFREQ, and the LCP state changes to Open.

Example 4-41. The LAC Sends a CONFACK, and the LCP State Changes to Open

Feb  5 20:39:55.949 UTC: As33 LCP: O CONFACK [ACKrcvd] id 4 len 43
Feb  5 20:39:55.949 UTC: As33 LCP:    ACCM 0x00000000 (0x020600000000)
Feb  5 20:39:55.949 UTC: As33 LCP:    MagicNumber 0x06E435E9 (0x050606E435E9)
Feb  5 20:39:55.949 UTC: As33 LCP:    PFC (0x0702)
Feb  5 20:39:55.949 UTC: As33 LCP:    ACFC (0x0802)
Feb  5 20:39:55.949 UTC: As33 LCP:    EndpointDisc 1 Local
Feb  5 20:39:55.949 UTC: As33 LCP:     (0x13170190699D7655924F3481F6E9E6D7)
Feb  5 20:39:55.949 UTC: As33 LCP:     (0x6EFD0A00000000)
Feb  5 20:39:55.953 UTC: As33 LCP: State is Open
CalCity_LAC#

In highlighted line 1 (Example 4-41), the LAC acknowledges the LCP options in the remote access client's last CONFREQ (Example 4-40) with a CONFACK message.

Finally, in highlighted line 2, the LCP state changes to Open. LCP negotiation has succeeded. At this point, the LAC and the remote access client are ready to begin the second stage of PPP negotiation, authentication.

Note that LCP negotiation will fail if the LAC and the remote access client do not agree on the configuration of LCP options. LCP negotiation failure can occur for a number of reasons, the most common being failure to agree an authentication protocol. This would occur, for example, if the LAC was configured to authenticate using only CHAP, but the remote access client was configured to authenticate using only PAP.

Partial PPP Authentication Fails on the LAC

Once you have verified that LCP negotiation between the LAC and a remote access client has been successful, the next stage is to verify that partial PPP authentication completes successfully.

To examine the PPP authentication sequence between the LAC and the remote access client, you can again use the debug ppp negotiation command.

Before taking a look at an authentication failure between the LAC and a remote access client, it is useful to examine the output of the debug ppp negotiation command when authentication is successful. Note that the debug ppp authentication command can also be used for this purpose.

In Example 4-42, debug ppp negotiation shows successful authentication between the LAC and the remote access client. Only the relevant portion of the output is shown.

Example 4-42. Successful Partial PPP Authentication on the LAC

CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb  5 20:39:55.953 UTC: As33 LCP: State is Open
Feb  5 20:39:55.953 UTC: As33 PPP: Phase is AUTHENTICATING, by this end
  [0 sess, 0 load]
Feb  5 20:39:55.953 UTC: As33 CHAP: O CHALLENGE id 6 len 32 from "CalCity_LAC"
Feb  5 20:39:56.065 UTC: As33 LCP: I IDENTIFY [Open] id 5 len 18 magic 0x06E435E9 MSRASV5.00
Feb  5 20:39:56.081 UTC: As33 LCP: I IDENTIFY [Open] id 6 len 25 magic 0x06E435E9
 MSRAS-1-MLEWIS
Feb  5 20:39:56.097 UTC: As33 CHAP: I RESPONSE id 6 len 37
  from "ltahoe@mjlnet.com"
Feb  5 20:39:56.097 UTC: As33 PPP: Phase is FORWARDING [0 sess, 0 load]
Feb  5 20:39:57.117 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async33,
  changed state to up
CalCity_LAC#

PPP negotiation between the LAC and a remote access client consists of two stages, LCP negotiation and partial PPP authentication. In highlighted line 1, you will notice that LCP negotiation has been successful and the LCP state has changed to open. This is the point at which PPP authentication begins.

In highlighted line 2, the PPP phase changes to AUTHENTICATING. In highlighted line 3, the LAC sends a CHAP challenge to the remote access client. Notice the O herethis indicates that the challenge is outgoing.

The remote access client replies to the CHAP challenge with a CHAP response in highlighted line 4. This CHAP response message is incoming, which is indicated by the I in the output. Note that the remote access client identifies itself as ltahoe@mjlnet.com. This is the remote access client's user name.

Then in highlighted line 5, the line protocol on interface async 36 changes state to up.

What is going on here? The LAC received the CHAP response from the remote access client, and you might have expected it to send back either a success or failure message, but it sent neither. The reason for this is that the remote access client is only partially authenticated on LAC. In other words, the LAC challenges the remote access client, receives the response, and uses the domain name contained within the response to associate the remote access client with an L2TP tunnel to the LNS. It is the LNS that completes authentication and sends either a success or a failure message back to the remote access client. In Example 4-42, partial authentication has completed successfully.

Before moving on to examine the output of the debug ppp negotiation command when partial authentication is not so successful, it is worth having another quick look at the output in Example 4-42. Specifically, take a look at the output between highlighted lines 3 and 4. You will notice two LCP Identify messages from the remote access client. The LCP Identify messages (0x0C, Identification) allow a remote access client to identify itself to its PPP peer (the LAC). In this case, the remote access client informs the LAC that it is a Microsoft client running RAS version 5 and that the computer name is MLEWIS.

Now you know what a successful partial authentication sequence looks like, it is time to examine what happens when partial authentication is not successful.

Example 4-43 shows the output of the debug ppp negotiation command when partial authentication is not successful. Note that only the relevant portion of the debug output is shown.

Example 4-43. Unsuccessful Partial PPP Authentication on the LAC

CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb  5 20:44:02.449 UTC: As34 LCP: State is Open
Feb  5 20:44:02.449 UTC: As34 PPP: Phase is AUTHENTICATING, by this end
  [0 sess, 0 load]
Feb  5 20:44:02.449 UTC: As34 CHAP: O CHALLENGE id 6 len 32 from "CalCity_LAC"
Feb  5 20:44:02.569 UTC: As34 LCP: I IDENTIFY [Open] id 5 len 18 magic 0x4F3947BA
  MSRASV5.00
Feb  5 20:44:02.585 UTC: As34 LCP: I IDENTIFY [Open] id 6 len 25 magic 0x4F3947BA
  MSRAS-1-MLEWIS
Feb  5 20:44:02.601 UTC: As34 CHAP: I RESPONSE id 6 len 37
  from "ltahoe@mjlnet.com"
Feb  5 20:44:02.601 UTC: As34 PPP: Phase is FORWARDING [0 sess, 0 load]
Feb  5 20:44:02.605 UTC: As34 PPP: Phase is AUTHENTICATING [0 sess, 0 load]
Feb  5 20:44:02.605 UTC: As34 CHAP: O FAILURE id 6 len 25 msg is
  "MD/DES compare failed"
Feb  5 20:44:02.609 UTC: As34 PPP: Phase is TERMINATING [0 sess, 0 load]
Feb  5 20:44:02.609 UTC: As34 LCP: O TERMREQ [Open] id 22 len 4
Feb  5 20:44:02.725 UTC: As34 LCP: I TERMACK [TERMsent] id 22 len 4
Feb  5 20:44:02.725 UTC: As34 LCP: State is Closed
Feb  5 20:44:02.729 UTC: As34 PPP: Phase is DOWN [0 sess, 0 load]
Feb  5 20:44:02.729 UTC: As34 PPP: Phase is ESTABLISHING, Passive Open
  [0 sess, 0 load]
Feb  5 20:44:02.729 UTC: As34 LCP: State is Listen
Feb  5 20:44:02.821 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected from
  1111 , call lasted 35 seconds
Feb  5 20:44:04.729 UTC: %LINK-5-CHANGED: Interface Async34, changed state to reset
Feb  5 20:44:04.729 UTC: As34 LCP: State is Closed
Feb  5 20:44:04.729 UTC: As34 PPP: Phase is DOWN [0 sess, 0 load]
Feb  5 20:44:09.729 UTC: %LINK-3-UPDOWN: Interface Async34, changed state to down
Feb  5 20:44:09.729 UTC: As34 LCP: State is Closed
CalCity_LAC#

Highlighted line 1 shows the LCP state changing to OPEN. This indicates that LCP negotiation has completed successfully.

Shortly thereafter, in highlighted line 2, the PPP phase changes to AUTHENTICATING. Then, in highlighted line 3, the LAC sends a CHAP challenge to the remote access client. The remote access client responds with a CHAP response in highlighted line 4. Again, you can see that the remote access client identifies itself as ltahoe@mjlnet.com. So far so good.

But now something goes wrong. Highlighted line 5 shows the LAC sending a CHAP failure message to the remote access client. What is going on here? Should not PPP authentication be completed on the LNS? Why is the LAC sending a CHAP failure message?

Once CHAP authentication has failed, things start to go downhill rapidly. In highlighted line 6, the LAC sends a Terminate-Request (TERMREQ). As the name implies, this message is used by a PPP peer to indicate its desire to terminate the connection.

In highlighted line 7, the remote access client responds with a Terminate-Ack (TERMACK). The remote access client has acknowledged the TERMREQ, and the PPP connection is about to be closed.

Highlighted line 8 shows the PPP phase changing state to down. Then in highlighted line 9, interface async 34 goes down. The connection has been terminated. What went wrong? A bit more digging is necessary.

The next command to use is debug vpdn event. This command will give you more insight into what is happening.

When the remote access client reconnects to the LAC, the debug vpdn event command is used, as shown in Example 4-44.

Example 4-44. LAC Cannot Find a Tunnel for Domain mjlnet.com

CalCity_LAC#debug vpdn event
VPDN events debugging is on
CalCity_LAC#
Feb  5 20:44:54.501 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 20:45:00.497 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 20:45:24.345 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb  5 20:45:29.605 UTC: As35 VPDN: Got DNIS string 7777
Feb  5 20:45:29.605 UTC: As35 VPDN: Looking for tunnel -- mjlnet.com --
Feb  5 20:45:29.609 UTC: VPDN/mjlnet.com: Authorization failed, could not
  talk to AAA server or local tunnel problem
Feb  5 20:45:29.609 UTC: As35 VPDN: Looking for tunnel -- dnis:7777 --
Feb  5 20:45:29.609 UTC: VPDN/dnis:7777: Authorization failed, could not talk to
  AAA server or local tunnel problem
Feb  5 20:45:29.613 UTC: As35 VPDN: Continue PPP authentication for
  ltahoe@mjlnet.com
Feb  5 20:45:30.141 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected
  from 1111 , call lasted 35 seconds
Feb  5 20:45:33.553 UTC: %LINK-5-CHANGED: Interface Async35, changed state to reset
Feb  5 20:45:38.553 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to down
CalCity_LAC#

Highlighted line 1 in Example 4-44 shows interface serial 0/0:0 connected to the remote access client (1111).

Then in highlighted line 2, interface async 35 changes state to up. The remote access client is now connected to the internal digital modem.

This is when things start to get interesting. Highlighted line 3 shows the LAC obtaining the DNIS (7777). Remember, this is the number that the remote access client dialed to connect to the LAC.

In highlighted line 4, the LAC tries to associate the remote access client's domain name (obtained during authentication) to a L2TP tunnel. The remote access client's domain name is mjlnet.com.

Something goes wrong in highlighted line 5. This line reveals that either authorization failed or there was a local tunnel problem. This indicates that the LAC was unable to associate the domain (mjlnet.com) with a L2TP tunnel.

Having failed to associate the domain name with a tunnel, the LAC then tries to associate the DNIS with a tunnel (highlighted line 6). Unfortunately, as highlighted line 7 reveals, once again either authorization has failed or the DNIS could not be associated with a tunnel.

In this case, authorization is not the problem (for more about this, see the case studies at the end of the chapter). The problem, therefore, must relate to the failure of the LAC to associate either the domain name or the DNIS to a tunnel. This, however, does not explain the PPP failure message sent by the LAC to the remote access client in Example 4-43.

Highlighted line 8 in Example 4-44, shows the message Continue PPP authentication for ltahoe@mjlnet.com. This message is quite revealing. It shows that having failed to associate the domain name or the DNIS to an L2TP tunnel, the LAC is now trying to locally complete authentication of the remote access client. Unfortunately, this local authentication fails, and in highlighted line 9, interface serial 0/0:0 is disconnected from the remote access client. Finally, in highlighted line 10, interface async 36 changes state to down.

The problem is clear. The LAC is unable to associate the remote access client's domain name or the DNIS to a tunnel. The LAC is configured to associate domain name with the L2TP tunnel, so this would indicate that either the remote access client's domain name is incorrectly configured or the domain name specified in the VPDN group is wrong.

It should be clear from the output in Example 4-44 that the remote access client's domain name (mjlnet.com) is in fact correctly configured. The problem, therefore, must be with the VPDN group.

The configuration of the LAC is examined and the problem is revealed. Example 4-45 shows the incorrect configuration for the VPDN group domain name on the LAC. Note that only the relevant portion of the output is shown.

Example 4-45. VPDN Group Configuration

CalCity_LAC#show running-config
Building configuration...
!
vpdn-group 1
 request-dialin
  protocol l2tp
  domain disco.com
 initiate-to ip 172.16.5.5
 l2tp tunnel password 7 060506324F41
!

As you can see, the domain name configured for the VPDN group (disco.com) is not consistent with the remote access client's domain name (mjlnet.com). The issue is resolved by modifying the domain name configured under the VPDN group.

Example 4-46 shows reconfiguration of the domain name under the VPDN group.

Example 4-46. Reconfiguration of the Domain Name

CalCity_LAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
CalCity_LAC(config)#vpdn-group 1
CalCity_LAC(config-vpdn)#request-dialin
CalCity_L(config-vpdn-req-in)#no domain disco.com
CalCity_L(config-vpdn-req-in)#domain mjlnet.com
CalCity_L(config-vpdn-req-in)#exit
CalCity_LAC#

When the remote access client reconnects to the LAC, L2TP tunnel establishment succeeds. This is verified using the show vpdn tunnel all command.

Example 4-47 shows the successful establishment of the L2TP tunnel between the LAC and the LNS.

Example 4-47. Verifying Successful L2TP Tunnel Establishment

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 19773 is up, remote id is 37111, 1 active sessions
  Tunnel state is established, time since change 00:00:14
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  34 packets sent, 16 received
  5201 bytes sent, 772 received
  Control Ns 4, Nr 2
  Local RWS 800 (default), Remote RWS 800 (max)
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 0
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

As you can see in highlighted line 1, one tunnel and one session have been established. The tunnel state (established) is shown in highlighted line 2.

Highlighted lines 3 and 4 show the LNS's name (Skydance_LNS), IP address (172.16.5.5), and UDP port on which the tunnel is established (1701).

Additionally, the local LAC name (CalCity_LAC), IP address (172.16.1.1), and UDP port on which the tunnel is established (1701) are shown in highlighted lines 5 and 6. The issue has been resolved.

L2TPv2 Tunnel Establishment Failure

Once the inbound call has been successfully received on the LAC, and the domain name, DNIS, or complete username (if you are using per-user VPDN) has been successfully matched, the next stage (assuming that it has not already been set up) is to initiate tunnel setup to the LNS.

Figure 4-25 illustrates initiation of L2TP tunnel setup initiation from the LAC to the LNS.

Figure 4-25. L2TP Tunnel Setup Initiation

[View full size image]

The first thing that happens during the tunnel setup process is that the LAC sends a SCCRQ message to the LNS. Upon receipt of the SCCRQ message, the LNS checks that it is from a valid source and that sufficient resources are available. If these conditions are met, the LNS responds to the SCCRQ with a SCCRP message. This indicates to the LAC to the LNS is willing to proceed with tunnel setup. Note, however, that if the LNS is not configured to terminate L2TP tunnels from the LAC in question, it simply discards the message.

When the LAC receives the SCCRP, it then responds with a SCCN. This indicates successful tunnel setup. Once the control connection is set up, data session establishment can take place.

Before taking a look at how tunnel setup can fail, it is worth examining successful tunnel setup, using the debug vpdn l2x-events command.

Example 4-48 shows the output of the debug vpdn l2x-events command. This output shows successful tunnel setup. Note that only the relevant portion of the output is shown.

Example 4-48. Successful L2TPv2 Tunnel Setup

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb  5 23:50:34.992 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 23:50:40.988 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  5 23:51:04.592 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to up
Feb  5 23:51:09.848 UTC: Tnl 63403 L2TP: SM State idle
Feb  5 23:51:09.848 UTC: Tnl 63403 L2TP: O SCCRQ
Feb  5 23:51:09.848 UTC: Tnl 63403 L2TP: Tunnel state change from idle to
  wait-ctl-reply
Feb  5 23:51:09.852 UTC: Tnl 63403 L2TP: SM State wait-ctl-reply
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: I SCCRP from Skydance_LNS
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: Got a challenge from remote peer,
   Skydance_LNS
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: Got a response from remote peer, Skydance_LNS
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: Tunnel Authentication success
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: Tunnel state change from wait-ctl-reply
  to established
Feb  5 23:51:09.856 UTC: Tnl 63403 L2TP: O SCCCN  to Skydance_LNS tnlid 52441
Feb  5 23:51:09.860 UTC: Tnl 63403 L2TP: SM State established
CalCity_LAC#

In highlighted line 1, interface serial 0/0:0 his connected to the remote access client (1111), and in highlighted line 2, interface async 38 changes state to up. The remote access client's call has been received on the LAC.

Highlighted line 3 shows the first L2TP message activity, with the LAC sending an outgoing (O) SCCRQ to the LNS. The LNS responds with an SCCRP in highlighted line 4. Note the name of the LNS, Skydance_LNS. In highlighted line 5, the LAC reports successful tunnel authentication. The SCCCN is sent to the LNS in highlighted line 6. The control connection is now established. To confirm this, use the show vpdn tunnel all command, as demonstrated in Example 4-49.

Example 4-49. Verifying L2TP Tunnel Setup

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 12471 is up, remote id is 42221, 1 active sessions
  Tunnel state is established, time since change 00:01:09
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  48 packets sent, 43 received
  6898 bytes sent, 2436 received
  Control Ns 4, Nr 2
  Local RWS 800 (default), Remote RWS 800 (max)
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 0
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

Highlighted line 1 shows that one tunnel and one session have been established. In highlighted line 2, the remote tunnel name is shown. It is the name of the LNS, Skydance_LNS. Below that, in highlighted line 3, the IP address of the LNS (172.16.5.5), and UDP port on which the connection to the LNS has been made (1701) are shown.

Highlighted lines 4 and 5 show the local end of the L2TP tunnel. The local tunnel name is the name of the LAC (CalCity_LAC). The local IP address (172.16.1.1) is also shown, together with the local UDP port number on which the connection has been established (1701).

Below that is a plethora of information, including the number of packets and bytes sent and received, the latest control channel Ns (Next sent) and Nr (Next received), the local and remote receive window sizes, the retransmission time, unsent and resend queue sizes, the total number of resends and ZLB Acks sent, retransmission time distribution (1, 2, 4, 8 seconds, and so on), and finally the number of sessions disconnected because of a lack of resources.

Example 4-49 showed successful tunnel setup. Now it is time to examine what happens when tunnel establishment is not so successful.

L2TP tunnel establishment can fail for a number of reasons, including:

• There is no IP connectivity between the LAC and the LNS. This can be tested using ping.

• You should also verify that there are no access lists (or firewalls) blocking L2TP itself (UDP port 1701).

• The LNS's IP address is incorrectly specified on the LAC. Check this by examining the IP address for the LNS configured using the initiateto ip LNS_address command under the VPDN group. If you are using tunnel definitions, also check the IP address specified on the AAA server.

• The LNS does not recognize the LAC. Verify this by checking that the LAC's name is specified correctly with the terminate-from hostname LAC_name under the VPDN group.

• The LNS is not configured to terminate L2TP tunnels (there is a VPDN protocol mismatch).

• There is an L2TP tunnel authentication failure.

This section examines troubleshooting a VPDN protocol mismatch, as well as L2TP tunnel authentication failure.

VPDN Protocol Mismatch

If there is a VPDN protocol mismatch between the LAC and the LNS, L2TP tunnel establishment will fail. Use the debug vpdn l2x-events command to troubleshoot this issue.

Examples 4-50 to 4-53 show the output of the debug vpdn l2x-events command when tunnel setup is not successful.

Example 4-50. L2TPv2 Tunnel Setup Is Unsuccessful

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb  6 00:04:10.573 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:04:16.573 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:04:53.101 UTC: %LINK-3-UPDOWN: Interface Async37, changed state to up
CalCity_LAC#
Feb  6 00:04:58.417 UTC: Tnl 12380 L2TP: SM State idle

Highlighted line 1 (Example 4-50) shows that serial interface 0/0:0 is connected to the remote access client (1111), and in highlighted line 2, interface async 37 changes state to up.

In Example 4-51, the LAC sends a SCCRQ message to the LNS.

Example 4-51. LAC Sends a SCCRQ

Feb  6 00:04:58.417 UTC: Tnl 12380 L2TP: O SCCRQ
Feb  6 00:04:58.421 UTC: Tnl 12380 L2TP: Tunnel state change from idle to
  wait-ctl-reply
Feb  6 00:04:58.421 UTC: Tnl 12380 L2TP: SM State wait-ctl-reply

The LAC now resends the SCCRQ, as demonstrated in Example 4-52.

Example 4-52. LAC Resends the SCCRQ

Feb  6 00:04:59.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:04:59.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
  1 seconds
Feb  6 00:05:00.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:00.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
  2 seconds
Feb  6 00:05:02.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:02.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
  4 seconds
Feb  6 00:05:06.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:06.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
  8 seconds
Feb  6 00:05:14.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:22.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:30.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0
Feb  6 00:05:38.153 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected
  from 1111 , call lasted 87 seconds
Feb  6 00:05:38.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
  tnl 0, cl 0, ns 0, nr 0

Highlighted line 1 (Example 4-52) shows the LAC resending the SCCRQ. Shortly thereafter, in highlighted line 2, the SCCRQ is again resent to the LAC. Clearly the LNS is not responding to the SCCRQ messages sent by the LAC. The LAC continues resending the SCCRQ in highlighted lines 3, 4, 5, 6, 7, and 8.

One thing to notice as the LAC repeatedly resends the SCCRQ message is how the LAC increases the retransmit delay between successive SCCRQ messages. Between the first and fifth retransmissions, the retransmit delay increases from 1 second to 8 seconds, shown between the highlighted lines. Finally, as shown in Example 4-53, the LAC shuts down the tunnel.

Example 4-53. LAC Shuts Down the Tunnel

Feb  6 00:05:39.865 UTC: Tnl 12380 L2TP: Shutdown tunnel
Feb  6 00:05:39.865 UTC: Tnl 12380 L2TP: Tunnel state change from wait-ctl-reply
  to idle
Feb  6 00:05:41.861 UTC: %LINK-5-CHANGED: Interface Async37, changed state to reset
Feb  6 00:05:46.861 UTC: %LINK-3-UPDOWN: Interface Async37, changed state to down
CalCity_LAC#

In highlighted line 1 (Example 4-53), the L2TP tunnel is shut down. Then in highlighted line 2, interface async 37 changes state to down. Tunnel establishment has failed.

You can see from the output of debug vpdn l2x-events that the LAC was sending L2TP SCCRQ messages to the LNS, but there was no response from the LNS.

The configuration of the VPDN group on the LNS is now examined. Example 4-54 shows the output of the show running-config command on the LNS. Only the relevant portion of the output is shown.

Example 4-54. Verifying VPDN Group Configuration

Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
 accept-dialin
  protocol l2f
  virtual-template 1
 terminate-from hostname CalCity_LAC
!

As you can see, highlighted line 2 shows that the LNS is correctly configured to terminate tunnels from the LAC (CalCity_LAC).

Highlighted line 1, however, shows that the LNS is unfortunately configured to terminate not L2TP but instead L2F tunnels. There is no way that is going to work. The VPDN group needs to be reconfigured to terminate L2TP instead of L2F tunnels.

Example 4-55 shows reconfiguration of the VPDN group to terminate L2TP tunnels.

Example 4-55. Reconfiguration of the VPDN Group

Skydance_LNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Skydance_LNS(config)#vpdn-group 1
Skydance_LNS(config-vpdn)#accept-dialin
Skydance_(config-vpdn-acc-in)#protocol l2tp
Skydance_(config-vpdn-acc-in)#exit
Skydance_LNS(config-vpdn)#terminate-from hostname CalCity_LAC
Skydance_LNS(config-vpdn)#exit
Skydance_LNS#

In highlighted line 1, the protocol is changed to L2TP.

One thing to notice in the reconfiguration of the VPDN group is that after the protocol has been modified to L2TP, it is also necessary to re-enter the hostname of the LAC from which the tunnel will be terminated (highlighted line 2).

After the tunnel protocol on the LNS is reconfigured, the remote access client reconnects to the LAC. This time tunnel setup is successful. Successful tunnel establishment is verified using the show vpdn tunnel all command. Example 4-56 shows the output of the show vpdn tunnel all command after successful tunnel establishment.

Example 4-56. Verifying L2TPv2 Tunnel Setup

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 41497 is up, remote id is 22228, 1 active sessions
  Tunnel state is established, time since change 00:00:57
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  49 packets sent, 35 received
  6778 bytes sent, 1924 received
  Control Ns 4, Nr 2
  Local RWS 800 (default), Remote RWS 800 (max)
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 0
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

In highlighted line 1, you can see that one L2TP tunnel and one session have been established successfully. The remote tunnel name is shown in highlighted line 2 (Skydance_LNS).

The IP address of the LNS (172.16.5.5), along with the UDP port (1701) on which the L2TP connection has been made, is shown in highlighted line 3.

The local hostname (CalCity_LAC) is shown in highlighted line 4. In the next line, the IP address of the local host, along with the UDP port upon which the L2TP connection has been made, is shown.

Tunnel Authentication Failure

If tunnel authentication is being used between the LAC and the LNS (and it should be), authentication failure is another possible cause of tunnel establishment failure.

Before diving into an examination of the output of the applicable show and debug commands, it is worth re-examining the mechanics of L2TP tunnel setup with particular emphasis on authentication.

When the LAC sends the SCCRQ message to the LNS to initiate control connection (tunnel) setup, included with it is an authentication challenge.

The LNS responds to the SCCRQ with an SCCRP. Contained within the SCCRP are two things that are directly relevant to tunnel authentication:

• A response to the authentication challenge sent by the LAC in the SCCRQ.

• An authentication challenge from the LNS.

The LAC receives the SCCRP and authenticates the response from the LNS. If the response is no good, the LAC responds with a StopCCN. The StopCCN, as the name implies, is used to inform the LNS that the control connection is to be torn down.

If the authentication response from the LNS is good, the LAC responds with a SCCCN. The SCCCN contains the response to the challenge in the SCCRP. When the LNS receives the SCCCN, it authenticates the response. If the response is no good, it notifies the LAC using a StopCCN message.

Once the LNS has successfully authenticated the LAC, the control connection is successfully established, and session establishment can begin. That is what should happen, in theory.

To begin, have a look at what happens in practice by first examining the output of the debug vpdn l2x-events command when successful tunnel setup is successful. This output will then be compared to output of the same command when tunnel setup does not succeed because of an authentication failure.

Examples 4-57 to 4-60 show the output of the debug vpdn l2x-events command when tunnel setup is successful. Only the relevant portion of the output is shown.

Example 4-57. L2TP Tunnel Authentication Succeeds

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb  6 00:17:21.462 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:17:27.462 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:17:50.994 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb  6 00:17:56.266 UTC: Tnl 63312 L2TP: SM State idle

Highlighted line 1 shows interface serial 0/0:0 connected to the remote access client (1111). In highlighted line 2, interface async 35 changes state to up. The remote access client is connected to one of the LAC's internal digital modems.

An SCCRQ is then sent by the LAC to the LNS, as demonstrated in Example 4-58. Remember that this SCCRQ contains an authentication challenge.

Example 4-58. LAC Sends a SCCRQ

Feb  6 00:17:56.266 UTC: Tnl 63312 L2TP: O SCCRQ
Feb  6 00:17:56.266 UTC: Tnl 63312 L2TP: Tunnel state change from idle to
  wait-ctl-reply
Feb  6 00:17:56.266 UTC: Tnl 63312 L2TP: SM State wait-ctl-reply

In Example 4-59, the LNS responds with an SCCRP.

Example 4-59. LNS Responds with a SCCRP

Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: I SCCRP from Skydance_LNS
Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: Got a challenge from remote peer,
  Skydance_LNS
Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: Got a response from remote peer, Skydance_LNS
Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: Tunnel Authentication success
Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: Tunnel state change from wait-ctl-reply to
  Established

In highlighted line 1 (Example 4-59), the LNS responds to the SCCRQ with an SCCRP. Highlighted lines 2 and 3 show that the LAC has received a challenge from the remote peer (Skydance_LNS), together with a response. Both the challenge and response are contained within the SCCRP.

The first thing that LAC does is to examine the response from the LNS. This is the point at which, if the response is incorrect, the LAC will send a StopCCN to the LNS.

Happily, in highlighted line 4, you can see that tunnel authentication has been a success. Because the response in the SCCRP was good, the LAC sends an SCCCN to the LNS in Example 4-60.

Example 4-60. LAC Sends an SCCN

Feb  6 00:17:56.274 UTC: Tnl 63312 L2TP: O SCCCN  to Skydance_LNS tnlid 62661
Feb  6 00:17:56.278 UTC: Tnl 63312 L2TP: SM State established
Feb  6 00:17:56.282 UTC: Tnl/Cl 63312/26 L2TP: Session FS enabled
Feb  6 00:17:56.282 UTC: Tnl/Cl 63312/26 L2TP: Session state change from idle to
  wait-for-tunnel
Feb  6 00:17:56.282 UTC: As35 Tnl/Cl 63312/26 L2TP: Create session
Feb  6 00:17:56.282 UTC: Tnl 63312 L2TP: SM State established

The SCCCN shown in Example 4-50 contains the LAC's response to the challenge contained within the SCCRP. The LNS authenticates the response, and if this is unsuccessful, it sends a StopCCN to the LAC.

No such message is received from the LNS, implying that authentication was successful. The LAC can now begin session setup (not shown).

That is successful tunnel setup including authentication. What happens when things do not go so well? By using the debug vpdn l2x-events command, the sequence of events can again be examined.

Examples 4-61 to 4-65 show the output of the debug vpdn l2x-events command when tunnel setup is unsuccessful.

Example 4-61. L2TP Tunnel Authentication Fails

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb  6 00:23:05.702 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:23:11.702 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
  to 1111
Feb  6 00:23:35.270 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to up
CalCity_LAC#
Feb  6 00:23:40.530 UTC: Tnl 19591 L2TP: SM State idle

Interface serial 0/0:0 is shown connected to the remote access client (1111) in highlighted line 1.

Highlighted line 2 shows interface async 38 changing state to up. The remote access client is now connected to the internal digital modem on line 38.

The LAC now sends an SCCRQ to the LNS, as shown in Example 4-62. Remember, this SCCRQ contains an authentication challenge.

Example 4-62. LAC Sends a SCCRQ

Feb  6 00:23:40.530 UTC: Tnl 19591 L2TP: O SCCRQ
Feb  6 00:23:40.534 UTC: Tnl 19591 L2TP: Tunnel state change from idle to
  wait-ctl-reply
Feb  6 00:23:40.534 UTC: Tnl 19591 L2TP: SM State wait-ctl-reply

The LNS responds with a SCCRP, as shown in Example 4-63.

Example 4-63. LNS Responds with a SCCRP

Feb  6 00:23:40.538 UTC: Tnl 19591 L2TP: I SCCRP from Skydance_LNS
Feb  6 00:23:40.538 UTC: Tnl 19591 L2TP: Got a challenge from remote peer,
  Skydance_LNS
Feb  6 00:23:40.538 UTC: Tnl 19591 L2TP: Got a response from remote peer, Skydance_LNS
Feb  6 00:23:40.538 UTC: Tnl 19591 L2TP: Tunnel auth failed for Skydance_LNS
Feb  6 00:23:40.538 UTC: Tnl 19591 L2TP: Expected
     AD 08 DF AD 63 44 1A 57 85 56 B3 D5 83 A6 35 33
Feb  6 00:23:40.542 UTC: Tnl 19591 L2TP: Got
     5D ED C2 31 4D 33 CF 82 33 06 E0 61 E0 BB 2A 2C

Highlighted line 1 (Example 4-63) shows an inbound SCCRP from the LNS (Skydance_LNS). The response to the challenge in the SCCRQ and the LNS's own challenge to the LAC are contained within the SCCRP, as shown in highlighted lines 2 and 3.

But take a look at highlighted line 4. The LAC has examined the response from the LNS, and an authentication failure has resulted.

Further information is revealed in highlighted lines 5 and 6. Highlighted line 5 shows the MD5 hash (response) that the LAC was expecting from the LNS in the SCCRP. Highlighted line 6 shows the MD5 hash that was in fact received. As you can see, they are quite different, and so authentication failed.

Unsurprisingly, the LAC now terminates the control connection by sending a StopCCN message to the LNS, as demonstrated in Example 4-64.

Example 4-64. LAC Sends a StopCCN

Feb  6 00:23:40.542 UTC: Tnl 19591 L2TP: O StopCCN  to Skydance_LNS tnlid 37558
Feb  6 00:23:40.542 UTC: Tnl 19591 L2TP: Tunnel state change from wait-ctl-reply to
  shutting-down

The L2TP tunnel is finally shut down in Example 4-65.

Example 4-65. L2TP Tunnel Is Shut Down

Feb  6 00:23:40.546 UTC: Tnl 19591 L2TP: Shutdown tunnel
Feb  6 00:23:40.546 UTC: Tnl 19591 L2TP: Tunnel state change from shutting-down to
  Idle
Feb  6 00:23:40.702 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0  disconnected
  from 1111 , call lasted 35 seconds
Feb  6 00:23:42.550 UTC: %LINK-5-CHANGED: Interface Async38, changed state to reset
Feb  6 00:23:49.414 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to down
CalCity_LAC#

Highlighted line 1 (Example 4-65) shows that the tunnel has now been shut down, and in highlighted line 2, interface serial 0/0:0 is disconnected from the remote access client. Finally, in highlighted line 3, interface async 38 changes state to down. The tunnel setup attempt has failed, and the connection has been terminated.

Although the output in Example 4-63 shows authentication failing on the LAC, that does not necessarily indicate that the tunnel password is incorrectly configured on the LNS. It could be that the password is incorrectly configured on the LAC, and the LAC is simply expecting a hash calculated using an incorrect password.

Because service password-encryption is enabled (and tunnel passwords are encrypted in the LAC and LNS's configuration files), it is impossible to know whether the password is incorrectly configured on the LAC or the LNS. The password must, therefore, by reconfigured on both.

Example 4-66 shows the reconfiguration of the L2TP tunnel password on the LAC and the LNS.

Example 4-66. Reconfiguration of the L2TP Tunnel Password on the LAC and LNS

! On the LAC:
Calcity_LAC#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Calcity_LAC (config)#vpdn-group 1
Calcity_LAC(config-vpdn)#l2tp tunnel password cisco
Calcity_LAC(config-vpdn)#exit
Calcity_LAC#


! On the LNS:
Skydance_LNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Skydance_LNS(config)#vpdn-group 1
Skydance_LNS(config-vpdn)#l2tp tunnel password cisco
Skydance_LNS(config-vpdn)#exit
Skydance_LNS#

After the L2TP tunnel passwords on the LAC and the LNS are reconfigured, the remote access client reconnects. This time, L2TP tunnel setup is successful. This is confirmed using the show vpdn tunnel all command.

Example 4-67 shows the output of the show vpdn tunnel all command.

Highlighted line 1 shows that one tunnel and one session have been successfully established. Highlighted lines 2 and 3 show the hostname of the remote peer (Skydance_LNS), along with its IP address and the UDP port over which the connection has been established (172.16.5.5 and 1701, respectively).

Example 4-67. Verifying Successful L2TP Tunnel Setup

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 5078 is up, remote id is 57551, 1 active sessions
  Tunnel state is established, time since change 00:00:27
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  46 packets sent, 28 received
  6628 bytes sent, 1556 received
  Control Ns 4, Nr 2
  Local RWS 800 (default), Remote RWS 800 (max)
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 0
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

Highlighted lines 4 and 5 show the local hostname (Calcity_LAC), as well as the local IP address and the UDP port over which the connection was established (172.16.1.1 and 1701).

L2TPv2 Session Establishment Failure

As soon as tunnel establishment has succeeded, session setup can begin. If session setup is not successful, user traffic will not be passed over the tunnel between the LAC and the LNS.

L2TP session setup is illustrated in Figure 4-26.

Figure 4-26. L2TP Session Establishment

[View full size image]

To establish the data session, the LAC sends an ICRQ message. Assuming that sufficient resources are available, the LNS replies with an ICRP. Finally, the LAC sends an ICCN message to the LNS. The data session is now established.

Before looking at session setup failure, it is worth examining successful session setup using the debug vpdn l2x-events command.

Example 4-68 shows the output of the debug vpdn l2x-events command.

Example 4-68. Successful L2TP Session Establishment

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb  5 23:50:85.862 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
  to 1111
Feb  5 23:51:06.550 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb  5 23:51:09.860 UTC: Tnl 63403 L2TP: SM State established
Feb  5 23:51:09.864 UTC: Tnl/Cl 63403/22 L2TP: Session FS enabled
Feb  5 23:51:09.864 UTC: Tnl/Cl 63403/22 L2TP: Session state change from idle
  to wait-for-tunnel
Feb  5 23:51:09.864 UTC: As38 Tnl/Cl 63403/22 L2TP: Create session
Feb  5 23:51:09.864 UTC: Tnl 63403 L2TP: SM State established
Feb  5 23:51:09.864 UTC: As38 Tnl/Cl 63403/22 L2TP: O ICRQ to Skydance_LNS 52441/0
Feb  5 23:51:09.868 UTC: As38 Tnl/Cl 63403/22 L2TP: Session state change from
  wait-for-tunnel to wait-reply
Feb  5 23:51:09.872 UTC: As38 Tnl/Cl 63403/22 L2TP: O ICCN to Skydance_LNS 52441/22
Feb  5 23:51:09.876 UTC: As38 Tnl/Cl 63403/22 L2TP: Session state change from
  wait-reply to established
Feb  5 23:51:10.868 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async38,
  changed state to up
CalCity_LAC#

In highlighted line 1, interface serial 0/0:1 is connected to the 1111. Then in highlighted line 2, interface async 35 changes state to up. The remote access client is connected to the digital modem on line 35.

The LAC now initiates data session setup with the LNS by sending an ICRQ (highlighted line 3).

Note that no SCCRQ message is sent. This is because the SCCRQ message is used during L2TP tunnel (control connection) setup but is not necessary when establishing a new session within a tunnel that already exists.

In highlighted line 4, an ICCN is shown being sent from the LAC to the LNS. What happened to the ICRP? It is sent by the LNS and received by the LAC, but it is not shown in this debug output.

For more information on the L2TP session, you can use the show vpdn session command, as demonstrated in Example 4-69.

Example 4-69. Verifying L2TP Session Establishment

CalCity_LAC#show vpdn session
L2TP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Intf          Username               State  Last Chg Fastswitch
18    18    12471 As34          ltahoe@mjlnet.com       est    00:01:17 enabled
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

Highlighted line 1 shows the local and remote session IDs (18/18), the local tunnel ID (12471), the username associated with the session (ltahoe@mjlnet.com), the session state (ESTABLISHED), the length of time since the last session state change, and whether fast switching is enabled for this session.

If L2TP session setup fails, the most common cause is the configuration of a session limit or VPDN softshut. VPDN softshut is a mechanism that allows graceful shutdown of L2TP (or other VPDN) tunnels and sessions. By using this command, the administrator can cause the LNS or LAC to refuse any more L2TP sessions. Existing sessions, however, continue until naturally disconnected. When configured, VPDN softshut can give the appearance of an error.

When troubleshooting this "issue," the first command to use is again debug vpdn l2x-events.

Examples 4-70 to 4-73 show the output of the debug vpdn l2x-events command when VPDN softshut is configured on the LNS.

Example 4-70. L2TP Session Setup Fails

CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 11 21:55:04.106 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
  to 1111
Feb 11 21:55:25.666 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 11 21:55:28.918 UTC:   Tnl/Sn16357/28 L2TP: Session FS enabled
Feb 11 21:55:28.918 UTC:   Tnl/Sn16357/28 L2TP: Session state change from idle to
  wait-for-tunnel

Highlighted line 1 shows interface serial 0/0:1 connected to 1111. Then in highlighted line 2, interface async 35 changes state to up. The remote access client is connected to the internal digital modem on line 35.

In Example 4-71, L2TP session setup begins.

Example 4-71. L2TP Session Setup Begins

Feb 11 21:55:28.922 UTC: As35  Tnl/Sn16357/28 L2TP: Create session
Feb 11 21:55:28.922 UTC:   Tnl16357 L2TP: SM State established
Feb 11 21:55:28.922 UTC: As35  Tnl/Sn16357/28 L2TP: O ICRQ to Skydance_LNS 7063/0
Feb 11 21:55:28.922 UTC:   Tnl16357 L2TP: Control channel retransmit delay set to
  1 seconds
Feb 11 21:55:28.922 UTC: As35  Tnl/Sn16357/28 L2TP: Session state change from
  wait-for-tunnel to wait-reply

In highlighted line 1 (Example 4-71), a new L2TP session is created for the remote access client. An ICRQ is sent to the LNS to initiate session setup in highlighted line 2. The LNS now sends a CDN, as shown in Example 4-72.

Example 4-72. LNS Sends a CDN

Feb 11 21:55:28.930 UTC: As35  Tnl/Sn16357/28 L2TP: I CDN from Skydance_LNS
  tnl 7063, cl 0
Feb 11 21:55:28.930 UTC: As35  Tnl/Sn16357/28 L2TP: Destroying session
Feb 11 21:55:28.930 UTC: As35  Tnl/Sn16357/28 L2TP: Session state change from
  wait-reply to idle
Feb 11 21:55:28.930 UTC: As35  Tnl/Sn16357/28 L2TP: Releasing idb for LAC/LNS
  tunnel 16357/7063 session 28 state idle

In Example 4-72, highlighted line 1 shows the CDN from the LNS. The CDN is used by the LNS to request that the LAC disconnect the call session from the remote access client. The session is then shut down by the LAC in highlighted line 2. Finally, in Example 4-73, the remote access client is disconnected.

Example 4-73. Remote Access Client Is Disconnected

Feb 11 21:55:29.026 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:1  disconnected
  from 1111 , call lasted 30 seconds
Feb 11 21:55:30.938 UTC: %LINK-5-CHANGED: Interface Async35, changed state to reset
Feb 11 21:55:35.938 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to down
CalCity_LAC#

In highlighted line 1 (Example 4-73), interface serial 0/0:1 is disconnected, and interface async 35 changes state to DOWN (highlighted line 2). The remote access client has been disconnected.

The reason that the LNS requested disconnection of the session from the remote access client can be seen by examining the Result and Error codes contained within the CDN message sent by the LNS to the LAC (Example 4-72, highlighted line 1).

To examine the Result and Error codes in the CDN, use the debug vpdn l2x-errors command when the remote access client reconnects, as demonstrated in Example 4-74.

Example 4-74. Verifying the Result and Error Codes in the CDN

CalCity_LAC#debug vpdn l2x-errors
L2X protocol errors debugging is on
CalCity_LAC#
Feb 11 21:56:16.330 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
  to 1111
Feb 11 21:56:39.874 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to up
Feb 11 21:56:45.130 UTC: As36  Tnl/Sn16357/29 L2TP: Result code(2): 2: Call
  disconnected, refer to error msg
Feb 11 21:56:45.130 UTC:      Error code(6): Vendor specific
Feb 11 21:56:45.130 UTC:      Optional msg: Session limit
Feb 11 21:56:45.226 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:1  disconnected
  from 1111 , call lasted 34 seconds
Feb 11 21:56:47.138 UTC: %LINK-5-CHANGED: Interface Async36, changed state to reset
Feb 11 21:56:52.138 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to down
CalCity_LAC#

Interface serial 0/0:1 is connected to 1111 in highlighted line 1. Interface async 36 then changes state to up (highlighted line 2). The remote access client is now connected to the internal digital modem on line 36.

In highlighted line 3, the Result Code contained within the CDN message sent by the LNS to the LAC is displayed. The Result Code is 2, indicating that the reason for the disconnect is shown by the Error Code.

The Error Code 6 in highlighted line 4 indicates that this is a vendor-specific error. That does not tell you very much, but the Error Message Field included in the CDN indicates that call disconnection was requested because of a session-limit configured on the LNS (highlighted line 5).

More information regarding Result and Error Codes carried in CDN messages can be found in Tables 4-5 and 4-6 at the beginning of this chapter.

Highlighted line 6 then shows interface serial 0/0:1 disconnecting from the remote access client, and in highlighted line 7 interface async 36 changes state to down.

The error message shown means one of two things: either a session limit or VPDN softshut is configured on the LNS.

Using the show vpdn tunnel all command, you can see the current number of sessions established within the tunnel to the LNS, as demonstrated in Example 4-75.

Example 4-75. Verifying the L2TP Tunnel and Associated Sessions

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 46935 is up, remote id is 61101, 1 active sessions
  Tunnel state is established, time since change 00:01:01
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  VPDN group for tunnel is 1
  43 packets sent, 33 received
  5796 bytes sent, 1880 received
  Control Ns 4, Nr 3
  Local RWS 800 (default), Remote RWS 800 (max)
  Tunnel PMTU checking disabled
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 1
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

Highlighted line 1 shows that one tunnel and one session are established.

The configuration of the LNS is then examined using the show running-config command. Example 4-76 shows the output of the show running-config command on the LNS. Note that only the relevant portion of the output is shown.

Example 4-76. VPDN Group Configuration

Skydance_LNS#show running-config
Building configuration...
vpdn enable
vpdn softshut
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp tunnel password 7 01100F175804
!

In highlighted line 1, you can see that VPDN softshut is indeed configured on the LNS. This will prevent any new sessions been established within the L2TP tunnel from the LAC.

To allow new sessions to be established within the L2TP tunnel, VPDN softshut must be disabled. The VPDN softshut is disabled using the no vpdn softshut command on the LNS.

Example 4-77 shows vpdn softshut being disabled on the LNS.

Example 4-77. VPDN Softshut Is Disabled on the LNS

Skydance_LNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Skydance_LNS(config)#no vpdn softshut
Skydance_LNS(config)#exit
Skydance_LNS#

Once VPDN softshut has been disabled on the LNS, the remote access client reconnects to the LAC, and session setup succeeds. To verify this, the show vpdn tunnel all command is used.

Example 4-78 shows the output of the show vpdn tunnel all command.

Example 4-78. L2TP Session Setup Succeeds

CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 2
Tunnel id 46935 is up, remote id is 61101, 2 active sessions
  Tunnel state is established, time since change 00:03:27
  Remote tunnel name is Skydance_LNS
    Internet Address 172.16.5.5, port 1701
  Local tunnel name is CalCity_LAC
    Internet Address 172.16.1.1, port 1701
  VPDN group for tunnel is 1
  77 packets sent, 103 received
  8603 bytes sent, 5976 received
  Control Ns 6, Nr 4
  Local RWS 800 (default), Remote RWS 800 (max)
  Tunnel PMTU checking disabled
  Retransmission time 1, max 1 seconds
  Unsent queuesize 0, max 0
  Resend queuesize 0, max 2
  Total resends 0, ZLB ACKs sent 1
  Current nosession queue check 0 of 5
  Retransmit time distribution: 0 0 0 0 0 0 0 0 0
  Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#

Note that there are now two sessions within the tunnel to the LNS (highlighted line 1). The issue has been resolved.

As previously mentioned, this issue can also occur if a session limit is configured using the vpdn session-limit sessions command. This command limits the number of sessions to the number specified. If a new session causes this limit to be exceeded, session setup will fail. In this case, either remove the session limit (no vpdn session-limit sessions) or revise the limit upward.

LNS/Remote Access Client PPP Negotiation Failure

After the L2TP tunnel and session have been established between the LAC and the LNS, the next stage is for the LNS to complete PPP negotiation with the remote access client. Specifically, the LNS must complete LCP negotiation and PPP authentication and then negotiate NCPs with the remote access client. Note that the LNS can be configured to renegotiate LCP with the remote access client using the lcp renegotiation command under the VPDN group.

Before the LNS can begin PPP negotiation with the remote access client, a virtual access interface must be cloned from the virtual template interface.

Figure 4-27 shows cloning of the virtual access interface from the virtual template.

Figure 4-27. Virtual Access Interface Is Cloned

[View full size image]

You can use the debug vtemplate command to verify cloning of virtual template configuration to virtual access interfaces, as demonstrated in Example 4-79.

Example 4-79. Cloning the Virtual Access Interface from the Virtual Template

CalCity_LAC#debug vtemplate
Virtual Template debugging is on
Skydance_LNS#
Feb  6 01:22:30.925 UTC: Vt1 VTEMPLATE: Unable to create and clone vaccess
Feb  6 01:22:30.925 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0
Feb  6 01:22:30.925 UTC: Vi1 VTEMPLATE: Hardware address 00d0.6354.7000
Feb  6 01:22:30.925 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vtemplate
Feb  6 01:22:30.925 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1 *****************
Feb  6 01:22:30.925 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1interface
  Virtual-Access1
default ip address
no ip address
encap ppp
ip unnumbered Ethernet1/0
peer default ip address pool PERRIS_POOL
ppp authentication chap
ppp multilink
End
Feb  6 01:22:30.985 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to up
Feb  6 01:22:31.985 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to up
Skydance_LNS#

Highlighted line 1 indicates that configuration is about to be cloned to virtual access interface 1. In highlighted line 2, configuration is cloned from virtual template interface 1 to virtual access interface 1.

From highlighted lines 3 to 7, the configuration from the virtual template interface is shown as it is copied to the virtual access interface. If the virtual access interface is not successfully cloned from the virtual template, check that the virtual template is correctly referenced under the VPDN group.

Use the show running-config command to verify that the virtual template is corrected referenced, as shown in Example 4-80.

Example 4-80. Verifying the Virtual Template Reference Under the VPDN Group

Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp tunnel password 7 01100F175804
!

In this example, the virtual template interface is correctly referenced under the VPDN group.

If user-specific configuration is stored on a AAA server, make sure that as you troubleshoot PPP negotiation you verify this configuration, and ensure that it is being downloaded to the LNS.

LCP Negotiation or PPP Authentication Failure on the LNS

After the virtual access interface has been cloned from the virtual template interface, PPP negotiation begins between the LNS and the remote access client. PPP negotiation involves forced LCP, PPP authentication, and NCP setup. If LCP negotiation or PPP authentication fails on the LNS, NCPs are not negotiated, and the remote access client is disconnected.

Figure 4-28 shows LCP Negotiation and PPP authentication on the LNS.

Figure 4-28. LCP Negotiation and PPP Authentication on the LNS

[View full size image]

The LNS can complete LCP negotiation and PPP authentication using information sent to it by the LAC during L2TP session setup, or it can choose to renegotiate LCP or reauthenticate the remote access client.

Before examining LCP negotiation or PPP authentication failure on the LNS, it is useful to examine what happens when LCP negotiation and PPP authentication is successful.

Use the debug ppp negotiation command to examine the LCP negotiation and PPP authentication sequence. Note that the debug ppp authentication command can also be used to examine the PPP authentication sequence.

Examples 4-81 to 4-84 show the output of the debug ppp negotiation command when LCP negotiation and PPP authentication is successful. Only the relevant portion of the output is shown.

Example 4-81. Successful PPP Authentication on the LNS

Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb  6 01:29:07.677 UTC: Vi1 PPP: Phase is DOWN, Setup
Feb  6 01:29:07.749 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to up
Feb  6 01:29:07.749 UTC: Vi1 PPP: Using set call direction
Feb  6 01:29:07.749 UTC: Vi1 PPP: Treating connection as a callin
Feb  6 01:29:07.749 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open
Feb  6 01:29:07.749 UTC: Vi1 LCP: State is Listen

In highlighted line 1, virtual-access interface 1 changes state to up. Then in highlighted line 2, the PPP phase changes to ESTABLISHING. This indicates that LCP negotiation is about to begin. LCP negotiation begins in Example 4-82.

Example 4-82. Incoming FORCED CONFREQ

Feb  6 01:29:07.749 UTC: Vi1 LCP: I FORCED CONFREQ len 21
Feb  6 01:29:07.749 UTC: Vi1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    MagicNumber 0x130FE417 (0x0506130FE417)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    PFC (0x0702)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    ACFC (0x0802)

Highlighted line 1 (Example 4-82) shows an inbound (I) FORCED CONFREQ. This CONFREQ has special significance. If you have already read the technical overview at the beginning of this chapter, this may seem familiar. It is in fact the last CONFREQ sent by the LAC to the remote access client during initial PPP negotiation and passed to the LNS by the LAC (in the ICCN message) during session setup.

LCP negotiation continues in Example 4-83.

Example 4-83. Incoming FORCED CONFACK

Feb  6 01:29:07.749 UTC: Vi1 LCP: I FORCED CONFACK len 39
Feb  6 01:29:07.749 UTC: Vi1 LCP:    ACCM 0x00000000 (0x020600000000)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    MagicNumber 0x1D9A61B9 (0x05061D9A61B9)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    PFC (0x0702)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    ACFC (0x0802)
Feb  6 01:29:07.749 UTC: Vi1 LCP:    EndpointDisc 1 Local
Feb  6 01:29:07.749 UTC: Vi1 LCP:     (0x13170190699D7655924F3481F6E9E6D7)
Feb  6 01:29:07.749 UTC: Vi1 LCP:     (0x6EFD0A00000000)

The LNS now begins processing an inbound FORCED CONFACK (Example 4-83). This "CONFACK" is in fact the CONFREQ received by the LAC from the remote access client during initial PPP negotiation. Again, this is forwarded to the LNS in the ICCN message.

The purpose of the FORCED CONFREQ and CONFACK (CONFREQ) is to allow the LNS not to have to renegotiate LCP with the remote access client. These two CONFREQs tell the LNS what LCP options were negotiated between the LAC and the remote access client.

See Table 4-9 at the beginning of the chapter for more details on LCP and PPP authentication information passed to the LNS by the LAC during session setup.

The LNS now has a choice. It can either accept the LCP options negotiated between the remote access client and the LAC, or it can renegotiate LCP. This can be useful when, for example, the LAC rejects configuration of certain LCP options that the LNS is able to support. If you want the LNS to renegotiate LCP with the remote access client, you can configure the lcp renegotiation {always | on-mismatch} command under the VPDN group on the LNS.

The lcp renegotiation {always | on-mismatch} command can also be very useful if the LNS rejects LCP options negotiated between the remote access client and the LAC and passed to the LNS by the LAC during L2TP session setup. In this case, you will see a message such as PPP LCP not accepting sent CONFACK when using the debug ppp negotiation command on the LNS.

In Example 4-84, PPP authentication begins.

Example 4-84. PPP Authentication Begins

Feb  6 01:29:07.749 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb  6 01:29:07.753 UTC: Vi1 CHAP: O CHALLENGE id 12 len 33 from "Skydance_LNS"
Feb  6 01:29:07.753 UTC: Vi1 CHAP: I RESPONSE id 11 len 37 from
  "ltahoe@mjlnet.com"
Feb  6 01:29:07.753 UTC: Vi1 CHAP: O SUCCESS id 11 len 4
Feb  6 01:29:07.753 UTC: Vi1 PPP: Phase is UP

Highlighted line 1 (Example 4-84) shows the PPP phase change to AUTHENTICATING. Authentication is about to begin.

In highlighted line 2, the LNS sends a CHAP challenge to the remote access client, and in highlighted line 3, the remote access client sends its response.

Finally, a CHAP success message is sent by the LNS to the remote access client in highlighted line 4, indicating authentication has been successful.

That is successful PPP authentication, but what happens when authentication is unsuccessful? In Examples 4-85 to 4-86, PPP authentication is not successful, as shown in output from the debug ppp negotiation command. Note that only the relevant portion of the output is shown.

Example 4-85. PPP Authentication Is Unsuccessful

Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on

Feb  6 01:31:16.993 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb  6 01:31:16.997 UTC: Vi1 CHAP: O CHALLENGE id 12 len 33 from "Skydance_LNS"
Feb  6 01:31:16.997 UTC: Vi1 CHAP: I RESPONSE id 11 len 37 from
  "ltahoe@mjlnet.com"
Feb  6 01:31:16.997 UTC: Vi1 CHAP: O FAILURE id 11 len 25 msg is
  "MD/DES compare failed"

PPP authentication begins in highlighted line 1, with the PPP phase changing to AUTHENTICATING. In highlighted line 2, the LNS sends a CHAP challenge to the remote access client, and the remote access client replies with a CHAP response message shown in highlighted line 3. Note the name of the remote access client (ltahoe@mjlnet.com).

Everything looks good until highlighted line 3, when the LNS sends a CHAP failure message to the remote access client. Authentication of the remote access client by the LNS has failed.

PPP negotiation now terminates, as shown in Example 4-86.

Example 4-86. PPP Negotiation Terminates

Feb  6 01:31:16.997 UTC: Vi1 PPP: Phase is TERMINATING
Feb  6 01:31:16.997 UTC: Vi1 LCP: O TERMREQ [Open] id 1 len 4
Feb  6 01:31:18.997 UTC: Vi1 LCP: TIMEout: State TERMsent
Feb  6 01:31:18.997 UTC: Vi1 LCP: O TERMREQ [TERMsent] id 2 len 4
Feb  6 01:31:20.641 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to down
Feb  6 01:31:20.641 UTC: Vi1 LCP: State is Closed
Feb  6 01:31:20.641 UTC: Vi1 PPP: Phase is DOWN
Skydance_LNS#

The PPP phase then changes to TERMINATING (highlighted line 1), and in highlighted line 2, the LNS sends a termination request (TERMREQ) to the remote access client. In highlighted line 3, the virtual-access interface changes state to down. Finally, in highlighted line 4, the PPP phase changes to DOWN. Authentication has failed, and PPP negotiation has been terminated.

Authentication failure can be due to an incorrect username or password configured on either the remote access client or the LNS. In this case, the remote user confirms that the username and password are correct. This means that either the username or password for the remote access client is incorrectly configured on the LNS. The username and password are then reconfigured on the LNS.

Example 4-87 shows the reconfiguration of the remote access client's username and password on the LNS.

Example 4-87. Remote Access Client's Username and Password Are Reconfigured

Skydance_LNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Skydance_LNS(config)#username ltahoe@mjlnet.com password cisco
Skydance_LNS(config)#exit
Skydance_LNS#

Once the remote access client's username and password are reconfigured, the remote access client reconnects. PPP negotiation is now successful.

Successful PPP negotiation, including authentication, is verified using the show caller user command, as demonstrated in Example 4-88.

Example 4-88. Verifying Successful PPP Negotiation

Skydance_LNS#show caller user ltahoe@mjlnet.com
  User: ltahoe@mjlnet.com, line Vi1, service PPP L2TP
        Active time 00:00:33, Idle time 00:00:00
  Timeouts:            Absolute  Idle
      Limits:          -         -
      Disconnect in:   -         -
  PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
  IP: Local 172.16.5.5, remote 10.1.1.1
  VPDN: NAS CalCity_LAC, MID 34, MID Unknown
        HGW , NAS CLID 0, HGW CLID 0, tunnel open
  Counts: 41 packets input, 3990 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          28 packets output, 1200 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#

Highlighted line 1 shows the username (ltahoe@mjlnet.com), the line (virtual-access interface 1), and the service (PPP over L2TP) associated with the user.

Highlighted line 2 shows the negotiated PPP options. As you can see, LCP is in an open state, PPP multilink has not been negotiated, the local host is authenticating the remote access client, and IPCP has been negotiated.

Highlighted line 3 shows the local and remote access client's IP addresses (172.16.5.5 and 10.1.1.1, respectively). Finally, in highlighted line 4, the name of the LAC (CalCity_LAC) is shown. Successful PPP negotiation has been confirmed, and the issue has been resolved.

If you are using a AAA server to authenticate and authorize remote access clients, also see "Case Study 2: Remote AAA (RADIUS) Authentication Failure on the LNS," "Case Study 3: Remote AAA (RADIUS) Authorization Failure on the LNS," and "Case Study 4: AAA (RADIUS) Server Unreachable from the LNS."

NCP Negotiation Failure on the LNS

Once PPP authentication has succeeded for the remote access client on the LNS, the next stage in the PPP negotiation sequence is negotiation of NCPs. NCPs include the IPCP and the IPXCP.

A common cause of NCP negotiation failure is misconfiguration of network layer protocols (for example, IP or IPX) on the virtual template interface. NCP negotiation between the remote access client and the LNS is shown in Figure 4-29.

Figure 4-29. NCP Negotiation Between the Remote Access Client and the LNS

[View full size image]

Before examining what happens when NCP negotiation fails, it is worth taking a look at what happens when NCP negotiation succeeds. Use the debug ppp negotiation command to examine NCP negotiation between the remote access client and the LNS.

Examples 4-89 to 4-101 show the output of the debug ppp negotiation command when NCP negotiation is successful. Note that only the relevant portion of the output is shown.

Example 4-89. Successful NCP Negotiation

Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#

Feb  6 01:36:10.445 UTC: Vi1 PPP: Phase is UP

In Example 4-89, the PPP phase changes to UP, and NCP negotiation begins.

In Example 4-90, the LNS sends an outgoing (O) IPCP CONFREQ to the remote access client. Contained within this CONFREQ is the IPCP address option (0x03, IP Address). This IPCP option is used to communicate the IP address of the local system, which in this case is the IP address applied to virtual-access interface 1 (172.16.5.5).

Example 4-90. LNS Sends a CONFREQ

Feb  6 01:36:10.445 UTC: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
Feb  6 01:36:10.445 UTC: Vi1 IPCP:    Address 172.16.5.5 (0x0306AC100505)

In Example 4-91, the remote access client then sends a Compression Control Protocol (CCP) CONFREQ to the LNS. This CONFREQ contains one CCP option, which is Microsoft Point-to-Point Compression (MS-PPC) (0x12).

Example 4-91. Remote Access Client Sends a CONFREQ

Feb  6 01:36:10.565 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 7 len 10
Feb  6 01:36:10.565 UTC: Vi1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)

Notice the supported bits contained within the MS-PPC option in Example 4-91 (0x00000001). These supported bits indicate that the remote access client would like to use MS-PPC alone (in other words, without Microsoft Point-to-Point Encryption (MPPE), which can be configured in conjunction with MS-PPC).

As shown in Example 4-92, the LNS sends a Protocol-Reject (PROTREJ) to the remote access client to reject configuration of the CCP, including MS-PPC.

Example 4-92. LNS Responds with a PROTREJ

Feb  6 01:36:10.565 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol
  CCP (0x80FD0107000A120600000001)

The remote access client then sends an IPCP CONFREQ to the LNS, as demonstrated in Example 4-92. This CONFREQ contains a number of options. These options are CompressTypeVJ (0x02, IP Compression Protocol), address (0x03, IP Address), Primary DNS (0x81, Primary DNS Address), Primary WINS (0x82, Primary NBNS Address), Secondary DNS (0x83, Secondary DNS Address), and finally Secondary WINS (0x84, Secondary NBNS Address).

Example 4-93. Remote Access Client Sends a CONFREQ

Feb  6 01:36:10.581 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 8 len 40
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    CompressType VJ 15 slots CompressSlot
  ID (0x0206002D0F01)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

The CompressTypeVJ option in Example 4-93 indicates that the remote access client would like to use Van Jacobson (VJ) Compression on the PPP connection.

Note, however, that all of the options contained within the CONFREQ, with the exception of IP Compression Protocol, are specified as 0.0.0.0. Here, the remote access client is indicating to the LNS that it would like all of these addresses to be supplied.

As Example 4-94 shows, because the remote access client has requested an IP address, the LNS obtains one from an IP address pool. The address obtained from the pool is 10.1.1.1.

Example 4-94. LNS Obtains an IP Address from the IP Address Pool

Feb  6 01:36:10.581 UTC: Vi1 IPCP: Pool returned 10.1.1.1

As shown in Example 4-95, The LNS then sends a CONFREJ to the remote access client. This CONFREJ is used to reject the CompressTypeVJ, Secondary DNS, and Secondary WINS options. This means that the LNS will not support Van Jacobson Compression on the PPP connection and will not supply secondary DNS and WINS server addresses to the remote access client.

Example 4-95. LNS Sends a CONFREJ to the Remote Access Client

Feb  6 01:36:10.581 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 8 len 22
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    CompressType VJ 15 slots CompressSlot
  ID (0x0206002D0F01)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Feb  6 01:36:10.581 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

It is worth noting that if you configure the ip tcp header-compression command on the virtual template interface (it is not configured in this example), and TCP header compression is negotiated with a large number of remote access clients, this may cause high CPU overhead on the LNS.

In Example 4-96, the remote access client acknowledges the LNS's IP address (172.16.5.5) using a CONFACK message. This CONFACK is an acknowledgment of the LNS's first CONFREQ message sent to the remote access client in Example 4-90. Notice that the ID of CONFACK is the same as that for the original CONFREQ (1).

Example 4-96. Remote Access Client Sends a CONFACK to the LNS

Feb  6 01:36:10.589 UTC: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10
Feb  6 01:36:10.589 UTC: Vi1 IPCP:    Address 172.16.5.5 (0x0306AC100505)

As demonstrated in Example 4-97, the remote access client now sends a second IPCP CONFREQ message to the LNS. This CONFREQ message is similar to the first one that it sent in Example 4-93. However, this one contains only three IPCP options: address, Primary DNS, and Primary WINS. The other options were previously rejected by the LNS in Example 4-95.

Example 4-97. Remote Access Client Sends a CONFREQ

Feb  6 01:36:10.697 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 9 len 22
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)

The LNS now sends a Configure-Nak (CONFNAK) message to the remote access client, as shown in Example 4-98. This CONFNACK message is used to supply the addresses requested by the remote access client (using the CONFREQ message in Example 4-97).

Example 4-98. LNS Sends a CONFNACK

Feb  6 01:36:10.697 UTC: Vi1 IPCP: O CONFNAK [ACKrcvd] id 9 len 22
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb  6 01:36:10.697 UTC: Vi1 IPCP:    PrimaryWINS 10.2.2.100 (0x82060A010164)

In Example 4-98, the LNS supplies the address 10.1.1.1 to the remote access client, together with the addresses of the primary DNS and WINS servers (10.2.2.99 and 10.2.2.100).

As Example 4-99 shows, the remote access client then sends another CONFREQ message to the LNS. This CONFREQ message is used to confirm the addresses sent by the LNS in the CONFNAK message in Example 4-98.

Example 4-99. Remote Access Client Sends a CONFREQ

Feb  6 01:36:10.813 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 10 len 22
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    PrimaryWINS 10.2.2.100 (0x82060A010164)

Finally, in Example 4-100, the LNS acknowledges the CONFREQ (in Example 4-99) using a CONFACK.

Example 4-100. LNS Sends a CONFACK

Feb  6 01:36:10.813 UTC: Vi1 IPCP: O CONFACK [ACKrcvd] id 10 len 22
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb  6 01:36:10.813 UTC: Vi1 IPCP:    PrimaryWINS 10.2.2.100 (0x82060A010164)

Example 4-101 shows that the LNS and the remote access client have successfully negotiated IPCP.

Example 4-101. IPCP Is Successfully Negotiated

Feb  6 01:36:10.813 UTC: Vi1 IPCP: State is Open
Feb  6 01:36:10.813 UTC: Vi1 IPCP: Install route to 10.1.1.1
Feb  6 01:36:11.445 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to up
Feb  6 01:36:12.441 UTC: Vi1 LCP: TIMEout: State Open
Skydance_LNS#

The IPCP state is now Open (highlighted line 1, Example 4-101), and the LNS installs a route to the remote access client (highlighted line 2). The line protocol on interface virtual-access 1 now changes state to up (highlighted line 3). NCP (IPCP portion) negotiation has completed successfully.

Now that you have seen successful NCP negotiation, it is time to take a look at an example of unsuccessful NCP negotiation. Examples 4-102 to 4-107 show the output of the debug ppp negotiation command when NCP negotiation is not successful. Note that only the relevant portion of the output is shown.

Example 4-102. NCP Negotiation Fails

Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#

Feb  6 01:39:13.353 UTC: Vi1 PPP: Phase is UP

The PPP phase changes to UP, and NCP negotiation begins.

As Example 4-103 shows, the remote access client then sends a CCP CONFREQ to the LNS specifying MS-PPC.

Example 4-103. Remote Access Client Sends a CONFREQ

Feb  6 01:39:13.465 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 6 len 10
Feb  6 01:39:13.465 UTC: Vi1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)

In Example 4-104, the LNS rejects configuration of the CCP by sending a Protocol-Reject (PROTREJ) to the remote access client.

Example 4-104. LNS Sends a PROTREJ

Feb  6 01:39:13.465 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol
  CCP (0x80FD0106000A120600000001)

Now this is where things start to get interesting. Example 4-105 shows an incoming (I) IPCP CONFREQ from the remote access client. This CONFREQ includes six IPCP options: CompressTypeVJ, Address, Primary DNS, Primary WINS, Secondary DNS, and Secondary WINS.

Example 4-105. Remote Access Client Sends a CONFREQ

Feb  6 01:39:13.473 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 7 len 40
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    CompressType VJ 15 slots CompressSlot
  ID (0x0206002D0F01)
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    Address 0.0.0.0 (0x030600000000)
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Feb  6 01:39:13.473 UTC: Vi1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)

Then something strange happens, as Example 4-106 demonstrates. The LNS sends a PROTREJ message to the remote access client rejecting configuration of IPCP.

Example 4-106. LNS Rejects Configuration of IPCP

Feb  6 01:39:13.473 UTC: Vi1 LCP: O PROTREJ [Open] id 2 len 46 protocol IPCP
Feb  6 01:39:13.473 UTC: Vi1 LCP:  (0x8021010700280206002D0F0103060000)
Feb  6 01:39:13.473 UTC: Vi1 LCP:  (0x00008106000000008206000000008306)
Feb  6 01:39:13.473 UTC: Vi1 LCP:  (0x00000000840600000000)

PPP is finally terminated in Example 4-107.

Example 4-107. PPP Negotiation Is Terminated

Feb  6 01:39:14.353 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to up
Feb  6 01:39:15.349 UTC: Vi1 LCP: TIMEout: State Open
Skydance_LNS#
Feb  6 01:39:16.897 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
  to down
Feb  6 01:39:16.897 UTC: Vi1 PPP: Phase is TERMINATING
Feb  6 01:39:16.897 UTC: Vi1 LCP: State is Closed
Feb  6 01:39:16.897 UTC: Vi1 PPP: Phase is DOWN
Feb  6 01:39:17.897 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  Virtual-Access1, changed state to down
Skydance_LNS#

Following the rejection of IPCP by the LNS, virtual-access interface 1 changes state to down (highlighted line 1, Example 4-107). In highlighted line 2, the PPP phase changes to TERMINATING and then DOWN (highlighted line 3). Finally, in highlighted line 4, the line protocol on virtual-access interface 1 changes state to down. NCP negotiation has failed.

So what went wrong? Why did the LNS reject configuration of IPCP on virtual-access interface 1? The LNS will reject configuration of IPCP on the virtual-access interface if the virtual-access interface is not configured with an IP address. The virtual-access interface is dynamic in nature and takes its configuration from virtual template interface.

The next step is to examine the configuration of the virtual template interface associated with the VPDN group using the show running-config command.

Example 4-108 shows the output of the show running-config command. Only the relevant parts of the configuration are shown.

Example 4-108. Verifying Virtual Template Interface Configuration

Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname CalCity_LAC
 l2tp tunnel password 7 060506324F41
!
!
interface Virtual-Template1
 no ip address
 peer default ip address pool SKYDANCE_POOL
 ppp authentication chap
 ppp multilink
!

As you can see, no IP address has been configured on virtual template interface 1 (highlighted line 3). This is the configuration that is copied to the virtual-access interfaces as they are dynamically created when PPP connections from remote access clients are terminated on the LNS. To resolve this issue, an IP address is configured on the virtual template interface.

Example 4-109 shows the configuration of an IP address on the virtual template interface.

Example 4-109. Configuration of ip unnumbered on the Virtual Template Interface

Skydance_LNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Skydance_LNS(config)#interface virtual-template 1
Skydance_LNS(config-if)#ip unnumbered ethernet 1/0
Skydance_LNS(config-if)#exit
Skydance_LNS#

Once an IP address (ip unnumbered ethernet 1/0) is configured on the virtual template interface, the remote access client reconnects and NCP (IPCP portion) negotiation is successful.

Use the show caller user command to verify successful IPCP negotiation with the remote access client.

Example 4-110 shows the output of the show caller user command.

Example 4-110. Checking Successful IPCP Negotiation

Skydance_LNS#show caller user ltahoe@mjlnet.com
  User: ltahoe@mjlnet.com, line Vi1, service PPP L2TP
        Active time 00:00:25, Idle time 00:00:00
  Timeouts:            Absolute  Idle
      Limits:          -         -
      Disconnect in:   -         -
  PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
  IP: Local 172.16.5.5, remote 10.1.1.1
  VPDN: NAS CalCity_LAC, MID 37, MID Unknown
        HGW , NAS CLID 0, HGW CLID 0, tunnel open
  Counts: 47 packets input, 4448 bytes, 0 no buffer
          0 input errors, 0 CRC, 0 frame, 0 overrun
          26 packets output, 1119 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#

Highlighted line 1 shows that user ltahoe@mjlnet.com is connected to interface virtual-access 1 (vi1). In highlighted line 2, you can see that LCP is in an open state, PPP multilink was not negotiated and is in a closed state, the authentication protocol used is CHAP, and IPCP was negotiated. Highlighted line 3 shows the IP address configured on virtual-access interface 1 (172.16.5.5), together with the IP address configured on the remote access client (10.1.1.1). Finally, in highlighted line 4, the hostname of the LAC (CalCity_LAC) is shown. IPCP negotiation has been successful, and the issue is resolved.