|
|
Troubleshooting L2FFast and efficient troubleshooting of L2F is dependent upon a good understanding of L2F protocol operation, L2F configuration, and PPP. Additionally, if remote access clients dial into the NAS, a good knowledge of ISDN and asynchronous modems is also important. In this section, you will see how to apply the end-to-end troubleshooting methodology to L2F. The flowchart in Figure 2-26 describes the troubleshooting process used with L2F. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network. Figure 2-26. L2F Troubleshooting Flowchart Before beginning the troubleshooting process, it is worth briefly re-examining the tunnel establishment model for L2F and some of the possible issues that could be seen. Figure 2-27 illustrates tunnel establishment. Figure 2-27. L2F Tunnel and Session Establishment Figure 2-27 illustrates the following steps:
That's what should happen. As you have probably guessed, there are quite a number of things that can go wrong. Some of these things are shown in Figure 2-28. Note that not all potential problems are shown. Figure 2-28. Potential Problems with L2F Tunnel Setup Together, Figure 2-28 and Table 2-4 illustrate some potential problems.
The first part of the tunnel establishment model for L2F is, of course, the PPP connection initiated by the remote access client. Some of the issues that might occur are highlighted in Table 2-4. Assuming a Microsoft client, issues might include incorrect modem drivers, a cabling issue between the client and the modem, misconfiguration of Dial-up Networking (DUN), and so on. It is not the intention of this book, however, to detail how to troubleshoot client operating systems and hardware but, instead, to focus on troubleshooting issues that can occur on the NAS and the Home Gateway. The next section begins the L2F tunnel troubleshooting process, beginning with call reception on the NAS. Call Reception on the NASThe first thing that needs to be confirmed on the NAS is that calls are indeed being received as intended. This section assumes that the client is using an asynchronous modem and that these calls are being received by the NAS on its ISDN PRI. Figure 2-29 illustrates call reception on the NAS. Figure 2-29. Call Reception on the NAS
The first thing to do is to confirm that the ISDN interface is active and that calls are being received. The show isdn status command is a very good command to give you a quick snapshot of the state of the ISDN interface. Example 2-12 shows "good" output from this command. Example 2-12. "Good" Output from the show isdn status CommandLODI_NAS1#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: 1 Active Layer 3 Call(s) CCB:callid=5, sapi=0, ces=0, B-chan=1, calltype=VOICE CCB:callid=4, sapi=0, ces=0, B-chan=1, calltype=VOICE Active dsl 0 CCBs = 2 The Free Channel Mask: 0xFFFF7FFE Number of L2 Discards = 0, L2 Session ID = 2 Total Allocated ISDN CCBs = 2 LODI_NAS1# Highlighted line 1 shows the globally configured ISDN switch type (primary-net5). Highlighted line 2 shows the ISDN switch type applied to interface serial 0/0:15 (also primary-net5). The status of Layers 1, 2, and 3 are shown in next three highlighted lines. Layer 1 status is ACTIVE. This indicates that physical connectivity has been established. Moving on to Layer 2, you can see that the status is MULTIPLE_FRAME_ESTABLISHED. This shows that the PRI has established communications with the service provider's ISDN switch. Below that, the status of Layer 3 is shown. In this case, you can see that there is one active call on the interface. Now that you have seen an example of "good" output, Example 2-13 provides some output that is not so good. Example 2-13. "Not-So-Good" Output from the show isdn status CommandLODI_NAS1#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 = 0 Total Allocated ISDN CCBs = 0 LODI_NAS1# In this case, you can see that Layer 1 is in a DEACTIVATED state. This obviously indicates a problem. An examination of the E1 controller shows the results in Example 2-14. Example 2-14. E1 Controller Reports a Remote Alarm and Loss of SignalLODI_NAS1#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 (81 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 1 Slip Secs, 81 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 81 Unavail Secs LODI_NAS1# You can see in the first highlighted line of the output that E1 0/0 is down. In the second highlighted line, the transmitter is sending a remote alarm, and in the next line, the receiver is reporting a loss of signal. A loss of signal usually indicates a problem with the cable. It could be that the cable is not connected correctly or that there is a break in the cable. The cable is replaced in this case, and the controller is checked again in Example 2-15. Example 2-15. E1 Controller Now Reports No AlarmsLODI_NAS1#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 (290 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 1 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs LODI_NAS1# In the first highlighted line in Example 2-15, you can see that E1 0/0 is now up and, in the second highlighted line, that there are no alarms detected. Now check the ISDN status using the show isdn status command, as demonstrated in Example 2-16. Example 2-16. ISDN Layer 1 Status Is Now ActiveLODI_NAS1#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: 0x80007FFF Number of L2 Discards = 0, L2 Session ID = 0 Total Allocated ISDN CCBs = 0 LODI_NAS1# As you can see in the highlighted output, Layer 1 is now ACTIVE, and Layer 2 is MULTIPLE_FRAME_ESTABLISHED. The issue is resolved. Note that most problems with E1 or T1 controllers are caused by incorrectly configured framing, linecode, or clock source. Make sure that these are configured as per your service provider's recommendations. Also ensure that ISDN switch type and encapsulation type are correctly set. You now know that the router is communicating correctly with the ISDN switch. The next step is to check that call setup operates correctly. ISDN uses the Q.931 protocol to signal call setup, so use debug isdn q931 command to verify call setup, as shown in Example 2-17. In the first highlighted line of Example 2-17, a call setup message is received (RX) on the D channel (serial0/0:15). Example 2-17. Verifying Call Setup OperationLODI_NAS1#debug isdn q931 ISDN Q931 packets debugging is on LODI_NAS1# Jan 6 18:35:43.131 GMT:GMT: ISDN Se0/0:15: RX <- SETUP pd = 8 callref = 0x0006 Jan 6 18:35:43.131 GMT: Sending Complete Jan 6 18:35:43.131 GMT: Bearer Capability i = 0x8090A3 Jan 6 18:35:43.131 GMT: Channel ID i = 0xA98381 Jan 6 18:35:43.135 GMT: Calling Party Number i = 0xA1, '1111', Plan:ISDN, Type:National Jan 6 18:35:43.135 GMT: Called Party Number i = 0xA1, '7777', Plan:ISDN, Type:National Jan 6 18:35:43.135 GMT: Low Layer Compat i = 0x8090A3 Jan 6 18:35:43.143 GMT: ISDN Se0/0:15: llc valid, speed 64, call type is VOICE speed:0 async:N Jan 6 18:35:43.147 GMT: ISDN Se0/0:15: TX -> CALL_PROC pd = 8 callref = 0x8006 Jan 6 18:35:43.147 GMT: Channel ID i = 0xA98381 Jan 6 18:35:43.183 GMT: ISDN Se0/0:15: TX -> ALERTING pd = 8 callref = 0x8006 Jan 6 18:35:43.187 GMT: ISDN Se0/0:15: TX -> CONNECT pd = 8 callref = 0x8006 Jan 6 18:35:43.211 GMT: ISDN Se0/0:15: RX <- CONNECT_ACK pd = 8 callref = 0x0006 Jan 6 18:35:43.215 GMT: ISDN Se0/0:15: CALL_PROGRESS: CALL_CONNECTED call id 0xA, bchan 0, dsl 0 Jan 6 18:35:43.215 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 18:36:08.847 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to up LODI_NAS1# Jan 6 18:36:15.123 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async33, changed state to up LODI_NAS1# If you look further down the output, you can see the calling party number (the remote access client) 1111, and the called party number, 7777 (the NAS). In highlighted line 4, a CONNECT message is transmitted (TX) by the NAS. This indicates that the call has been accepted on the PRI. Toward the bottom of the output, you can see the message Interface Serial0/0:0 is now connected to 1111. Call setup has been successful. If call setup is not successful, check the ISDN switch-type and the number that the remote access client is calling to access the NAS. Once the call has been successfully received on interface serial 0/0:0 (one of the B channels), it is routed to the internal MICA modems. Success or failure of one of the modems to receive the call successfully can be examined using the debug modem command. This is demonstrated in Example 2-18. Example 2-18. Verifying Success/Failure of Call Receipt by the ModemLODI_NAS1#debug modem Modem control/process activation debugging is on LODI_NAS1# Jan 6 18:37:52.215 GMT: Modem 1/1 Mica: configured for Answer mode, with Null signaling, 0x0 tone detection. Jan 6 18:37:52.215 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 18:37:52.379 GMT: Modem 1/1 Mica: in modem state CALL_SETUP Jan 6 18:37:53.447 GMT: Modem 1/1 Mica: in modem state CONNECT Jan 6 18:37:57.939 GMT: Modem 1/1 Mica: in modem state LINK Jan 6 18:38:09.163 GMT: Modem 1/1 Mica: in modem state TRAINUP Jan 6 18:38:13.219 GMT: Modem 1/1 Mica: in modem state EC_NEGOTIATING Jan 6 18:38:13.755 GMT: Modem 1/1 Mica: in modem state STEADY Jan 6 18:38:13.767 GMT: Modem 1/1 Mica: CONNECT at 49333/28800 (Tx/Rx), V90, LAPM, V42bisJan 6 18:38:14.655 GMT: TTY34: DSR came up Jan 6 18:38:14.655 GMT: tty34: Modem: IDLE->(unknown) Jan 6 18:38:14.659 GMT: TTY34: Autoselect started Jan 6 18:38:14.659 GMT: TTY34: create timer type 0, 120 seconds Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7E Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF7D Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF7D23 Jan 6 18:38:15.831 GMT: TTY34 Autoselect cmd: ppp negotiate Jan 6 18:38:15.831 GMT: TTY34: destroy timer type 0 (OK) Jan 6 18:38:15.831 GMT: TTY34: EXEC creation Jan 6 18:38:15.835 GMT: TTY34: create timer type 1, 600 seconds Jan 6 18:38:15.839 GMT: TTY34: destroy timer type 1 (OK) Jan 6 18:38:15.839 GMT: TTY34: destroy timer type 0 Jan 6 18:38:17.839 GMT: %LINK-3-UPDOWN: Interface Async34, changed state to up Jan 6 18:38:22.923 GMT: Modem 1/1 Mica: PPP escape_map: Tx map = 0, Rx map = 0 Jan 6 18:38:24.111 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async34, changed state to up Jan 6 18:38:34.843 GMT: Modem 1/1 Mica: in modem state SS_SHIFTINGSPEED Jan 6 18:38:36.087 GMT: Modem 1/1 Mica: in modem state STEADY Jan 6 18:38:36.099 GMT: Modem 1/1 Mica: SpeedShifted to 49333/31200 (Tx/Rx) LODI_NAS1# In highlighted line 1, modem MICA 1/1 (slot 1, modem 1), goes off the hook (Modem 1/1 Mica: in modem state CALL_SETUP), and in highlighted line 2, the modem is connected at transmit and receive (Tx/Rx) speeds of 49333 and 28800 bps, respectively. Between highlighted lines 3 and 4, the autoselect process takes place, with several samples made of the data received on the line. Based on these samples, the NAS is able to detect that PPP is being used and autoconfigures the line for this encapsulation type. PPP negotiation is then triggered on the line. Finally, in highlighted line 5, interface async 34 changes state to up. If you do not see any output from the debug modem command, make sure that the isdn incoming voice-modem command is configured on the ISDN D channel. Also make sure that the modem InOut command is configured on the modem lines. Another useful command to use when debugging modems is debug modem csm. This command provides detailed debugging for the Call Switching Module (for internal digital modems). You have now confirmed that the call setup is completing successfully. Troubleshooting PPP on the NASIf you have confirmed that calls from the remote access client are being successfully received, it is now time to check PPP negotiation on the NAS. PPP negotiation is a two-stage process on the NAS, consisting of LCP negotiation and partial authentication. Remember that Network Control Protocols (NCPs) are not negotiated by the NAS, but instead between the client and the Home Gateway. LCP Negotiation Fails Between the Remote Client and the NASIf LCP negotiation is not successful between the NAS and the remote client, use the debug ppp negotiation command to see what went wrong. Figure 2-30 shows LCP negotiation between the NAS and the remote access client. Figure 2-30. LCP Negotiation Between the NAS and Client
The output in Examples 2-19 to 2-31 show successful LCP negotiation between the NAS and the remote client. Example 2-19. PPP Negotiation BeginsLODI_NAS1#debug ppp negotiation PPP protocol negotiation debugging is on LODI_NAS1# Jan 6 18:45:37.063 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 18:46:05.723 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to up Jan 6 18:46:05.723 GMT: As36 PPP: Treating connection as a dedicated line Jan 6 18:46:05.723 GMT: As36 PPP: Phase is ESTABLISHING, Active Open Highlighted line 1 shows that interface serial0/0:0 (one of the B channels) is connected. In highlighted line 2, interface async 36 changes state to up. PPP then moves to the ESTABLISHING phase (highlighted line 3). This means that PPP negotiation is about to begin. PPP negotiation begins when the NAS sends a Configure-Request (CONFREQ) to the remote access client, as shown in Example 2-20. Example 2-20. Outbound CONFREQ from the NAS
Jan 6 18:46:05.727 GMT: As36 LCP: O CONFREQ [Closed] id 6 len 25
Jan 6 18:46:05.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:05.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:05.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:05.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:05.727 GMT: As36 LCP: ACFC (0x0802)
The highlighted line in Example 2-20 shows the outbound (O) Configure-Request (CONFREQ) from the NAS. This is used to inform the remote access client of the LCP options that the NAS wants to use. The LCP options included in this CONFREQ are Asynchronous Control Character Map (ACCM), Authentication Protocol, Magic Number, Protocol Field Compression (PFC), and Address & Control Field Compression (ACFC). ACCM is used to control how data is escaped over the link. Escaping data ensures that data sent over the link is not misinterpreted by the modem as commands. Raw data is given in parentheses. In ACCM 0x000A0000 (0x0206000A0000), 0x02 is the LCP option number (ACCM itself), 0x06 is the option length, and 0x000A0000 is the four-octet map that defines how character escaping will be performed. It is worth noting that the elements option number, option length, and value comprise a common format with PPP options. The next LCP option is authentication protocol (0x03). In this case, the authentication protocol specified is standard MD5 CHAP (0xC22305). The third option is Magic Number (0x05). The Magic Number specified by the NAS is 0x115342A4. The Magic Number is used for loop detection. PFC (0x07) is the next option specified. The NAS uses this option to inform the client that it can receive PPP protocol fields that are compressed. The final option is ACFC (0x08). This option is used to indicate that the NAS can receive PPP frames without HDLC Address and Control fields. The client then acknowledges the NAS's CONFREQ with a Configure-Ack (CONFACK), as shown in Example 2-21. Notice that the CONFACK has the same ID (6) as the previous CONFREQ (see Example 2-20). Example 2-21. Inbound LCP CONFACK from the Remote Access Client
Jan 6 18:46:05.831 GMT: As36 LCP: I CONFACK [REQsent] id 6 len 25
Jan 6 18:46:05.831 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:05.835 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:05.835 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:05.835 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:05.835 GMT: As36 LCP: ACFC (0x0802)
All the options contained in the CONFACK are the same as those in the CONFREQ in Example 2-20. The first inbound (I) CONFREQ is now received from the client (see Example 2-22). Example 2-22. Inbound LCP CONFREQ from the Remote Access Client
Jan 6 18:46:06.711 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 0 len 23
Jan 6 18:46:06.711 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:06.711 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:06.711 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:06.711 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:06.711 GMT: As36 LCP: Callback 6 (0x0D0306)
Most of the options are the same as those specified in the NAS's CONFREQ, but there is one addition: The client has specified the Callback (0x0D) option. The client uses this option to request that the NAS drop the link after authentication and call it back. Note that this first CONFREQ from the client will later be forwarded to the Home Gateway during client (session) setup as L2F_OPEN suboption L2F_REQ_LCP0. The NAS then sends a Configure-Reject (CONFREJ) to the remote access client, as shown in Example 2-23. Example 2-23. Outbound CONFREJ from NAS
Jan 6 18:46:06.715 GMT: As36 LCP: O CONFREJ [ACKrcvd] id 0 len 7
Jan 6 18:46:06.715 GMT: As36 LCP: Callback 6 (0x0D0306)
Jan 6 18:46:07.727 GMT: As36 LCP: TIMEout: State ACKrcvd
The NAS uses the Configure-Reject (CONREJ) in Example 2-23 to reject configuration of Callback. Note that LCP times out here. The NAS now sends a second outbound CONFREQ to the client, shown in Example 2-24. The NAS specifies the same options as the first CONFREQ (see Example 2-20). Example 2-24. Second Outbound CONFREQ from the NAS
Jan 6 18:46:07.727 GMT: As36 LCP: O CONFREQ [ACKrcvd] id 7 len 25
Jan 6 18:46:07.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:07.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:07.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:07.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:07.727 GMT: As36 LCP: ACFC (0x0802)
A second CONFACK is received from the client in Example 2-25. Example 2-25. Second Inbound CONFREQ from Client
Jan 6 18:46:07.819 GMT: As36 LCP: I CONFACK [REQsent] id 7 len 25
Jan 6 18:46:07.819 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:07.819 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:07.819 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:07.819 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:07.819 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:09.727 GMT: As36 LCP: TIMEout: State ACKrcvd
The CONFACK in Example 2-25 is used to acknowledge the previous CONFREQ from the NAS. Note another LCP timeout here. A third CONFREQ is now sent to the client, as shown in Example 2-26. Example 2-26. Third LCP Outbound CONFREQ from the NAS
Jan 6 18:46:09.727 GMT: As36 LCP: O CONFREQ [ACKrcvd] id 8 len 25
Jan 6 18:46:09.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:09.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:09.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:09.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:09.727 GMT: As36 LCP: ACFC (0x0802)
The CONFREQ in Example 2-26 contains the same options as the two previous CONFREQs. The third CONFREQ is acknowledged by a final inbound CONFACK from the client in Example 2-27. Example 2-27. Final CONFACK Received from the Client
Jan 6 18:46:09.819 GMT: As36 LCP: I CONFACK [REQsent] id 8 len 25
Jan 6 18:46:09.819 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:09.819 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:09.819 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:09.819 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:09.823 GMT: As36 LCP: ACFC (0x0802)
The CONFACK in Example 2-27 will later be passed to the Home Gateway as L2F_OPEN suboption L2F_ACK_LCP1 during L2F session establishment. A second inbound CONFREQ is received from the client, as shown in Example 2-28. Example 2-28. Second CONFREQ Received from the Client
Jan 6 18:46:10.715 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 0 len 23
Jan 6 18:46:10.715 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:10.715 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:10.715 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:10.715 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:10.715 GMT: As36 LCP: Callback 6 (0x0D0306)
The options contained in the CONFREQ in Example 2-28 are the same as those specified in the client's first CONFREQ (see Example 2-22). Callback is then rejected by the NAS using a CONFREJ in Example 2-29. Example 2-29. Second CONFREJ Sent by NAS
Jan 6 18:46:10.715 GMT: As36 LCP: O CONFREJ [ACKrcvd] id 0 len 7
Jan 6 18:46:10.719 GMT: As36 LCP: Callback 6 (0x0D0306)
The client now sends its third CONFREQ (in Example 2-30), and this time you will notice there is no Callback option included. Example 2-30. Third CONFREQ from Client
Jan 6 18:46:10.803 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 1 len 20
Jan 6 18:46:10.803 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:10.803 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:10.803 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:10.803 GMT: As36 LCP: ACFC (0x0802)
Finally, in Example 2-31, the NAS sends a CONFACK to the client acknowledging its CONFREQ (highlighted line 1). This CONFACK is also later forwarded to the NAS as LCP_OPEN suboption L2F_ACK_LCP2 during L2F session establishment. In highlighted line 2, the LCP state changes to OPEN, indicating that LCP negotiation has completed successfully. Example 2-31. NAS Sends CONFACK to the ClientJan 6 18:46:10.807 GMT: As36 LCP: O CONFACK [ACKrcvd] id 1 len 20 Jan 6 18:46:10.807 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000) Jan 6 18:46:10.807 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB) Jan 6 18:46:10.807 GMT: As36 LCP: PFC (0x0702) Jan 6 18:46:10.807 GMT: As36 LCP: ACFC (0x0802) Jan 6 18:46:10.807 GMT: As36 LCP: State is Open Example 2-32 shows the output of the debug ppp negotiation command when LCP negotiation is unsuccessful. Note that only the relevant portion of the output is shown. Example 2-32. debug ppp negotiation Command Output (Continued)LODI_NAS1#debug ppp negotiation PPP protocol negotiation debugging is on LODI_NAS1# *Mar 1 01:26:21.131 GMT: As36 LCP: O CONFREQ [ACKsent] id 18 len 25 *Mar 1 01:26:21.131 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000) *Mar 1 01:26:21.131 GMT: As36 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 01:26:21.131 GMT: As36 LCP: MagicNumber 0x10CA833B (0x050610CA833B) *Mar 1 01:26:21.131 GMT: As36 LCP: PFC (0x0702) *Mar 1 01:26:21.131 GMT: As36 LCP: ACFC (0x0802) *Mar 1 01:26:21.239 GMT: As36 LCP: I CONFNAK [ACKsent] id 18 len 9 *Mar 1 01:26:21.243 GMT: As36 LCP: AuthProto MS-CHAP (0x0305C22380) *Mar 1 01:26:21.243 GMT: As36 LCP: Failed to negotiate with peer *Mar 1 01:26:21.243 GMT: As36 LCP: O TERMREQ [ACKsent] id 19 len 4 *Mar 1 01:26:21.403 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 32 seconds *Mar 1 01:26:23.243 GMT: As36 LCP: TIMEout: State TERMsent *Mar 1 01:26:23.243 GMT: As36 LCP: O TERMREQ [TERMsent] id 20 len 4 *Mar 1 01:26:25.023 GMT: %LINK-5-CHANGED: Interface Async36, changed state to reset *Mar 1 01:26:25.023 GMT: As36 LCP: State is Closed *Mar 1 01:26:25.027 GMT: As36 PPP: Phase is DOWN *Mar 1 01:26:30.023 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to down *Mar 1 01:26:30.023 GMT: As36 LCP: State is Closed LODI_NAS1# In highlighted line 1, the NAS sends an LCP CONFREQ to the client. Note that the authentication protocol (AuthProto) specified is CHAP (standard MD5 CHAP). In highlighted line 2, the client then responds with a CONFNACK specifying MS-CHAP (Microsoft CHAP). Highlighted line 3 shows that the NAS has failed to negotiate with the peer (the client), and in highlighted line 4, the NAS sends a TERMREQ to terminate the connection. Then in highlighted lines 5 and 6, interface serial 0/0:0 is disconnected from 1111, and interface async 36 changes state to down. The NAS and the client were unable to agree on an authentication protocol, and the client was disconnected. To resolve this issue, the NAS can be configured to accept MS-CHAP, or the client can be configured to accept standard MD5 CHAP. In this case, the client is reconfigured to accept standard MD5 CHAP. The client now reconnects, and LCP negotiates successfully. This is verified using the show user and show caller user commands. Example 2-33 shows the output of the show user command. Example 2-33. show user Command OutputLODI_NAS1#show user Line User Host(s) Idle Location * 0 con 0 idle 00:00:00 37 tty 37 joebloggs@ Async interface - Interface User Mode Idle Peer Address LODI_NAS1# As you can see, user joebloggs@(mjlnet.com) is connected on interface async 37. More information about the client connection can be found using the show caller user command. Example 2-34 shows the output of the show caller user command. Example 2-34. show caller user Command OutputLODI_NAS1#show caller user joebloggs@mjlnet.com User: joebloggs@mjlnet.com, line tty 37, service Async Active time 00:00:54, Idle time 00:00:07 Timeouts: Absolute Idle Idle Session Exec Limits: - - 00:10:00 Disconnect in: - - - TTY: Line 37, running PPP on As37 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 is permanent async interface, Modem Autoconfigure Integrated ModemLinenumber Not Suppressed Modem State: Ready, Modem Configured User: joebloggs@mjlnet.com, line As37, service PPP Active time 00:00:51, Idle time 00:00:00 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, CHAP (<- none) IP: Local 172.16.1.1 VPDN: NAS LODI_NAS1, MID 19, MID open HGW PERRIS_HGW1, NAS CLID 4, HGW CLID 18, tunnel open Counts: 206 packets input, 11542 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 318 packets output, 14026 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets LODI_NAS1# In highlighted line 1, you can see that user joebloggs@mjlnet.com is connected on line 37. Highlighted line 2 shows that PPP is running on the line. Then highlighted line 3 shows that LCP has been successfully negotiated (state is OPEN), and that the authentication protocol is standard MD5 CHAP. Partial PPP Authentication Fails on the NASLCP has now been successfully negotiated and is in the OPEN state. At this point, PPP authentication begins. Figure 2-31 shows partial authentication between the NAS and remote access client. Figure 2-31. Partial Authentication Between the NAS and the Client
Example 2-35 shows the output of the debug ppp negotiation command when authentication is successful. Note that only the relevant portion of the output is shown. Note that the debug ppp authentication command can also be used to troubleshoot PPP authentication. Example 2-35. Successful PPP Authentication on the NASLODI_NAS1#debug ppp negotiation PPP protocol negotiation debugging is on LODI_NAS1# Jan 6 18:46:10.807 GMT: As36 LCP: State is Open Jan 6 18:46:10.811 GMT: As36 PPP: Phase is AUTHENTICATING, by this end Jan 6 18:46:10.811 GMT: As36 CHAP: O CHALLENGE id 3 len 30 from "LODI_NAS1" Jan 6 18:46:10.895 GMT: As36 LCP: I IDENTIFY [Open] id 2 len 18 magic 0x000064CB MSRASV4.00 Jan 6 18:46:10.903 GMT: As36 LCP: I IDENTIFY [Open] id 3 len 21 magic 0x000064CB MSRAS-1-ORCH1 Jan 6 18:46:10.927 GMT: As36 CHAP: I RESPONSE id 3 len 40 from "joebloggs@mjlnet.com" Jan 6 18:46:10.927 GMT: As36 PPP: Phase is FORWARDING Jan 6 18:46:11.471 GMT: As36 PPP: Phase is FORWARDED Jan 6 18:46:11.995 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async36, changed state to up In highlighted line 1, the LCP state changes to OPEN. LCP negotiation has completed successfully. The PPP phase now changes to AUTHENTICATING (highlighted line 2). Authentication is about to begin. First the NAS sends an outbound (O) CHAP Challenge to the remote access client (highlighted line 3). Note that you should not see inbound (I) CHAP challenges from the remote access client. In highlighted line 4, the client replies with a Response message. The NAS does not now send a CHAP Success or Failure message to the client. At first, this may seem a little strange, because this is what would be expected in a "normal" PPP negotiation sequence. In this case, the negotiation sequence is different. The NAS does not examine the Value field (which contains the response data) in the CHAP Response message at all. Instead, it parses the username or DNIS and looks for an L2F tunnel corresponding to the domain name or DNIS. Having found a corresponding L2F tunnel and establishing an L2F tunnel to the Home Gateway if necessary, it sends the client's CHAP Response, together with other information, to the Home Gateway. In this case, the username supplied in the client's Response is joebloggs@mjlnet.com. The domain name mjlnet.com is matched by the NAS to an L2F tunnel. Also note in Example 2-35 the two LCP Identify options received from the client between highlighted lines 3 and 4. These are both vendor specific options (0x00), and they serve to inform the NAS that the client is using Microsoft RAS version 4 and that the computer name is ORCH1. Note that this is not the client username. You have seen debug output where the authentication on the NAS is successful. Example 2-36 shows the output of debug ppp negotiation when the authentication is not successful. Example 2-36. Unsuccessful Partial PPP Authentication on the NASLODI_NAS1#debug ppp negotiation PPP protocol negotiation debugging is on LODI_NAS1# Jan 6 19:03:27.562 GMT: As38 LCP: State is Open Jan 6 19:03:27.566 GMT: As38 PPP: Phase is AUTHENTICATING, by this end Jan 6 19:03:27.566 GMT: As38 CHAP: O CHALLENGE id 4 len 30 from "LODI_NAS1" Jan 6 19:03:27.650 GMT: As38 LCP: I IDENTIFY [Open] id 2 len 18 magic 0x00000DF5 MSRASV4.00 Jan 6 19:03:27.662 GMT: As38 LCP: I IDENTIFY [Open] id 3 len 21 magic 0x00000DF5 MSRAS-1-ORCH1 Jan 6 19:03:27.682 GMT: As38 CHAP: I RESPONSE id 4 len 40 from "joebloggs@mjlnet.com" Jan 6 19:03:27.682 GMT: As38 PPP: Phase is FORWARDING Jan 6 19:03:27.686 GMT: As38 PPP: Phase is AUTHENTICATING Jan 6 19:03:27.686 GMT: As38 CHAP: Unable to validate Response. Username joebloggs@mjlnet.com not found Jan 6 19:03:27.690 GMT: As38 CHAP: O FAILURE id 4 len 26 msg is "Authentication failure" Jan 6 19:03:27.690 GMT: As38 PPP: Phase is TERMINATING Jan 6 19:03:27.690 GMT: As38 LCP: O TERMREQ [Open] id 13 len 4 Jan 6 19:03:27.778 GMT: As38 LCP: I TERMREQ [TERMsent] id 4 len 8 (0x00000005) Jan 6 19:03:27.778 GMT: As38 LCP: O TERMACK [TERMsent] id 4 len 4 Jan 6 19:03:27.782 GMT: As38 LCP: I TERMACK [TERMsent] id 13 len 4 Jan 6 19:03:27.782 GMT: As38 LCP: State is Closed Jan 6 19:03:27.782 GMT: As38 PPP: Phase is DOWN Jan 6 19:03:27.782 GMT: As38 PPP: Phase is ESTABLISHING, Passive Open Jan 6 19:03:27.786 GMT: As38 LCP: State is Listen Jan 6 19:03:27.866 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 30 seconds Jan 6 19:03:29.782 GMT: %LINK-5-CHANGED: Interface Async38, changed state to reset Jan 6 19:03:29.782 GMT: As38 LCP: State is Closed Jan 6 19:03:29.786 GMT: As38 PPP: Phase is DOWN Jan 6 19:03:34.782 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down Jan 6 19:03:34.782 GMT: As38 LCP: State is Closed In highlighted line 1, the LCP state changes to OPEN, indicating that LCP negotiation has been successful. The PPP phase then changes to AUTHENTICATING (highlighted line 2), and authentication begins. In highlighted line 3, the NAS sends an outbound (O) Challenge to the client. In highlighted line 4 of the output, the client replies to the Challenge from the NAS with a Response message. Again, the NAS parses the username (joebloggs@mjlnet.com) and searches for a L2F tunnel corresponding to the domain name mjlnet.com. Having failed to find a corresponding tunnel, the NAS tries to authenticate the client itself, but when this does not succeed (highlighted line 5), it sends a CHAP Failure message to the client (highlighted line 6). The PPP phase then changes to TERMINATING (highlighted line 7). Terminate-Requests (TERMREQs) and Terminate-Acks (TERMACKs) are then exchanged between the client and the NAS (highlighted lines 8 to 11). The TERMREQ message is, as its name suggests, used to request teardown of the connection. The TERMACK is an acknowledgement of the request. In highlighted line 12, interface serial0/0:0 disconnects, and then in highlighted line 13, interface async 38 changes state to down. PPP authentication has failed and the client connection has been torn down. The NAS was unable to find a L2F tunnel corresponding to domain name mjlnet.com. The VPDN configuration is then examined and the problem is revealed. Example 2-37 shows the output of the show running-config command on the NAS. Note that only the relevant portion of the output is shown. Example 2-37. VPDN Group Domain Name Is MisconfiguredLODI_NAS1#show running-config Building configuration... Current configuration : 1755 bytes ! vpdn-group 1 request-dialin protocol l2f domain disco.com initiate-to ip 172.16.2.2 ! As you can see, the domain for the VPDN group has been incorrectly configured as disco.com. To correct this, use the configuration in Example 2-38. Example 2-38. Reconfiguration of the VPDN Domain NameLODI_NAS1#conf t Enter configuration commands, one per line. End with CNTL/Z. LODI_NAS1(config)#vpdn-group 1 LODI_NAS1(config-vpdn)#request-dialin LODI_NAS1(config-vpdn-req-in)#no domain disco.com LODI_NAS1(config-vpdn-req-in)#domain mjlnet.com LODI_NAS1(config-vpdn-req-in)#exit LODI_NAS1# Having corrected the domain name, the client reconnects. When the client reconnects, partial PPP authentication succeeds, and the L2F tunnel is established to the Home Gateway. Successful L2F tunnel establishment is verified using the show vpdn tunnel all command. Example 2-39 shows the output of the show vpdn tunnel all command. Example 2-39. L2F Tunnel Establishment Is SuccessfulLODI_NAS1#show vpdn tunnel all % No active L2TP tunnels L2F Tunnel Information Total tunnels 1 sessions 1 NAS name: LODI_NAS1 NAS CLID: 1 NAS IP address 172.16.1.1 Gateway name: PERRIS_HGW1 Gateway CLID: 15 Gateway IP address 172.16.2.2 State: open Packets out: 280 Bytes out: 11899 Packets in: 390 Bytes in: 18182 LODI_NAS1# Highlighted line 1 shows that one tunnel and one session have been established. In highlighted lines 2 to 4, the name (PERRIS_HGW), CLID (15), and IP address (172.16.2.2) of the Home Gateway are shown. Troubleshooting L2F Tunnel EstablishmentOnce LCP negotiation and partial authentication have been completed and the domain name or DNIS has been matched to a VPDN group, the NAS begins tunnel establishment to the Home Gateway. Figure 2-32 shows tunnel initialization and establishment between the NAS and the Home Gateway. Figure 2-32. L2F Tunnel Initialization Between the NAS and Home Gateway Before examining what happens when L2F tunnel establishment fails, it is worth having a look at successful tunnel establishment using the debug vpdn l2x-events command. Examples 2-40 to 2-42 show the output of the debug vpdn l2x-events command. In highlighted line 1 (Example 2-40), interface serial 0/0:0 (one of the B channels) is connected to the remote access client (1111). Example 2-40. Successful L2F Tunnel EstablishmentLODI_NAS1#debug vpdn l2x-events L2X protocol events debugging is on LODI_NAS1# Jan 6 19:28:44.006 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 19:29:09.842 GMT: %LINK-3-UPDOWN: Interface Async34, changed state to up Jan 6 19:29:15.046 GMT: Tnl 24 L2F: UDP socket opened to 172.16.2.2 using source 172.16.1.1 Jan 6 19:29:15.046 GMT: Tnl 24 L2F: Tunnel state change from closed state opening Then in highlighted line 2, interface async 34 changes state to up. The remote access client is now connected to the NAS. In highlighted line 3, the NAS opens a UDP port and sends an L2F_CONF to the Home Gateway. Note that the L2F_CONF is not explicitly shown in the debug output. The Home Gateway responds with an L2F_CONF, shown in Example 2-41. Example 2-41. L2F Tunnel Initialization
Jan 6 19:29:15.074 GMT: Tnl 24 L2F: L2F_CONF received
Jan 6 19:29:15.078 GMT: Tnl 24 L2F: Received L2F-CONF from PERRIS_HGW1
Jan 6 19:29:15.078 GMT: Tnl 24 L2F: Tunnel PERRIS_HGW1 state change from
opening state open
The NAS now replies to the Home Gateway with an L2F_OPEN, as shown in Example 2-42, highlighted line 1. The Home Gateway authenticates the NAS, and because this is successful, responds with its own L2F_OPEN. This is seen in highlighted line 2. Example 2-42. L2F Tunnel Establishment and AuthenticationJan 6 19:29:15.078 GMT: Tnl 24 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait Jan 6 19:29:15.102 GMT: Tnl 24 L2F: L2F_OPEN received Jan 6 19:29:15.106 GMT: Tnl 24 L2F: OPEN from PERRIS_HGW1 received for tunnel in state open Jan 6 19:29:15.106 GMT: Tnl 24 L2F: Tunnel PERRIS_HGW1 state change from open state open Jan 6 19:29:15.110 GMT: As34 Tnl/Cl 24/23 L2F: Session state change from closed to opening The NAS successfully authenticates the Home Gateway, and the L2F tunnel is now established. The show vpdn tunnel all command can be used to confirm L2F tunnel establishment, as shown in Example 2-43. Example 2-43. Output of the show vpdn tunnel all CommandLODI_NAS1#show vpdn tunnel all % No active L2TP tunnels L2F Tunnel Information Total tunnels 1 sessions 1 NAS name: LODI_NAS1 NAS CLID: 32 NAS IP address 172.16.1.1 Gateway name: PERRIS_HGW1 Gateway CLID: 21 Gateway IP address 172.16.2.2 State: open Packets out: 17 Bytes out: 1400 Packets in: 12 Bytes in: 501 LODI_NAS1# Highlighted line 1 shows that there is one L2F tunnel and one L2F session established. Highlighted lines 2 to 4 show the NAS's name (LODI_NAS1), CLID (32), and IP address (172.16.1.1). The Home Gateway's name (PERRIS_HGW1), CLID (21), and IP address (172.16.2.2) are shown in highlighted lines 5 to 7. Highlighted line 8 shows the tunnel state (OPEN). Finally, highlighted lines 9 to 12 show the number of packets and bytes input and output for the tunnel. Tunnel establishment can fail for a number of reasons, including:
Troubleshooting a VPDN protocol mismatch and tunnel authentication failure are examined in depth in this section. If your tunnel definition is stored on a AAA server, be sure to see the case study entitled "Misconfigured L2F Tunnel Definition on the AAA Server" toward the end of this chapter. VPDN Protocol MismatchIf there is a VPDN protocol mismatch between the NAS and the Home Gateway, tunnel setup will fail. Use the debug vpdn l2x-events command to troubleshoot a VPDN protocol mismatch, as shown in Examples 2-44 to 2-46. Example 2-44. Output of the debug vpdn events Command When L2F Initialization Is UnsuccessfulLODI_NAS1#debug vpdn l2x-events L2X protocol events debugging is on LODI_NAS1# Jan 6 19:39:26.878 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 19:39:52.462 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up Jan 6 19:39:57.666 GMT: Tnl 28 L2F: UDP socket opened to 172.16.2.2 using source 172.16.1.1 Jan 6 19:39:57.666 GMT: Tnl 28 L2F: Tunnel state change from closed state opening Highlighted lines 1 and 2 in Example 2-44 show that interface serial 0/0:0 is connected to 1111 and that interface async 34 has changed state to up. The remote access client is now connected to the NAS. In highlighted line 3, the NAS opens a UDP (L2F) connection to the Home Gateway. The NAS sends an L2F_CONF here, although it is not explicitly shown in Example 2-44. There is no response to the NAS's L2F_CONF, and in Example 2-45 (highlighted line 1), the NAS resends it. Example 2-45. The NAS Resends the L2F_CONF
Jan 6 19:40:02.898 GMT: Tnl 28 L2F: Resending L2F_CONF, time #1 max 6
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel in state opening with Sessions being
aborted
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from opening state
closing
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from closing state
closed
Jan 6 19:40:07.898 GMT: L2F: Closed tunnel structure
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from closed state
opening
Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel in state opening with Sessions being
aborted with remote close requested
The NAS now sends an L2F_CLOSE to request tunnel shutdown as shown in Example 2-46. Example 2-46. NAS Sends an L2F_CLOSEJan 6 19:40:07.902 GMT: Tnl 28 L2F: Requesting Tunnel shutdown via L2F-Close Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel state change from opening state close-wait Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel state change from close-wait state closed Jan 6 19:40:07.902 GMT: L2F: Closed tunnel structure Jan 6 19:40:09.902 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down Jan 6 19:40:10.554 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 43 seconds Jan 6 19:40:11.906 GMT: %LINK-5-CHANGED: Interface Async38, changed state to reset Jan 6 19:40:16.906 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down LODI_NAS1# In highlighted line 1 in Example 2-46, the NAS sends the L2F_CLOSE to notify the Home Gateway of its intention to terminate tunnel establishment. Then in highlighted lines 2 and 3, interface async 38 changes the state to down, and the interface serial 0/0:0 is disconnected from 1111 (the remote access client). Tunnel intialization has failed. Note that the debug vpdn l2x-errors command also shows this failure. An examination of the VPDN group configuration on the Home Gateway shows the results in Example 2-47. Note that only the relevant portion of the output is shown. Example 2-47. VPDN Group Configuration on the Home GatewayPERRIS_HGW1#show running-config Building configuration... ! vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname LODI_NAS1 ! As you can see, the Home Gateway is correctly configured to terminate a tunnel from the NAS but, unfortunately, is configured to terminate L2TP tunnels and not L2F tunnels. The configuration is modified as in Example 2-48. Example 2-48. Reconfiguration of Home Gateway to Terminate L2F TunnelsPERRIS_HGW1#conf t Enter configuration commands, one per line. End with CNTL/Z. PERRIS_HGW1(config)#vpdn-group 1 PERRIS_HGW1(config-vpdn)#accept-dialin PERRIS_HG(config-vpdn-acc-in)#protocol l2f PERRIS_HG(config-vpdn-acc-in)#exit PERRIS_HGW1(config-vpdn)#terminate-from hostname LODI_NAS1 PERRIS_HGW1(config-vpdn)#end PERRIS_HGW1# When the client reconnects, tunnel establishment is successful. The output of the show vpdn tunnel command confirms this, as demonstrated in Example 2-49. Example 2-49. Successful L2F Tunnel EstablishmentLODI_NAS1#show vpdn tunnel all % No active L2TP tunnels L2F Tunnel Information Total tunnels 1 sessions 1 NAS name: LODI_NAS1 NAS CLID: 36 NAS IP address 172.16.1.1 Gateway name: PERRIS_HGW1 Gateway CLID: 30 Gateway IP address 172.16.2.2 State: open Packets out: 25 Bytes out: 2173 Packets in: 15 Bytes in: 685 Highlighted line 1 shows that one tunnel and one session have been established. In highlighted lines 2 to 5, the Home Gateway's name (PERRIS_HGW1), CLID (30), and IP address (172.16.2.2) are shown. Tunnel Authentication FailureIn the section entitled "Technical Overview of L2F" earlier in this chapter, you saw that the NAS and the Home Gateway must authenticate each other before the L2F tunnel can be established. If tunnel authentication fails, tunnel establishment will not succeed. Figure 2-33 illustrates tunnel authentication between the NAS and the Home Gateway. Figure 2-33. L2F Tunnel Establishment Before examining what happens when tunnel authentication fails, it is worthwhile to have another look at the tunnel establishment sequence when tunnel authentication succeeds. Use the debug vpdn l2x-events command to examine the L2F tunnel establishment sequence. Examples 2-50 and 2-51 show the L2F tunnel establishment process. Example 2-50. L2F Tunnel Authentication SucceedsLODI_NAS1#debug vpdn l2x-events L2X protocol events debugging is on LODI_NAS1# Jan 6 19:58:58.982 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 19:59:24.730 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up Jan 6 19:59:29.942 GMT: Tnl 34 L2F: UDP socket opened to 172.16.2.2 using source 172.16.1.1 Jan 6 19:59:29.942 GMT: Tnl 34 L2F: Tunnel state change from closed state opening Jan 6 19:59:29.974 GMT: Tnl 34 L2F: L2F_CONF received Jan 6 19:59:29.974 GMT: Tnl 34 L2F: Received L2F-CONF from PERRIS_HGW1 Jan 6 19:59:29.978 GMT: Tnl 34 L2F: Tunnel PERRIS_HGW1 state change from opening state open In highlighted line 1 in Example 2-50, you can see that the NAS has opened a UDP port (1701) to 172.16.2.2 (the Home Gateway). Although it does not explicitly say so, a L2F_CONF message is sent to the Home Gateway at this point. It is worth reiterating once again that this L2F_CONF message contains, among other things, a 32-bit random number challenge. In highlighted line 2 of the output, you can see that the NAS receives a L2F_CONF message. This also contains a 32-bit random number challenge. Both the NAS and the Home Gateway at this point take the different random numbers that they have received and, together with the configured tunnel password, calculate a MD5 hash value. The NAS and the Home Gateway now begin tunnel establishment (Example 2-51). Example 2-51. L2F Tunnel AuthenticationJan 6 19:59:29.978 GMT: Tnl 34 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait Jan 6 19:59:30.002 GMT: Tnl 34 L2F: L2F_OPEN received Jan 6 19:59:30.002 GMT: Tnl 34 L2F: OPEN from PERRIS_HGW1 received for tunnel in state open Jan 6 19:59:30.002 GMT: Tnl 34 L2F: Tunnel PERRIS_HGW1 state change from open state open Jan 6 19:59:30.006 GMT: As38 Tnl/Cl 34/28 L2F: Session state change from closed to opening In highlighted line 1 in Example 2-51, the NAS sends an L2F_OPEN message to the Home Gateway. This message contains a hash value calculated on the random number received from the Home Gateway in the L2F_CONF in highlighted line 2 of Example 2-50 and the tunnel password configured on the NAS. In highlighted line 2, a L2F_OPEN message is received from the Home Gateway. This message is crucial, and it has two functions. First, it shows that the Home Gateway has successfully authenticated the NAS based on the hash value sent. Second, it contains in turn the hash value that the Home Gateway has calculated based on the random number sent by the NAS (in the L2F_CONF in highlighted line 1 of Example 2-50), together with the tunnel password configured on the Home Gateway. At this stage, the Home Gateway has successfully authenticated the NAS, but the NAS has not yet authenticated the Home Gateway. In highlighted line 3, the NAS reports that the session state has moved from closed to opening. This means that the NAS has now successfully authenticated the Home Gateway, and the tunnel has been established. If you are a little lost, it is probably a good idea to reread the section entitled "L2F Tunnel Establishment" at the beginning of the chapter. You have now seen what happens when L2F tunnel authentication succeeds, but what happens if the authentication fails? Once again, use the debug vpdn l2x-events command to examine the tunnel establishment sequence. Examples 2-52 to 2-54 show the output from the debug vpdn l2x-events command when tunnel authentication fails. Example 2-52. L2F Tunnel Authentication FailsLODI_NAS1#debug vpdn l2x-events L2X protocol events debugging is on LODI_NAS1# Jan 6 20:10:37.246 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Jan 6 20:11:02.990 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to up Jan 6 20:11:08.190 GMT: Tnl 38 L2F: UDP socket opened to 172.16.2.2 using source 172.16.1.1 Jan 6 20:11:08.190 GMT: Tnl 38 L2F: Tunnel state change from closed state opening Jan 6 20:11:08.222 GMT: Tnl 38 L2F: L2F_CONF received Jan 6 20:11:08.222 GMT: Tnl 38 L2F: Received L2F-CONF from PERRIS_HGW1 Jan 6 20:11:08.226 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from opening state open In highlighted lines 1 and 2 in Example 2-52, interface serial 0/0:0 is connected to 1111, and interface async 36 changes state to up. The remote access client is connected to the NAS. Highlighted line 3 again shows that a UDP socket has been opened, and L2F_CONF sent, to the Home Gateway. The Home Gateway (Perris_HGW1) then responds with a L2F_CONF (highlighted lines 4 and 5). Remember that these two L2F_CONF packets contain the random number authentication challenges. L2F tunnel establishment then proceeds, as shown in Example 2-53. Example 2-53. L2F Tunnel Establishment ProceedsJan 6 20:11:08.226 GMT: Tnl 38 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait Jan 6 20:11:13.610 GMT: Tnl 38 L2F: Resending L2F_OPEN, time #1 max 6 Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel in state open with Sessions being aborted Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from open state closing Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from closing state closed Jan 6 20:11:18.610 GMT: L2F: Closed tunnel structure Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from closed state opening Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel in state opening with Sessions being aborted with remote close requested The NAS then sends an L2F_OPEN to the Home Gateway (Example 2-53, highlighted line 1). This contains the response (MD5 hash) to the Home Gateway's challenge that it sent in its L2F_CONF (Example 2-52, highlighted line 4). In highlighted line 2, you can see that the NAS has re-sent the L2F_OPEN to the Home Gateway. The Home Gateway should respond with an L2F_OPEN, but nothing is received. The NAS now aborts tunnel establishment (Example 2-54). Example 2-54. NAS Aborts Tunnel EstablishmentJan 6 20:11:18.614 GMT: Tnl 38 L2F: Requesting Tunnel shutdown via L2F-Close Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from opening state close-wait Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from close-wait state closed Jan 6 20:11:18.614 GMT: L2F: Closed tunnel structure Jan 6 20:11:20.090 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 42 seconds Jan 6 20:11:20.614 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to down Jan 6 20:11:22.618 GMT: %LINK-5-CHANGED: Interface Async36, changed state to reset Jan 6 20:11:27.618 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to down LODI_NAS1# The NAS sends a L2F_CLOSE message to the Home Gateway (Example 2-54, highlighted line 1). This serves as notification that tunnel establishment is being aborted. Finally, in highlighted lines 2 and 3, interface serial 0/0:0 disconnects from 1111, and interface async 36 changes state to down. Tunnel establishment has failed. The next step is to have a look at what happens on the Home Gateway when the NAS reattempts tunnel establishment. Use the debug vpdn l2x-errors command to examine tunnel establishment errors. Example 2-55 shows the output of the debug vpdn l2x-errors command when the NAS reattempts tunnel establishment. Example 2-55. L2F Tunnel Authentication FailurePERRIS_HGW1#debug vpdn l2x-errors L2X protocol errors debugging is on PERRIS_HGW1# .Jan 6 20:17:18.876 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082 .Jan 6 20:17:21.408 GMT: Tnl 16 L2F: Resending L2F_CONF, time #1 max 6 .Jan 6 20:17:22.068 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082 .Jan 6 20:17:26.412 GMT: Tnl 16 L2F: Resending L2F_CONF, time #2 max 6 .Jan 6 20:17:27.068 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082 PERRIS_HGW1# In highlighted line 1, the Home Gateway reports that it has received an L2F packet with a bogus authentication key. The packet in question is the L2F_OPEN from the NAS. In highlighted line 2, the Home Gateway resends its L2F_CONF message to the NAS. Therefore, the authentication response from the NAS to the Home Gateway's challenge is incorrect. This can mean only one thing. Tunnel passwords must be configured inconsistently on the NAS and the Home Gateway. The service password-encryption command is configured on both the NAS and the Home Gateway, so it is impossible to be sure where the tunnel password is misconfigured. The passwords are, therefore, reconfigured on both the NAS and the Home Gateway using the configuration in Example 2-56. Example 2-56. Reconfiguration of the Tunnel PasswordsLODI_NAS1#conf t Enter configuration commands, one per line. End with CNTL/Z. LODI_NAS1(config)#username LODI_NAS1 password cisco LODI_NAS1(config)#username PERRIS_HGW1 password cisco LODI_NAS1(config)#exit LODI_NAS1# ________________________________________________________________ PERRIS_HGW1#conf t Enter configuration commands, one per line. End with CNTL/Z. PERRIS_HGW1(config)#username PERRIS_HGW1 password cisco PERRIS_HGW1(config)#username LODI_NAS1 password cisco PERRIS_HGW1(config)#exit PERRIS_HGW1# When the client reconnects, L2F tunnel establishment succeeds. This is configured using the show vpdn tunnel all command. Example 2-57 shows the output of the show vpdn tunnel all command. Example 2-57. show vpdn tunnel all Confirms Successful Tunnel EstablishmentLODI_NAS1#show vpdn tunnel all % No active L2TP tunnels L2F Tunnel Information Total tunnels 1 sessions 1 NAS name: LODI_NAS1 NAS CLID: 37 NAS IP address 172.16.1.1 Gateway name: PERRIS_HGW1 Gateway CLID: 31 Gateway IP address 172.16.2.2 State: open Packets out: 13 Bytes out: 959 Packets in: 11 Bytes in: 410 LODI_NAS1# Highlighted line 1 reveals that one tunnel and one session have been established. Highlighted lines 2 to 4 show the Home Gateway's name (PERRIS_HGW1), CLID (31), and IP address (172.16.2.2). Troubleshooting L2F Session EstablishmentOnce tunnel setup has completed, session setup begins. Figure 2-34 shows L2F session setup. Figure 2-34. L2F Session Setup Before examining what happens when there is an L2F session setup failure, it is a good idea to first have a look at a successful session establishment using the debug vpdn l2x-events command. Example 2-58 shows the output of the debug vpdn l2x-events command when L2F session establishment is successful. Note that only the relevant portion of the output is shown. Example 2-58. Successful L2F Session EstablishmentLODI_NAS1#debug vpdn l2x-events L2X protocol events debugging is on LODI_NAS1# Jan 6 19:29:15.110 GMT: As34 Tnl/Cl 24/23 L2F: Sending L2F-OPEN for New Session Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: L2F_OPEN received Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: OPEN received for existing session in state opening Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: Session state change from opening to open Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: MID synced NAS/HG Clid=35/24 Mid=23 Jan 6 19:29:16.110 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async34, changed state to up LODI_NAS1# The NAS begins session establishment in highlighted line 1 in Example 2-58 by sending an L2F_OPEN message. The Home Gateway responds with an L2F_OPEN (highlighted line 2), and the session state changes from opening to open (highlighted line 3). The client session is now established. The message L2F: MID synced NAS/HG Clid=35/24 Mid=23 (highlighted line 4) confirms that the CLIDs 35 and 24 are assigned to the tunnel by the NAS and the Home Gateway, respectively, and that the MID to be used for this session is 23. The NAS is now free to forward PPP frames between the Home Gateway and the client over the tunnel. The show vpdn session command can also be used to confirm successful L2F session setup, as shown in Example 2-59. Example 2-59. Output of the show vpdn session CommandLODI_NAS1#show vpdn session % No active L2TP tunnels L2F Session Information Total tunnels 1 sessions 1 CLID MID Username Intf State 21 20 joebloggs@mjlnet.com As37 open LODI_NAS1# Highlighted line 1 shows the CLID, the MID, the username associated with the session, the interface on which the client is connected, and the session state. The most common cause of a session setup failure is the configuration of a session limit or the VPDN softshut feature. This issue is examined in this section. The starting point for troubleshooting this issue is the debug vpdn l2x-errors command. Examples 2-60 to 2-62 show the output from the debug vpdn l2x-errors command. Example 2-60. L2F Session Setup FailsLODI_NAS1#debug vpdn l2x-errors L2X protocol errors debugging is on LODI_NAS1# Jan 8 21:29:15.339 GMT: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected to 1111 Jan 8 21:29:21.339 GMT: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected to 1111 Jan 8 21:29:40.955 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up Jan 8 21:29:46.215 GMT: As38 Tnl/Cl 2/8 L2F: Session_create: Tunnel in open state In highlighted line 1 in Example 2-60, interface serial 0/0:1 is connected to 1111, and in highlighted line 2, interface async 38 changes state to up. The remote access client is now connected to the NAS. An L2F_OPEN for the client session is sent to the Home Gateway at this point (not shown). L2F session setup fails, as shown in Example 2-61. Example 2-61. L2F Session Setup FailsJan 8 21:29:46.271 GMT: As38 Tnl/Cl 2/8 L2F: Received Session CLOSE in state opening Tunnel: open, WHY: 0x2000, STR: Jan 8 21:29:46.271 GMT: As38 Tnl/Cl 2/8 L2F: Replying with Session CLOSE In highlighted line 1 in Example 2-61, the NAS receives an L2F_CLOSE for the client session. The NAS then replies with an L2F_CLOSE. In Example 2-62, the client interface changes state to down. Example 2-62. Client Interface Changes State to DownJan 8 21:29:48.275 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down Jan 8 21:29:48.367 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:1 disconnected from 1111 , call lasted 33 seconds Jan 8 21:29:50.275 GMT: %LINK-5-CHANGED: Interface Async38, changed state to reset Jan 8 21:29:55.275 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down LODI_NAS1# Interface async 38 now changes state to down (Example 2-62, highlighted line 1), and interface serial 0/0:1 is disconnected from 1111. The L2F session setup has failed, and the client has been disconnected. The reason for the session setup failure is contained in Example 2-61 highlighted line 1. Notice the output WHY: 0x2000, STR:. This output indicates that the L2F_CLOSE shown in highlighted line 1 contains the L2F_CLOSE_WHY and L2F_CLOSE_STR suboptions (see Table 2-2). The L2F_CLOSE_WHY contains the reason code for the close, and in this case it is 0x2000. If you refer back to Table 2-3, you will see that this code indicates that a session limit has been reached or that VPDN softshut has been configured. The L2F_CLOSE_STR is an ASCII description of the tunnel or session close reason. In this case, there is no ASCII description. Having discovered the reason for the close, a look at the configuration of the Home Gateway in Example 2-63 reveals the source of the "problem." Example 2-63. Home Gateway Is Configured with a VPDN Session Limit of 1PERRIS_HGW1#show running-config Building configuration... ! vpdn enable vpdn session-limit 1 ! vpdn-group 1 accept-dialin protocol l2f virtual-template 1 terminate-from hostname LODI_NAS1 ! In the highlighted line of output, you can see the statement vpdn session-limit 1. This, as the syntax suggests, limits the L2F tunnel to one session. In this example, this limit has already been reached. This issue can be resolved by either removing the configured limit or revising it upward. In Example 2-64, the limit is removed. Example 2-64. Removal of the VPDN Session LimitPERRIS_HGW1#conf t Enter configuration commands, one per line. End with CNTL/Z. PERRIS_HGW1(config)#no vpdn session-limit 1 PERRIS_HGW1(config)#exit PERRIS_HGW1# When the client reconnects, L2F session setup succeeds. This is verified using the show vpdn tunnel all command, as shown in Example 2-65. Example 2-65. L2F Session Setup Has SucceededLODI_NAS1#show vpdn tunnel all % No active L2TP tunnels L2F Tunnel Information Total tunnels 1 sessions 2 NAS name: LODI_NAS1 NAS CLID: 1 NAS IP address 172.16.1.1 Gateway name: PERRIS_HGW1 Gateway CLID: 1 Gateway IP address 172.16.2.2 State: open Packets out: 119 Bytes out: 7204 Packets in: 149 Bytes in: 7475 LODI_NAS1# In highlighted line 1, you can see that there is one tunnel and, importantly, now two sessions established. Highlighted lines 2 to 4 show the Home Gateway's name, CLID, and IP address. The issue is now resolved. As previously mentioned, the vpdn softshut command also causes session setup to fail. The vpdn softshut command can be used by a network administrator to disallow any new sessions to the Home Gateway, while at the same time allowing any existing sessions to continue until they are closed in the normal way (for example, the client drops the connection). This allows graceful tunnel shutdown. Removal of the vpdn softshut command (no vpdn softshut) allows new sessions to be established. Home Gateway/Remote Access Client PPP Negotiation FailureOnce the L2F tunnel and session have been set up, the next stage is for PPP negotiation to be completed on the Home Gateway. Specifically, LCP negotiation, PPP authentication, and NCP negotiation must take place. Before PPP negotiation can be completed on the Home Gateway, a virtual access interface must be cloned from the virtual template. This virtual access interface is used to terminate the client PPP connection from the remote client. Before troubleshooting PPP negotiation issues on the Home Gateway, therefore, the first thing to do is to verify that configuration is being correctly cloned from the virtual template to the virtual access interface. Figure 2-35 shows the cloning of configuration from the virtual template to the virtual access interface. Figure 2-35. Cloning Configuration from the Virtual Template to the Virtual Access Interface Cloning of configuration from the virtual template to the virtual access interface can be verified with the debug vtemplate command, as demonstrated in Example 2-66. Example 2-66. Configuration Is Cloned from the Virtual Template to the Virtual Access InterfacePERRIS_HGW1#debug vtemplate Virtual Template debugging is on PERRIS_HGW1# Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 3 Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Hardware address 0006.535a.efc0 Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vtemplate Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1 *********** ****** Jan 6 20:20:25.308 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1interface Virtual-Access1 default ip address no ip address encap ppp ip unnum e0/0 encap ppp peer default ip address pool PERRIS_POOL ppp multi ppp authen chap end Jan 6 20:20:25.713 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jan 6 20:20:26.726 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up PERRIS_HGW1# Highlighted line 1 shows that configuration is about to be cloned from the virtual template to virtual access interface 1. Highlighted lines 2 to 7 show the precise configuration cloned to the virtual access interface. The virtual access interface then changes state to up (highlighted line 8). Finally, in highlighted line 9, the line protocol on the virtual access interface changes state to up. The configuration has been successfully cloned to the virtual access interface. If no configuration is cloned to the virtual access interface, use the show running-config command to verify that the virtual template is correctly referenced in the VPDN group configuration, as demonstrated in Example 2-67. Example 2-67. VPDN Group Configuration Contains Reference to the Virtual TemplatePERRIS_HGW1#show running-config Building configuration... ! vpdn-group 1 accept-dialin protocol l2f virtual-template 1 terminate-from hostname LODI_NAS1 ! In this case, the virtual template is correctly referenced in the configuration of the VPDN group. If you have user-specific configuration stored on a AAA server, as you troubleshooting PPP negotiation be sure to verify that this configuration is correct, and that it is being downloaded to the Home Gateway. One useful command when troubleshooting the download of user-specific configuration is debug aaa per-user. LCP Negotiation or PPP Authentication FailuresOnce the virtual template configuration has been cloned to the virtual access interface, the Home Gateway attempts to complete LCP negotiation and authenticate the remote client. Figure 2-36 shows the LCP negotiation and authentication phase between the client and the Home Gateway. Figure 2-36. Home Gateway Negotiates LCP and Authenticates the Remote Access Client The Home Gateway has two choices at this point. It can simply complete LCP negotiation and authentication with the client based on the information sent to it by the NAS (LCP CONFREQ and CONFACKs, plus client's username and authentication response), or it can restart LCP negotiation or authentication. Use the debug ppp negotiation command to examine the PPP negotiation sequence (including LCP negotiation and PPP authentication) on the Home Gateway. Before examining what happens when LCP negotiation or PPP authentication fail, it is worth taking a look at what happens when LCP negotiation and PPP authentication succeed (see Examples 2-68 to 2-71). Example 2-68. Successful LCP Negotiation and Authentication Between the Home Gateway and the ClientPERRIS_HGW1#debug ppp negotiation PPP protocol negotiation debugging is on PERRIS_HGW1# Jan 6 20:25:12.379 UTC: Vi4 PPP: Phase is DOWN, Setup Jan 6 20:25:12.796 UTC: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to up Jan 6 20:25:12.800 UTC: Vi4 PPP: Using set call direction Jan 6 20:25:12.800 UTC: Vi4 PPP: Treating connection as a callin Jan 6 20:25:12.800 UTC: Vi4 PPP: Phase is ESTABLISHING, Passive Open Jan 6 20:25:12.800 UTC: Vi4 LCP: State is Listen In highlighted line 1 (Example 2-68), virtual access interface 4 changes state to up. The client is now connected to the Home Gateway. Highlighted line 2 shows that the PPP phase is ESTABLISHING. LCP negotiation now begins with the processing of an inbound FORCED CONFREQ by the Home Gateway, as shown in Example 2-69. Example 2-69. Forced LCP CONFREQ
Jan 6 20:25:12.800 UTC: Vi4 LCP: I FORCED CONFREQ len 21
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 20:25:12.804 UTC: Vi4 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 20:25:12.804 UTC: Vi4 LCP: MagicNumber 0x11ADEB98 (0x050611ADEB98)
Jan 6 20:25:12.804 UTC: Vi4 LCP: PFC (0x0702)
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACFC (0x0802)
Highlighted line 1 (Example 2-69) shows that the inbound (I) FORCED CONFREQ has been received by the Home Gateway. This FORCED CONFREQ is not, in fact, a CONFREQ received directly from the client but is, instead, the CONFREQ forwarded by the NAS (L2F_REQ_LCP0) during L2F session setup. This is the initial CONFREQ received by the NAS during LCP negotiation with the client. The Home Gateway now processes an inbound FORCED CONFACK, as shown in Example 2-70. Example 2-70. Forced LCP CONFACK
Jan 6 20:25:12.804 UTC: Vi4 LCP: I FORCED CONFACK len 16
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 20:25:12.808 UTC: Vi4 LCP: MagicNumber 0x0000725F (0x05060000725F)
Jan 6 20:25:12.808 UTC: Vi4 LCP: PFC (0x0702)
Jan 6 20:25:12.808 UTC: Vi4 LCP: ACFC (0x0802)
The Home Gateway processes the inbound FORCED CONFACK (Example 2-70, highlighted line 1). Again, this is not received directly from the client but is, instead, a CONFACK forwarded by the NAS during L2F session setup (L2F_ACK_LCP2). This is the LCP CONFACK sent by the NAS during the LCP negotiation with the remote access client. LCP "negotiation" is now complete, and authentication begins, as shown in Example 2-71. Example 2-71. PPP Authentication BeginsJan 6 20:25:12.812 UTC: Vi4 PPP: Phase is AUTHENTICATING, by this end Jan 6 20:25:12.812 UTC: Vi4 CHAP: O CHALLENGE id 8 len 32 from "PERRIS_HGW1" Jan 6 20:25:12.816 UTC: Vi4 CHAP: I RESPONSE id 9 len 40 from "joebloggs@mjlnet.com" Jan 6 20:25:12.820 UTC: Vi4 CHAP: O SUCCESS id 9 len 4 Jan 6 20:25:12.820 UTC: Vi4 PPP: Phase is UP In highlighted line 1 in Example 2-71, the PPP phase changes to AUTHENTICATING, indicating that authentication is about to begin. In highlighted line 2, the NAS sends a CHAP Challenge to the client. The client replies with a Response message (highlighted line 3). The NAS then sends a Success message to the client in highlighted line 4. LCP negotiation and authentication has succeeded on the Home Gateway. In the following scenario, PPP authentication fails between the remote access client and the Home Gateway. Again, use the debug ppp negotiation command to verify PPP negotiation between the Home Gateway and the remote access client. Example 2-72 shows the output of the debug ppp negotiation command when authentication fails between the Home Gateway and the client. Note that only the relevant portion of the output is shown. Example 2-72. PPP Authentication Fails Between the Home Gateway and the Remote Access ClientPERRIS_HGW1#debug ppp negotiation PPP protocol negotiation debugging is on Jan 6 20:28:34.280 UTC: Vi3 PPP: Phase is AUTHENTICATING, by this end Jan 6 20:28:34.280 UTC: Vi3 CHAP: O CHALLENGE id 9 len 32 from "PERRIS_HGW1" Jan 6 20:28:34.284 UTC: Vi3 CHAP: I RESPONSE id 9 len 40 from "joebloggs@mjlnet.com" Jan 6 20:28:34.288 UTC: Vi3 CHAP: O FAILURE id 9 len 25 msg is "MD/DES compare failed" Highlighted line 1 shows that the PPP phase is AUTHENTICATING. Authentication is about to begin. In highlighted line 2, the Home Gateway sends a CHAP Challenge to the client. The client replies with a Response message in highlighted line 3. Then in highlighted line 4, the Home Gateway sends a Failure message to the client. Authentication has failed. The PPP connection now terminates, as shown in Example 2-73. Example 2-73. PPP Connection Teardown BeginsJan 6 20:28:34.288 UTC: Vi3 PPP: Phase is TERMINATING Jan 6 20:28:34.288 UTC: Vi3 LCP: O TERMREQ [Open] id 1 len 4 Jan 6 20:28:34.404 UTC: Vi3 LCP: I TERMREQ [TERMsent] id 4 len 8 (0x00000005) Jan 6 20:28:34.404 UTC: Vi3 LCP: O TERMACK [TERMsent] id 4 len 4 Jan 6 20:28:34.412 UTC: Vi3 LCP: I TERMACK [TERMsent] id 1 len 4 Jan 6 20:28:34.412 UTC: Vi3 LCP: State is Closed Jan 6 20:28:34.412 UTC: Vi3 PPP: Phase is DOWN Jan 6 20:28:34.416 UTC: Vi3 PPP: Phase is ESTABLISHING, Passive Open Jan 6 20:28:34.416 UTC: Vi3 LCP: State is Listen Jan 6 20:28:34.500 UTC: Vi3 PPP: No remote authentication for call-in Jan 6 20:28:34.817 UTC: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down Jan 6 20:28:34.817 UTC: Vi3 LCP: State is Closed Jan 6 20:28:34.817 UTC: Vi3 PPP: Phase is DOWN PERRIS_HGW1# In highlighted line 1, the PPP phase changes to TERMINATING. The PPP connection is about to be torn down. In highlighted lines 2 to 5, the Home Gateway and the client exchange TERMREQ and TERMACK messages, then in highlighted line 6, the PPP phase changes state to DOWN. Finally, in highlighted line 7, the virtual access interface changes state to down. PPP authentication has failed, and the client connection has been torn down. This indicates that the client's username or password is misconfigured on the client or Home Gateway. In this case, the client confirms that he is using the correct username and password, and so one or the other must be misconfigured on the Home Gateway. The client's username and password are then reconfigured on the Home Gateway, as shown in Example 2-74. Example 2-74. Reconfiguration of the Client's Username and Password on the Home GatewayPERRIS_HGW1#conf t Enter configuration commands, one per line. End with CNTL/Z. PERRIS_HGW1(config)#username joebloggs@mjlnet.com password cisco PERRIS_HGW1(config)#end PERRIS_HGW1# When the client reconnects, PPP authentication succeeds. This is verified using the show caller user on the Home Gateway, as shown in Example 2-75. Example 2-75. Output of the show caller user Command on the Home GatewayPERRIS_HGW1#show caller user joebloggs@mjlnet.com User: joebloggs@mjlnet.com, line Vi1, service PPP L2F Active time 00:33:06, Idle time 00:00:07 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP IP: Local 172.16.2.2, remote 10.10.10.50 VPDN: NAS LODI_NAS1, MID 2, MID open HGW PERRIS_HGW1, NAS CLID 1, HGW CLID 1, tunnel open Counts: 279 packets input, 10883 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 668 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets PERRIS_HGW1# Highlighted line 1 shows that user joebloggs@mjlnet.com is now connected to interface virtual access 1 and that the interface virtual access 1 is running the PPP service over L2F. In highlighted line 2, you can see that LCP, CHAP, and IPCP have been negotiated with the remote access client. Note that multilink PPP (MP) has not been negotiated with the client and so is in a Closed state. The issue is now resolved. Note that the debug ppp authentication command can also be used to verify PPP authentication. One other thing to check when verifying PPP authentication on the Home Gateway is that the client is not trying to authenticate the Home Gateway. If you are using CHAP authentication, check for any inbound (I) CHAP Challenge messages received from the client. If CHAP Challenges are being received, reconfigure the client not to authenticate the Home Gateway (unless intended). Also, if you are using a AAA server, see the case studies entitled "Remote AAA (RADIUS) Authentication Fails for the Remote Access Client" and "Remote AAA (RADIUS) Authentication Fails for the Remote Access Client" toward the end of this chapter. Finally, it is worth noting that if the Home Gateway does not accept the options in the LCP messages passed to it by the NAS (L2F_REQ_LCP0 and L2F_ACK_LCP2; see Examples 2-69 and 2-70), then you will see a message such as PPP LCP not accepting rcv CONFACK indicating that LCP negotiation has failed. In this case, one option is to configure the Home Gateway to renegotiate LCP with the remote access client using the lcp renegotiation {always | on-mismatch} command (under the VPDN group). NCP Negotiation FailureOnce the Home Gateway has completed LCP negotiation and PPP authentication with the remote access client, NCP negotiation begins. If the network layer configuration is incorrect on the virtual template interface, NCP negotiation might fail. Figure 2-37 illustrates the NCP negotiation between the client and the Home Gateway. Figure 2-37. NCP Negotiation Between the Home Gateway and the Remote Access Client Before having a look at what happens when NCP negotiation fails, it is a good idea to examine a successful NCP negotiation sequence between the Home Gateway and the client. Use the debug ppp negotiation command to examine the NCP negotiation sequence between the Home Gateway and the client. Examples 2-76 to 2-88 show the output of the debug ppp negotiation command when NCP negotiation is successful. Only the relevant portion of the output is shown. Example 2-76. NCP Negotiation Succeeds Between the Home Gateway and the Remote Access ClientPERRIS_HGW1#debug ppp negotiation PPP protocol negotiation debugging is on PERRIS_HGW1# Jan 6 20:36:29.604 UTC: Vi4 PPP: Phase is UP Once LCP negotiation and authentication have taken place, the PPP state changes to UP (highlighted line 1). NCP negotiation now begins (see Example 2-77). Example 2-77. NCP Negotiation Begins
Jan 6 20:36:29.604 UTC: Vi4 IPCP: O CONFREQ [Closed] id 1 len 10
Jan 6 20:36:29.604 UTC: Vi4 IPCP: Address 10.10.10.1 (0x03060A0A0A01)
The Home Gateway initiates IPCP negotiation by sending an IPCP (IP Control Protocol) CONFREQ to the client (see Example 2-77). In it, the Home Gateway specifies its own IP address (IPCP option 0x03, IP-Address). The remote access client then requests configuration of Microsoft Point-to-Point Compression (MS-PPC), as shown in Example 2-78. Example 2-78. Client Requests MS-PPC
Jan 6 20:36:29.712 UTC: Vi4 CCP: I CONFREQ [Not negotiated] id 4 len 10
Jan 6 20:36:29.712 UTC: Vi4 CCP: MS-PPC supported bits 0x00000001
(0x120600000001)
The Home Gateway receives an inbound (I) Compression Control Protocol (CCP) CONFREQ from the client (in Example 2-78). Within it, the client requests configuration of MS-PPC (option 0x12). The Home Gateway rejects configuration of MS-PPC in Example 2-79 by sending a PROTREJ message. Example 2-79. Home Gateway Rejects MS-PPCJan 6 20:36:29.716 UTC: Vi4 LCP: O PROTREJ [Open] id 1 len 16 protocol CCP (0x80FD0104000A120600000001) Following the rejection of MS-PPC, the client sends an IPCP CONFREQ to the Home Gateway in Example 2-80. Example 2-80. Client Sends an IPCP CONFREQ
Jan 6 20:36:29.728 UTC: Vi4 IPCP: I CONFREQ [REQsent] id 5 len 40
Jan 6 20:36:29.728 UTC: Vi4 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:36:29.732 UTC: Vi4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:36:29.732 UTC: Vi4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
The IPCP CONFREQ from the client shown in Example 2-80 requests Van Jacobson compression (option 0x02), an IP address (option 0x03), and both primary and secondary DNS and WINS server addresses (options 0x81, 0x82, 0x83, and 0x84, respectively). The Home Gateway now obtains an IP address for the client in response to its request, as shown in Example 2-81. Example 2-81. Home Gateway Obtains an IP Address from Its Pool
Jan 6 20:36:29.732 UTC: Vi4 IPCP: Pool returned 10.10.10.50
The Home Gateway then sends a CONFREJ to the client rejecting its request for Van Jacobson compression, primary/secondary WINS, and secondary DNS server addresses (see Example 2-82). Example 2-82. Home Gateway Rejects the Request for Van Jacobson Compression, Primary/Secondary WINS, and Secondary DNS Server Addresses
Jan 6 20:36:29.732 UTC: Vi4 IPCP: O CONFREJ [REQsent] id 5 len 28
Jan 6 20:36:29.736 UTC: Vi4 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
The client acknowledges the Home Gateway's IP address with a CONFACK (Example 2-83). This is in response to the CONFREQ sent by the Home Gateway in Example 2-77. Example 2-83. Client Acknowledges the Home Gateway's IP Address
Jan 6 20:36:29.736 UTC: Vi4 IPCP: I CONFACK [REQsent] id 1 len 10
Jan 6 20:36:29.740 UTC: Vi4 IPCP: Address 10.10.10.1 (0x03060A0A0A01)
In Example 2-84, the client sends a second CONFREQ requesting an IP address and a primary DNS server address. Note that these are the only IPCP options not rejected in the Home Gateway's CONFREJ (see Example 2-82). Example 2-84. Client Requests IP and Primary DNS Server Addresses
Jan 6 20:36:29.857 UTC: Vi4 IPCP: I CONFREQ [ACKrcvd] id 6 len 16
Jan 6 20:36:29.857 UTC: Vi4 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:36:29.857 UTC: Vi4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
The Home Gateway responds with a Configure-Nak (CONFNACK) in Example 2-85. This is used to supply the client with an IP address and primary DNS server address. The IP address is the one obtained from the pool in Example 2-81. Example 2-85. Home Gateway Supplies an IP Address and Primary DNS Server Address to the Client
Jan 6 20:36:29.861 UTC: Vi4 IPCP: O CONFNAK [ACKrcvd] id 6 len 16
Jan 6 20:36:29.861 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.861 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
The client then responds with another CONFREQ in Example 2-86. This serves to confirm the IP and DNS server address just supplied by the Home Gateway. Example 2-86. Client Confirms Its IP Address and Primary DNS Server Addresses
Jan 6 20:36:29.977 UTC: Vi4 IPCP: I CONFREQ [ACKrcvd] id 7 len 16
Jan 6 20:36:29.981 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.981 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
The Home Gateway now acknowledges the client's IP address and primary DNS server addresses with a CONFACK (see Example 2-87). Example 2-87. Home Gateway Acknowledges the Client's IP Address and Primary DNS Server Address
Jan 6 20:36:29.981 UTC: Vi4 IPCP: O CONFACK [ACKrcvd] id 7 len 16
Jan 6 20:36:29.981 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.981 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
Finally, in Example 2-88, the IPCP state changes to OPEN (highlighted line 1), a route to the client is installed in the routing table (highlighted line 2), and the virtual access interface changes state to up (highlighted line 3). Example 2-88. IPCP State Changes to OPEN, and the Virtual Access Interface Line Protocol State Changes to UpJan 6 20:36:29.985 UTC: Vi4 IPCP: State is Open Jan 6 20:36:29.985 UTC: Vi4 IPCP: Install route to 10.10.10.50 Jan 6 20:36:30.606 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access4, changed state to up Jan 6 20:36:31.588 UTC: Vi4 LCP: TIMEout: State Open PERRIS_HGW1# NCP negotiation has been completed successfully. Note that in this example, IP is the only network layer protocol configured on the Home Gateway and the client. If other protocols such as IPX are configured, then their respective NCPs are also negotiated. Now that you have seen successful NCP negotiation between the Home Gateway and the client, it is time to examine what happens when NCP negotiation is not successful. The debug ppp negotiation command is again used to examine the NCP negotiation sequence. Examples 2-89 to 2-94 show the output of the debug ppp negotiation command. Note that only the relevant portion of the output is shown. Example 2-89. NCP Negotiation Is UnsuccessfulPERRIS_HGW1#debug ppp negotiation PPP protocol negotiation debugging is on PERRIS_HGW1# Jan 6 20:44:27.221 UTC: Vi1 PPP: Phase is UP The sequence begins in Example 2-89 with the PPP phase changing to UP. This indicates that NCP negotiation is about to start. Immediately after NCP negotiation begins, a Compression Control Protocol (CCP) CONFREQ is received from the client (see Example 2-90). In it, the client requests configuration of MS-PPC. Example 2-90. CCP CONFREQ Received from the Client
Jan 6 20:44:27.385 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 4 len 10
Jan 6 20:44:27.385 UTC: Vi1 CCP: MS-PPC supported bits 0x00000001
(0x120600000001)
The Home Gateway, however, rejects CCP (including MS-PPC), as shown in Example 2-91. Example 2-91. Home Gateway Rejects CCP
Jan 6 20:44:27.385 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol CCP
(0x80FD0104000A120600000001)
In Example 2-92, the client sends an IPCP CONFREQ to the Home Gateway, requesting an IP address and the addresses of primary and secondary DNS and WINS servers. Example 2-92. Client Sends an IPCP CONFREQ
Jan 6 20:44:27.397 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 5 len 40
Jan 6 20:44:27.397 UTC: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:44:27.397 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
At this point, the Home Gateway sends a PROTREJ to the client rejecting configuration of IPCP (see Example 2-93). Example 2-93. Home Gateway Rejects Configuration of IPCP
Jan 6 20:44:27.401 UTC: Vi1 LCP: O PROTREJ [Open] id 2 len 46 protocol IPCP
Jan 6 20:44:27.401 UTC: Vi1 LCP: (0x8021010500280206002D0F0103060000)
Jan 6 20:44:27.405 UTC: Vi1 LCP: (0x00008106000000008206000000008306)
Jan 6 20:44:27.405 UTC: Vi1 LCP: (0x00000000840600000000)
Once the Home Gateway has rejected the configuration of IPCP, things go downhill very quickly. In Example 2-94, the remote access client connection is torn down. Example 2-94. Client Connection Is Torn DownJan 6 20:44:28.222 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up Jan 6 20:44:29.208 UTC: Vi1 LCP: TIMEout: State Open Jan 6 20:44:31.207 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down Jan 6 20:44:31.211 UTC: Vi1 PPP: Phase is TERMINATING Jan 6 20:44:31.211 UTC: Vi1 LCP: State is Closed Jan 6 20:44:31.211 UTC: Vi1 PPP: Phase is DOWN Jan 6 20:44:32.209 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down PERRIS_HGW1# In highlighted line 1 in Example 2-94, interface virtual access 1 changes state to down. Then in highlighted line 2, the PPP phase changes to TERMINATING. This indicates the Home Gateway's intention to tear down the client connection. Finally, in highlighted line 3, the PPP phase changes to DOWN. The client connection has been torn down. What went wrong? The answer is in Example 2-93. At this point in the NCP negotiation sequence, the Home Gateway rejected configuration of IPCP. There is only one reason that the Home Gateway would reject configuration of IPCP: if there is no IP address configured on the virtual template. The virtual template configuration is then examined using the show running-config command, as shown in Example 2-95. Note that only the relevant portion of the output is shown. Example 2-95. Configuration of the Virtual TemplatePERRIS_HGW1#show running-config Building configuration... ! interface Virtual-Template1 no ip address peer default ip address pool PERRIS_POOL ppp authentication chap ppp multilink ! As expected, there is no IP address on the virtual template interface. This is remedied by configuring ip unnumbered on the virtual template, as shown in Example 2-96. Example 2-96. Configuration of ip unnumbered on the Virtual TemplatePERRIS_HGW1#conf t Enter configuration commands, one per line. End with CNTL/Z. PERRIS_HGW1(config)#interface virtual-template1 PERRIS_HGW1(config-if)#ip unnumbered ethernet0/0 PERRIS_HGW1(config-if)#exit PERRIS_HGW1# Once ip unnumbered has been configured on the virtual template, the client reconnects, and NCP negotiation is successful. Use the show caller user command to verify NCP negotiation on the Home Gateway. Example 2-97 shows the output of the show caller user command when IPCP negotiation has been successful. Example 2-97. Output of the show caller user CommandPERRIS_HGW1#show caller user joebloggs@mjlnet.com User: joebloggs@mjlnet.com, line Vi1, service PPP L2F Active time 00:01:15, Idle time 00:00:09 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP IP: Local 172.16.2.2, remote 10.10.10.50 VPDN: NAS LODI_NAS1, MID 18, MID open HGW PERRIS_HGW1, NAS CLID 3, HGW CLID 17, tunnel open Counts: 46 packets input, 4286 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 32 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets PERRIS_HGW1# Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to interface virtual access 1. Interface virtual access 1 is running the PPP service (over L2F). Highlighted line 2 shows that LCP, CHAP, and IPCP have been successfully negotiated with the client. Also note that multilink PPP (MP) has not been negotiated, and so is in a Closed state. The issue is resolved. One other thing to note is that clients, including Cisco routers, will not necessarily terminate the connection just because IPCP has not been negotiated. Check the status of the connection using the show caller user or show interfaces virtual-access command.  |
|
|
