|
|
Additional L2TP Troubleshooting CommandsThis section contains some additional commands that may be useful when troubleshooting L2TP. show vpdn history failureThe show vpdn history failure command is very useful for examining the VPDN failure history table. Example 4-140 shows the output of the show vpdn history failure command. Example 4-140. show vpdn history failure Command OutputCalCity_LAC#show vpdn history failure Table size: 20 Number of entries in table: 1 User: joebloggs@mjlnet.com, MID = 32 NAS: CalCity_LAC, IP address = 172.16.1.1, CLID = 0 Gateway: Information is not applicable Log time: Feb 11 22:01:39.962, Error repeat count: 7 Failure type: The remote server closed this session Failure reason: Result 2, Error 6, Session limit CalCity_LAC# Highlighted line 1 shows the history table size (20, the default), and in highlighted line 2, the current size is shown (1). The username corresponding to the entry in the table is shown in highlighted line 3. The LAC hostname and IP address are shown in highlighted line 4. In highlighted line 5, the time the failure was last logged is shown, together with the number of times this failure has occurred. Finally, in highlighted lines 6 and 7, a description of the failure, as well as the associated Reason and Error codes (see Tables 4-4, 4-5, and 4-6) are shown. Note that the size of the failure history table can be modified using the vpdn history failure table-size command. Additionally, the table can be cleared using the clear vpdn history failure command. show vpdn session allThe show vpdn session all command displays detailed information about L2TP sessions. Example 4-141 shows the output of the show vpdn session all command. Example 4-141. show vpdn session all Command OutputCalCity_LAC#show vpdn session all L2TP Session Information Total tunnels 1 sessions 1 Call id 18 is up on tunnel id 12471 Call serial number is 2364200016 Remote tunnel name is Skydance_LNS Internet Address is 172.16.5.5 Session username is ltahoe@mjlnet.com, state is established Time since change 00:01:21, interface As34 Remote call id is 18 Fastswitching is enabled 50 packets sent, 47 received 7118 bytes sent, 2672 received Sequencing is off %No active L2F tunnels %No active PPTP tunnels %No active PPPoE tunnels CalCity_LAC# Highlighted line 1 shows the number of tunnels and sessions established. In highlighted line 2, the Call (session) ID is displayed, together with its associated tunnel ID. Next, the Call Serial Number is shown (highlighted line 3). The Call Serial Number is used to identify the session, but unlike the Session ID, it is globally unique. Note that the Call Serial Number is used for administrative purposes. The remote tunnel name is shown in highlighted line 4. This corresponds to the L2TP peer's hostname. After the remote tunnel name is the IP address of the remote peer (highlighted line 5). Highlighted line 6 displays the username associated with this L2TP session. The session state is also shown in this line. The time since the session state last changed, as well as the interface with which the session is associated, is shown in highlighted line 7. Highlighted line 8 shows the remote Call (session) ID. Highlighted line 9 shows whether fast switching is enabled for this session. If it is disabled, there are a number of possible causes, the most likely of which are that either UDP checksums have been enabled for L2TP packets (using the l2tp ip udp checksum command) or that L2TP packets are being fragmented on the link between the LAC and LNS. To solve the first problem, simply disable UDP checksums using the no l2tp ip udp checksum command. It is worth noting that Cisco routers do not have checksums enabled by default. The second problem is caused when large packets are sent over the link between the LAC and LNS. This issue is caused because the original (large) PPP frame plus the L2TP, UDP, and IP headers exceeds the link MTU. See the section entitled "Configuring the LNS" earlier in this chapter for more details on this. The number of packets and bytes sent and received are shown in highlighted lines 10 and 11. Highlighted line 12 shows whether or not sequencing has been enabled for this session. L2TP sequencing can be enabled using the l2tp sequencing command. debug vpdn errorThe debug vpdn error command displays VPDN protocol errors. Example 4-142 shows the output of the debug vpdn error command. Example 4-142. debug vpdn error Command OutputCalCity_LAC#debug vpdn error VPDN errors debugging is on CalCity_LAC# Feb 5 20:33:53.925 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Feb 5 20:33:59.925 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Feb 5 20:34:35.041 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to up Feb 5 20:34:40.397 UTC: VPDN/mjlnet.com: Authorization failed, could not talk to AAA server or local tunnel problem Feb 5 20:34:40.401 UTC: VPDN/dnis:7777: Authorization failed, could not talk to AAA server or local tunnel problem Feb 5 20:34:40.985 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 47 seconds Feb 5 20:34:44.105 UTC: %LINK-5-CHANGED: Interface Async36, changed state to reset Feb 5 20:34:49.105 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to down Feb 5 20:35:48.937 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Feb 5 20:35:52.577 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to 1111 Feb 5 20:35:52.577 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from 1111 , call lasted 3 seconds CalCity_LAC# Highlighted line 1 indicates that authorization for the tunnel has failed based on the domain name (mjlnet.com). This error means that either connectivity to the AAA server has been lost or there is no locally configured VPDN group that corresponds to this domain name. Similarly, in highlighted line 2, authorization for the tunnel has failed based on the DNIS string (7777). Again, this error means that connectivity to the AAA server has been lost or that the DNIS does not correspond to any locally configured VPDN groups. debug vpdn l2x-dataThe debug vpdn l2x-data command shows L2TP data packets. Extra care should be taken when using this command, as it can produce a large amount of output. Example 4-143 shows the output of the debug vpdn l2x-data command. Example 4-143. debug vpdn l2x-data Command OutputCalCity_LAC#debug vpdn l2x-data L2X data packets debugging is on CalCity_LAC# *Mar 1 01:20:29.811 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data, flg L, ver 2, len 16, tnl 31626, cl 5 00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00 00 2C 04 16 00 00 FD 11 F4 80 AC 10 05 05 0A 14 0A 01 06 A5 06 A5 00 18 00 00 40 02 00 10 7B ... *Mar 1 01:20:29.815 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data, flg L, ver 2, len 22, tnl 31626, cl 5 00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00 00 32 04 17 00 00 FD 11 F4 79 AC 10 05 05 0A 14 0A 01 06 A5 06 A5 00 1E 00 00 40 02 00 16 7B ... *Mar 1 01:20:29.927 UTC: As36 Tnl/Sn31626/5 L2TP: FS into tunnel, src 172.16.1.1(1701), dst 172.16.5.5(1701), len 62 *Mar 1 01:20:29.931 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data, flg L, ver 2, len 28, tnl 31626, cl 5 00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00 00 38 04 18 00 00 FD 11 F4 72 AC 10 05 05 0A 14 0A 01 06 A5 06 A5 00 24 00 00 40 02 00 1C 7B ... Highlighted line 1 shows a L2TP data packet being received. Notice the Length (L) flag is set, the Length is 16, and the Tunnel ID is 31626. Directly below this is the raw data contained within the packet. In highlighted line 2, a data packet is sent (fast switched) to into the tunnel. The source and destination IP addresses and UDP ports are also shown. debug vpdn l2x packetsThe debug vpdn l2x-packets command displays L2TP control packets. Again, extra care should be taken when using this command, as it can produce large amounts of output. Example 4-144 shows the output of the debug vpdn l2x-packets command. Example 4-144. debug vpdn l2x-packets Command OutputCalCity_LAC#debug vpdn l2x-packets L2X control packets debugging is on CalCity_LAC# *Mar 1 01:23:34.475 UTC: Tnl63051 L2TP: O SCCRQ *Mar 1 01:23:34.475 UTC: Tnl63051 L2TP: O SCCRQ, flg TLS, ver 2, len 136, tnl 0, cl 0, ns 0, nr 0 C8 02 00 88 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 ... *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 0, len 8, flag 0x8000 (M) *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse SCCRP *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 2, len 8, flag 0x8000 (M) *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Protocol Ver 256 *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 3, len 10, flag 0x8000 (M) *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Framing Cap 0x0 *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 4, len 10, flag 0x8000 (M) *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Bearer Cap 0x0 *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 6, len 8, flag 0x0 *Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Firmware CalCity_LAC# Ver 0x1120 *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 7, len 18, flag 0x8000 (M) *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Hostname Skydance_LNS *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 8, len 25, flag 0x0 *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Vendor Name Cisco Systems, Inc. *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 9, len 8, flag 0x8000 (M) *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Assigned Tunnel ID 8409 *Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 10, len 8, flag 0x8000 (M) *Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Rx Window Size 10000 *Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Parse AVP 11, len 22, flag 0x8000 (M) *Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Chlng 88 CF E6 16 6C B5 90 BB EC 6B BC 6B DB 82 23 DF *Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Parse AVP 13, len 22, flag 0x8000 (M) *Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Chlng Resp F2 3E E7 94 F3 30 C2 FE 20 70 BC 29 5C 4D 0E A4 *Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: No missing AVPs in SCCRP *Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: I SCCRP, flg TLS, ver 2, len 159, tnl 63051, cl 0, ns 0, nr 1 C8 02 00 9F F6 4B 00 00 00 00 00 01 80 08 00 00 00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 ... *Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: I SCCRP from Skydance_LNS *Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: O SCCCN to Skydance_LNS tnlid 8409 *Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: O SCCCN, flg TLS, ver 2, len 42, tnl 8409, cl 0, ns 0, nr 1 C8 02 00 2A 20 D9 00 00 00 00 00 01 80 08 00 00 00 00 00 03 80 16 00 00 00 0D 6F 12 DE 59 3A 61 07 60 9A 08 47 1C C2 80 B5 63 Highlighted line 1 shows the packet header of an outgoing SCCRQ. The Type (T), Length (L), and Sequencing (S) bits are set to 1 in the L2TP header. These bit settings indicate that this is a control packet, and that the Length and Sequencing (Nr/Ns) fields are present. The version is shown as 2 (L2TPv2), the Length is 136, the tunnel and session IDs are both 0, and the Ns and Nr fields are also both set to 0. In highlighted line 12, a SCCRP is received. Again, the packet header is shown. More interestingly, however, are the AVPs that are contained within the SCCRP message. These are shown in highlighted lines 2 to 11. See Table 4-2 and 4-7 at the beginning of this chapter for more details on these AVPs. AVP type numbers, together with the Length and flags set in the AVP headers are shown. Note that each AVP is marked as mandatory (M). Finally, in highlighted line 13, an outgoing SCCCN is shown. debug vpdn packetThe debug vpdn packet command displays VPDN packets. Example 4-145 shows the output of the debug vpdn packet command. Example 4-145. debug vpdn packet Command OutputCalCity_LAC#debug vpdn packet VPDN packet debugging is on CalCity_LAC# *Mar 1 01:25:58.307 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC *Mar 1 01:25:58.307 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC *Mar 1 01:25:58.415 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 62 *Mar 1 01:25:58.415 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC *Mar 1 01:25:58.431 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 92 *Mar 1 01:25:58.435 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC *Mar 1 01:25:58.435 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 62 *Mar 1 01:25:58.547 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 74 *Mar 1 01:25:58.547 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC CalCity_LAC# Highlighted lines 1, 2, and 3 show L2TP packets being fast switched out of and into the L2TP tunnel. clear vpdn tunnelThe clear vpdn tunnel command can be used to manually tear down L2TP tunnels. Example 4-146 shows a L2TP tunnel with remote name Skydance_LNS and local name CalCity_LAC being torn down. Example 4-146. clear vpdn tunnel Command Output
CalCity_LAC#clear vpdn tunnel l2tp Skydance_LNS CalCity_LAC
Clearing all sessions and dropping the tunnel
CalCity_LAC#
 |
|
|