Other CommandsThis section briefly covers some other commands that might be useful when troubleshooting L2TPv3. show l2tun tunnel allThe show l2tun tunnel all command can be used to display information about the L2TPv3 control connection. Example 5-49 shows output from the show l2tun tunnel all command. Example 5-49. show l2tun tunnel all Command OutputLondon_LCCE#show l2tun tunnel all Tunnel Information Total tunnels 1 sessions 1 Tunnel id 61973 is up, remote id is 39248, 1 active sessions Tunnel state is established, time since change 00:06:01 Tunnel transport is IP (115) Remote tunnel name is Frankfurt_LCCE Internet Address 10.1.1.2, port 0 Local tunnel name is London_LCCE Internet Address 10.1.1.1, port 0 Tunnel domain is VPDN group for tunnel is - L2TP class for tunnel is FrankfurtV3Class 126 packets sent, 17 received 5432 bytes sent, 924 received Control Ns 126, Nr 82 Local RWS 3000 (default), Remote RWS 3000 (max) Tunnel PMTU checking disabled Retransmission time 1, max 1 seconds Unsent queuesize 0, max 0 Resend queuesize 0, max 2 Total resends 0, ZLB ACKs sent 79 Current nosession queue check 0 of 5 Retransmit time distribution: 0 0 0 0 0 0 0 0 0 Sessions disconnected due to lack of resources 0 London_LCCE# Highlighted line 1 shows that there is one tunnel (control connection) and one session established. In highlighted line 2, you can see that there is a control connection with local ID 61973 and remote ID 39248, together with one associated session. Highlighted lines 3 to 20 show details of this control connection. Highlighted line 3 shows that the control connection is established and that the time since the last state change is 6 minutes and 1 second. Highlighted line 4 shows that the control connection is using IP protocol 115. Highlighted lines 5 to 8 show the remote and local LCCE names and IP addresses. The remote LCCE name and IP address are Frankfurt_LCCE and 10.1.1.2, respectively. The local LCCE name and IP address are London_LCCE and 10.1.1.1, respectively. The L2TP class is shown in highlighted line 9 (FrankfurtV3Class). The number of packets and bytes sent and received are shown in highlighted lines 10 and 11. Highlighted line 12 shows the Next Sent (Ns) and Next Receive (Nr) values. The local and remote receive window sizes (RWS) are shown in highlighted line 13. The receive window size can be modified using the receive-window command (within the L2TP class). Note that the local receive window size is communicated to the remote peer in a Receive Window Size AVP during control connection setup (see Table 5-7). In highlighted line 14, you can see that Path MTU (PMTU) checking is disabled. This can be enabled using the ip pmtu command (within the pseudowire class). The retransmission time for control messages is shown in highlighted line 15 (1 second). This can be modified using the retransmit command (within the L2TP class). Unsent and resend queue sizes are shown in highlighted lines 16 and 17. The total number of resends (retransmissions) and ZLB Acks sent are shown in highlighted line 18. Highlighted line 19 shows the distribution of retransmission times. Finally, highlighted line 20 shows the number of sessions disconnected because of a lack of resources. show l2tun session allThis command displays information about L2TPv3 sessions. Example 5-50 shows output from the show l2tun session all command. Example 5-50. show l2tun session all Command OutputLondon_LCCE#show l2tun session all Session Information Total tunnels 1 sessions 1 Session id 22529 is up, tunnel id 61973 Call serial number is 4093900000 Remote tunnel name is Frankfurt_LCCE Internet address is 10.1.1.2 Session is L2TP signalled Session state is established, time since change 00:05:40 28 Packets sent, 4 received 1130 Bytes sent, 136 received Receive packets dropped: out-of-order: 0 total: 0 Send packets dropped: exceeded session MTU: 0 total: 0 Session vcid is 121 Session Layer 2 circuit, type is Frame Relay, name is Serial4/1:60 Circuit state is UP Remote session id is 52765, remote tunnel id 39248 DF bit off, ToS reflect disabled, ToS value 0, TTL value 255 No session cookie information available SSS switching enabled Sequencing is on Ns 28, Nr 4, 0 out of order packets received London_LCCE# Highlighted line 1 shows that there is one tunnel (control connection) and one session. Highlighted line 2 shows the session ID (22529) and the control connection ID (tunnel ID, 61973). Highlighted lines 3 to 23 show details about the session. The call serial number is shown in highlighted line 3. The name of the remote LCCE (Frankfurt_LCCE), together with its IP address (10.1.1.2) are shown in highlighted lines 4 and 5. Highlighted line 6 shows this L2TP session was dynamically signaled. The session state (established), as well as the time since the last session state change, are shown in highlighted line 7. The number of packets and bytes sent and received are shown in highlighted lines 8 and 9. Highlighted lines 10 and 11 show the number of receive packets dropped, and highlighted lines 12 and 13 show the number of send packets dropped. The VCID associated with the session is shown in highlighted line 14 (121), and the Layer 2 circuit type (Frame Relay), interface (serial 4/1), and DLCI (60) are shown in highlighted line 15. Highlighted line 16 shows the circuit state (UP). The remote session and tunnel (control connection) IDs are shown in highlighted line 17 (52765 and 39248, respectively). Highlighted line 18 shows that the Don't Fragment (DF) bit is not set in the IP header of L2TPv3 packets. If you want to set the DF bit, use the ip dfbit set command (in the pseudowire class). Highlighted line 18 also shows that Type of Service (ToS) reflection is disabled and that the IP header of L2TPv3 packets contains a ToS value of zero and a Time-to-Live (TTL) value of 255. ToS reflection can be enabled using the ip tos reflect pseudowire class command. This command configures the LCCE to copy the ToS value from tunneled packets to the IP header of L2TPv3 packets. If ToS reflection is not configured, the ToS value shown in highlighted line 18 is copied into the IP header of L2TPv3 packets. The default ToS value is zero, but this can be modified using the ip tos value under the pseudowire class configuration. The TTL copied to the IP header of L2TPv3 packets can be set using the ip ttl pseudowire command (the default is 255). Highlighted line 19 shows that Subscriber Switch Service (SSS) is enabled (see www.cisco.com for more on this). In highlighted line 20, you can see that L2TPv3 packet sequencing is enabled. This is disabled by default, but can be enabled using the sequencing {transmit | receive | both} pseudowire class command. Highlighted line 21 shows the Next sent (Ns) and Next received (Nr) values, together with the number of packets received out of order. debug acircuit [error | event]The debug acircuit [error | event] commands display attachment circuit error and event information, including provisioning events, circuit up/down events, and setup or configuration failures. Example 5-51 shows output from the debug acircuit event command. Information regarding a circuit on interface serial 4/1 is shown. Example 5-51. debug acircuit event Command Output
London_LCCE#debug acircuit event
Attachment Circuit events debugging is on
London_LCCE#
*Apr 2 20:04:52.263 UTC: %LINK-3-UPDOWN: Interface Serial4/1, changed state to up
*Apr 2 20:04:52.263 UTC: ACMGR: Receive <Circuit Up> msg
*Apr 2 20:04:52.263 UTC: Se4/1 ACMGR: circuit up event, SIP state chg down to
connecting, action is service request
*Apr 2 20:04:52.263 UTC: Se4/1 ACMGR: Sent a sip service request
*Apr 2 20:04:52.263 UTC: ACMGR: Receive <Circuit Up> msg
*Apr 2 20:04:52.263 UTC: Se4/1 ACMGR: circuit up event, SIP state chg down to
connecting, action is service request
*Apr 2 20:04:52.263 UTC: Se4/1 ACMGR: Sent a sip service request
*Apr 2 20:04:52.267 UTC: Se4/1 ACMGR: Rcv SIP msg: resp connect forwarded,
hdl 2A0001BD, sss_hdl EE0001C1
*Apr 2 20:04:52.267 UTC: Se4/1 ACMGR: service connected event, SIP state chg
connecting to conne
10:02:39: %LINK-3-UPDOWN: Interface Serial0, changed state to up
10:02:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to
upcted, action is respond forwarded
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: Receive <Circuit Down> msg
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: circuit down event, SIP state chg connecting to
end, action is service disconnect
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: Sent a sip service disconnect
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: Receive <Circuit Down> msg
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: circuit down event, SIP state chg connected to
end, action is service disconnect
*Apr 2 20:04:53.263 UTC: Se4/1 ACMGR: Sent a sip service disconnect
London_LCCE#
debug xconnect [error | event]This command displays xconnect configuration error and event information. Example 5-52 shows output from the debug xconnect event command. In this case, event information is shown for DLCIs 50 and 60 on interface serial 4/1. Example 5-52. debug xconnect event Command OutputLondon_LCCE#debug xconnect event *Apr 2 20:05:40.771 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial4/1, debug vpdn l2tp-sequencingThe debug vpdn l2tp-sequencing command displays the Next sent (Ns) and Next received (Nr) sequence numbers contained in L2TPv3 packets. Example 5-53 shows output from the debug vpdn l2tp-sequencing command. Example 5-53. debug vpdn l2tp-sequencing Command OutputLondon_LCCE#debug vpdn l2tp-sequencing L2TP data sequencing debugging is on London_LCCE# *Apr 2 20:09:49.935 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/101, our ns/nr 102/72 *Apr 2 20:09:49.935 UTC: Tnl61973 L2TP: Peer acknowledging through 101 *Apr 2 20:09:49.935 UTC: Tnl61973 L2TP: Dropped ZLB ACK *Apr 2 20:09:49.935 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/101, our ns/nr 102/72 *Apr 2 20:09:49.939 UTC: Tnl61973 L2TP: Dropped ZLB ACK *Apr 2 20:09:49.951 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/102, our ns/nr 102/72 *Apr 2 20:09:49.951 UTC: Tnl61973 L2TP: Peer acknowledging through 102 *Apr 2 20:09:49.951 UTC: Tnl61973 L2TP: Dropped ZLB ACK London_LCCE# Highlighted line 1 shows the peer and local Ns and Nr sequence numbers. In highlighted line 2, you can see that the peer LCCE has acknowledged L2TPv3 packets up to sequence number 101. debug vpdn packetThe debug vpdn packet displays L2TPv3 packets CEF and fast switched to and from the peer LCCE. Example 5-54 shows output from the debug vpdn packet command. Example 5-54. debug vpdn packet Command OutputLondon_LCCE#debug vpdn packet VPDN packet debugging is on London_LCCE# *Apr 2 20:13:33.551 UTC: VPDN CEF From tunnel: Received 48 byte pak *Apr 2 20:13:33.551 UTC: VPDN CEF From tunnel: Pak consumed *Apr 2 20:13:33.551 UTC: L2X: IP socket write 40 bytes, 10.1.1.1 to 10.1.1.2, prot 115 *Apr 2 20:13:33.571 UTC: L2X: IP socket write 48 bytes, 10.1.1.1 to 10.1.1.2, prot 115 *Apr 2 20:13:33.583 UTC: VPDN CEF From tunnel: Received 40 byte pak *Apr 2 20:13:33.583 UTC: VPDN CEF From tunnel: 40 byte buffer returned *Apr 2 20:13:33.583 UTC: VPDN FS From tunnel: Received 40 byte pak *Apr 2 20:13:33.583 UTC: VPDN FS From tunnel: 40 byte buffer returned *Apr 2 20:13:35.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:37.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:38.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:39.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:40.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:44.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot 115 *Apr 2 20:13:46.087 UTC: aie_sid:6 VPDN FS Into tunnel (SSS): Sending pak *Apr 2 20:13:46.087 UTC: aie_sid:6 VPDN FS/CEF Into tunnel: Sending 80 byte pak *Apr 2 20:13:46.087 UTC: aie_sid:6 VPDN CEF Into tunnel (SSS): Pak send successful London_LCCE# Highlighted line 1 shows that a 48-byte packet has been received by the local LCCE. In highlighted line 2, you can see that an 80-byte packet has been sent by the local LCCE. CAUTION Note that extra caution should be exercised when using this command because it can produce copious output. debug vpdn l2x-packetsYou can use the debug vpdn l2x-packets command to display detailed L2TPv3 control packet information. Example 5-55 shows output from the debug vpdn l2x-packets command. Example 5-55. debug vpdn l2x-packets Command OutputLondon_LCCE#debug vpdn l2x-packets L2X control packets debugging is on London_LCCE# *Mar 29 22:26:13.171 UTC: Tnl51541 L2TP: O Hello to Stockholm_LCCE tnlid 20631 *Mar 29 22:26:13.171 UTC: Tnl51541 L2TP: O Hello, flg TLS, ver 3, len 20, tnl 20631, ns 47, nr 45 00 00 00 00 C8 03 00 14 00 00 50 97 00 2F 00 2D 80 08 00 00 00 00 00 06 *Mar 29 22:26:35.243 UTC: Tnl/Sn58687/53867 L2TP: O CDN to Frankfurt_LCCE 34029/60109 *Mar 29 22:26:35.243 UTC: Tnl/Sn58687/53867 L2TP: O CDN, flg TLS, ver 3, len 50, tnl 34029, lsid 53867, rsid 60109, ns 38, nr 39 00 00 00 00 C8 03 00 32 00 00 84 ED 00 26 00 27 80 08 00 00 00 00 00 0E 80 0A 00 00 00 01 00 01 00 00 80 0A 00 09 00 03 00 00 D2 6B 80 0A 00 09 00 04 00 00 EA CD London_LCCE# Highlighted line 1 shows that a L2TPv3 Hello message has been sent to Stockholm_LCCE. In highlighted line 2, you can see the contents of the L2TPv3 packet header for the hello message. In particular, you can see that the Type (T), Length (L), and Sequence number (S) flags are set in the L2TPv3 header. You can also see that the version is 3 (L2TPv3), the length is 20, the control connection ID is 20631, and that the Next sent (Ns) and Next received (Nr) values are 47 and 45, respectively. Highlighted line 3 shows that a CDN message has been sent to Frankfurt_LCCE. Highlighted line 4 shows the TLS flags, version field value, length field value, control connection ID, local (LSID) and remote (RSID) session IDs, and the Next sent (Ns) and Next received (Nr) values of the L2TPv3 header of the CDN message. CAUTION Note that extra caution should be exercised when using this command because it can produce copious output. |