L2TP Congestion Avoidance

Table Of Contents

L2TP Congestion Avoidance

debug vpdn

l2tp congestion-control

show vpdn tunnel

L2TP Congestion Avoidance

---

The L2TP Congestion Avoidance feature provides packet flow control and congestion avoidance by throttling Layer 2 Transport Protocol (L2TP) control messages as described in RFC 2661. Throttling L2TP control message packets prevents dropped sessions when the peer's input buffer overflows.

Before the introduction of the L2TP Congestion Avoidance feature, the window size used to send packets between the network access server (NAS) and the tunnel server was set to the value advertised by the peer endpoint and was never changed. Configuring the L2TP Congestion Avoidance feature allows the L2TP packet window to be dynamically resized using a sliding window mechanism. The window size grows larger when packets are delivered successfully, and is reduced when dropped packets must be retransmitted.

L2TP congestion avoidance is useful in networks with a relatively high rate of calls being placed by either tunnel endpoint. L2TP congestion avoidance is also useful on highly scalable platforms such as the Cisco 10000 router, which supports a large number of simultaneous sessions.

Configuration Information

Configuration information is included in the "VPDN Tunnel Management" chapter in the Cisco IOS VPDN Configuration Guide, Release 12.4T, at the following URL:

•http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcg/tvpdn_c/vpc7tmht.htm

Command Reference

This section documents new and modified commands.

•debug vpdn

•l2tp congestion-control

•show vpdn tunnel

debug vpdn

To troubleshoot Layer 2 Forwarding (L2F) or Layer 2 Tunnel Protocol (L2TP) virtual private dialup network (VPDN) tunneling events and infrastructure, use the debug vpdn command in privileged EXEC mode. To disable debugging output, use the no form of this command.

debug vpdn {call {event | fsm} | error | event [disconnect] | l2tp-sequencing | l2x-data | l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event | fsm}}

no debug vpdn {call {event | fsm} | error | event [disconnect] | l2tp-sequencing | l2x-data | l2x-errors | l2x-events | l2x-packets | message | packet [detail | errors] | sss {error | event | fsm}}

Syntax Description

call event	Displays significant events in the VPDN call manager.
call fsm	Displays significant events in the VPDN call manager finite state machine (fsm).
error	Displays VPDN errors.
event	Displays VPDN events.
disconnect	(Optional) Displays VPDN disconnect events.
l2tp-sequencing	Displays significant events related to L2TP sequence numbers such as mismatches, resend queue flushes, and drops.
l2x-data	Displays errors that occur in data packets.
l2x-errors	Displays errors that occur in protocol-specific conditions.
l2x-events	Displays events resulting from protocol-specific conditions.
l2x-packets	Displays detailed information about control packets in protocol-specific conditions.
message	Displays VPDN interprocess messages.
packet	Displays information about VPDN packets.
detail	(Optional) Displays detailed packet information, including packet dumps.
errors	(Optional) Displays errors that occur in packet processing.
sss error	Displays debug information about VPDN Subscriber Service Switch (SSS) errors.
sss event	Displays debug information about VPDN SSS events.
sss fsm	Displays debug information about the VPDN SSS fsm.

Command Modes

Privileged EXEC

Command History

0S Release	Modification
12.0(23)S	This command was integrated into Cisco IOS Release 12.0(23)S.
12.0(31)S	The output was enhanced to display messages about control channel authentication events.
S Release	Modification
12.2(22)S	This command was integrated into Cisco IOS Release 12.2(22)S.
12.2(27)SBC	Support for enhanced display of messages about control channel authentication events was added in Cisco IOS Release 12.2(27)SBC.
12.2(28)SB	Support for the display of messages about congestion avoidance events was added in Cisco IOS Release 12.2(28)SB.
T Release	Modification
11.2	This command was introduced.
12.0(5)T	Support was added for L2TP debugging messages. The l2tp-sequencing and error keywords were added. The l2f-errors, l2f-events, and l2f-packets keywords were changed to l2x-errors, l2x-events, and l2x-packets.
12.2(4)T	Support was added for the message and call {event | fsm} keywords.
12.2(11)T	Support was added for the detail keyword.
12.2(13)T	Support was added for the sss {error | event | fsm} keywords.

Usage Guidelines

Note that the debug vpdn packet and debug vpdn packet detail commands generate several debug operations per packet. Depending on the L2TP traffic pattern, these commands may cause the CPU load to increase to a high level that impacts performance.

Examples

This section contains the following examples:

•Debugging VPDN Events on a NAS—Normal L2F Operations

•Debugging VPDN Events on the Tunnel Server—Normal L2F Operations

•Debugging VPDN Events on the NAS—Normal L2TP Operations

•Debugging VPDN Events on the Tunnel Server—Normal L2TP Operations

•Debugging Protocol-Specific Events on the NAS—Normal L2F Operations

•Debugging Protocol-Specific Events on the Tunnel Server—Normal L2F Operations

•Displaying L2TP Congestion Avoidance Settings

•Debugging Errors on the NAS—L2F Error Conditions

•Debugging L2F Control Packets for Complete Information

•Debugging an L2TPv3 Xconnect Session—Normal Operations

•Debugging Control Channel Authentication Events

Debugging VPDN Events on a NAS—Normal L2F Operations

The network access server (NAS) has the following VPDN configuration:

vpdn-group 1

 request-dialin

  protocol l2f

  domain cisco.com

 initiate-to ip 172.17.33.125

username nas1 password nas1

The following is sample output from the debug vpdn event command on a NAS when an L2F tunnel is brought up and Challenge Handshake Authentication Protocol (CHAP) authentication of the tunnel succeeds:

Router# debug vpdn event

%LINK-3-UPDOWN: Interface Async6, changed state to up

*Mar 2 00:26:05.537: looking for tunnel -- cisco.com --

*Mar 2 00:26:05.545: Async6 VPN Forwarding...

*Mar 2 00:26:05.545: Async6 VPN Bind interface direction=1

*Mar 2 00:26:05.553: Async6 VPN vpn_forward_user user6@cisco.com is forwarded

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up

*Mar 2 00:26:06.289: L2F: Chap authentication succeeded for nas1.

The following is sample output from the debug vpdn event command on a NAS when the L2F tunnel is brought down normally:

Router# debug vpdn event

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down

%LINK-5-CHANGED: Interface Async6, changed state to reset

*Mar 2 00:27:18.865: Async6 VPN cleanup

*Mar 2 00:27:18.869: Async6 VPN reset

*Mar 2 00:27:18.873: Async6 VPN Unbind interface

%LINK-3-UPDOWN: Interface Async6, changed state to down

Table 1 describes the significant fields shown in the two previous displays. The output describes normal operations when an L2F tunnel is brought up or down on a NAS.

Table 1 debug vpdn event Field Descriptions for the NAS 

Field	Description
Asynchronous interface coming up
%LINK-3-UPDOWN: Interface Async6, changed state to up	Asynchronous interface 6 came up.
looking for tunnel -- cisco.com -- Async6 VPN Forwarding...	Domain name is identified.
Async6 VPN Bind interface direction=1	Tunnel is bound to the interface. These are the direction values: •1—From the NAS to the tunnel server •2—From the tunnel server to the NAS
Async6 VPN vpn_forward_user user6@cisco.com is forwarded	Tunnel for the specified user and domain name is forwarded.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up	Line protocol is up.
L2F: Chap authentication succeeded for nas1.	Tunnel was authenticated with the tunnel password nas1.
Virtual access interface coming down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down	Normal operation when the virtual access interface is taken down.
Async6 VPN cleanup Async6 VPN reset Async6 VPN Unbind interface	Normal cleanup operations performed when the line or virtual access interface goes down.

Debugging VPDN Events on the Tunnel Server—Normal L2F Operations

The tunnel server has the following VPDN configuration, which uses nas1 as the tunnel name and the tunnel authentication name. The tunnel authentication name might be entered in a user's file on an authentication, authorization, and accounting (AAA) server and used to define authentication requirements for the tunnel.

vpdn-group 1

 accept-dialin

  protocol l2f

  virtual-template 1

 terminate-from hostname nas1

The following is sample output from the debug vpdn event command on the tunnel server when an L2F tunnel is brought up successfully:

Router# debug vpdn event

L2F: Chap authentication succeeded for nas1.

Virtual-Access3 VPN Virtual interface created for user6@cisco.com

Virtual-Access3 VPN Set to Async interface

Virtual-Access3 VPN Clone from Vtemplate 1 block=1 filterPPP=0

%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

Virtual-Access3 VPN Bind interface direction=2

Virtual-Access3 VPN PPP LCP accepted sent & rcv CONFACK

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

The following is sample output from the debug vpdn event command on a tunnel server when an L2F tunnel is brought down normally:

Router# debug vpdn event

%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down

Virtual-Access3 VPN cleanup

Virtual-Access3 VPN reset

Virtual-Access3 VPN Unbind interface

Virtual-Access3 VPN reset

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down

Table 2 describes the fields shown in two previous outputs. The output describes normal operations when an L2F tunnel is brought up or down on a tunnel server.

Table 2 debug vpdn event Field Descriptions for the Tunnel Server 

Field	Description
Tunnel coming up
L2F: Chap authentication succeeded for nas1.	PPP CHAP authentication status for the tunnel named nas1.
Virtual-Access3 VPN Virtual interface created for user6@cisco.com	Virtual access interface was set up on the tunnel server for the user user6@cisco.com.
Virtual-Access3 VPN Set to Async interface	Virtual access interface 3 was set to asynchronous for character-by-character transmission.
Virtual-Access3 VPN Clone from Vtemplate 1 block=1 filterPPP=0	Virtual template 1 was applied to virtual access interface 3.
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up	Link status is set to up.
Virtual-Access3 VPN Bind interface direction=2	Tunnel is bound to the interface. These are the direction values: •1—From the NAS to the tunnel server •2—From the tunnel server to the NAS
Virtual-Access3 VPN PPP LCP accepted sent & rcv CONFACK	PPP link control protocol (LCP) configuration settings (negotiated between the remote client and the NAS) were copied to the tunnel server and acknowledged.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up	Line protocol is up; the line can be used.
Tunnel coming down
%LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down	Virtual access interface is coming down.
Virtual-Access3 VPN cleanup Virtual-Access3 VPN reset Virtual-Access3 VPN Unbind interface Virtual-Access3 VPN reset	Router is performing normal cleanup operations when a virtual access interface used for an L2F tunnel comes down.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down	Line protocol is down for virtual access interface 3; the line cannot be used.

Debugging VPDN Events on the NAS—Normal L2TP Operations

The following is sample output from the debug vpdn event command on the NAS when an L2TP tunnel is brought up successfully:

Router# debug vpdn event

20:19:17: L2TP: I SCCRQ from ts1 tnl 8

20:19:17: L2X: Never heard of ts1

20:19:17: Tnl 7 L2TP: New tunnel created for remote ts1, address 172.21.9.4

20:19:17: Tnl 7 L2TP: Got a challenge in SCCRQ, ts1

20:19:17: Tnl 7 L2TP: Tunnel state change from idle to wait-ctl-reply

20:19:17: Tnl 7 L2TP: Got a Challenge Response in SCCCN from ts1

20:19:17: Tnl 7 L2TP: Tunnel Authentication success

20:19:17: Tnl 7 L2TP: Tunnel state change from wait-ctl-reply to established

20:19:17: Tnl 7 L2TP: SM State established

20:19:17: Tnl/Cl 7/1 L2TP: Session FS enabled

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from idle to wait-for-tunnel

20:19:17: Tnl/Cl 7/1 L2TP: New session created

20:19:17: Tnl/Cl 7/1 L2TP: O ICRP to ts1 8/1

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-for-tunnel to wait-connect

20:19:17: Tnl/Cl 7/1 L2TP: Session state change from wait-connect to established

20:19:17: Vi1 VPDN: Virtual interface created for bum1@cisco.com

20:19:17: Vi1 VPDN: Set to Async interface

20:19:17: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking

20:19:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

20:19:18: Vi1 VPDN: Bind interface direction=2

20:19:18: Vi1 VPDN: PPP LCP accepting rcv CONFACK

20:19:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Debugging VPDN Events on the Tunnel Server—Normal L2TP Operations

The following is sample output from the debug vpdn event command on the tunnel server when an L2TP tunnel is brought up successfully:

Router# debug vpdn event

20:47:33: %LINK-3-UPDOWN: Interface Async7, changed state to up

20:47:35: As7 VPDN: Looking for tunnel -- cisco.com --

20:47:35: As7 VPDN: Get tunnel info for cisco.com with NAS nas1, IP 172.21.9.13

20:47:35: As7 VPDN: Forward to address 172.21.9.13

20:47:35: As7 VPDN: Forwarding...

20:47:35: As7 VPDN: Bind interface direction=1

20:47:35: Tnl/Cl 8/1 L2TP: Session FS enabled

20:47:35: Tnl/Cl 8/1 L2TP: Session state change from idle to wait-for-tunnel

20:47:35: As7 8/1 L2TP: Create session

20:47:35: Tnl 8 L2TP: SM State idle

20:47:35: Tnl 8 L2TP: Tunnel state change from idle to wait-ctl-reply

20:47:35: Tnl 8 L2TP: SM State wait-ctl-reply

20:47:35: As7 VPDN: bum1@cisco.com is forwarded

20:47:35: Tnl 8 L2TP: Got a challenge from remote peer, nas1

20:47:35: Tnl 8 L2TP: Got a response from remote peer, nas1

20:47:35: Tnl 8 L2TP: Tunnel Authentication success

20:47:35: Tnl 8 L2TP: Tunnel state change from wait-ctl-reply to established

20:47:35: Tnl 8 L2TP: SM State established

20:47:35: As7 8/1 L2TP: Session state change from wait-for-tunnel to wait-reply

20:47:35: As7 8/1 L2TP: Session state change from wait-reply to established

20:47:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async7, changed state to up

Debugging Protocol-Specific Events on the NAS—Normal L2F Operations

The following is sample output from the debug vpdn l2x-events command on the NAS when an L2F tunnel is brought up successfully:

Router# debug vpdn l2x-events

%LINK-3-UPDOWN: Interface Async6, changed state to up

*Mar 2 00:41:17.365: L2F Open UDP socket to 172.21.9.26

*Mar 2 00:41:17.385: L2F_CONF received

*Mar 2 00:41:17.389: L2F Removing resend packet (type 1)

*Mar 2 00:41:17.477: L2F_OPEN received

*Mar 2 00:41:17.489: L2F Removing resend packet (type 2)

*Mar 2 00:41:17.493: L2F building nas2gw_mid0

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up

*Mar 2 00:41:18.613: L2F_OPEN received

*Mar 2 00:41:18.625: L2F Got a MID management packet

*Mar 2 00:41:18.625: L2F Removing resend packet (type 2)

*Mar 2 00:41:18.629: L2F MID synced NAS/HG Clid=7/15 Mid=1 on Async6

The following is sample output from the debug vpdn l2x-events command on a NAS when an L2F tunnel is brought down normally:

Router# debug vpdn l2x-events

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down

%LINK-5-CHANGED: Interface Async6, changed state to reset

*Mar 2 00:42:29.213: L2F_CLOSE received

*Mar 2 00:42:29.217: L2F Destroying mid

*Mar 2 00:42:29.217: L2F Removing resend packet (type 3)

*Mar 2 00:42:29.221: L2F Tunnel is going down!

*Mar 2 00:42:29.221: L2F Initiating tunnel shutdown.

*Mar 2 00:42:29.225: L2F_CLOSE received

*Mar 2 00:42:29.229: L2F_CLOSE received

*Mar 2 00:42:29.229: L2F Got closing for tunnel 

*Mar 2 00:42:29.233: L2F Removing resend packet

*Mar 2 00:42:29.233: L2F Closed tunnel structure

%LINK-3-UPDOWN: Interface Async6, changed state to down

*Mar 2 00:42:31.793: L2F Closed tunnel structure

*Mar 2 00:42:31.793: L2F Deleted inactive tunnel

Table 3 describes the fields shown in the displays.

Table 3 debug vpdn l2x-events Field Descriptions—NAS 

Field	Descriptions
Tunnel coming up
%LINK-3-UPDOWN: Interface Async6, changed state to up	Asynchronous interface came up normally.
L2F Open UDP socket to 172.21.9.26	L2F opened a User Datagram Protocol (UDP) socket to the tunnel server IP address.
L2F_CONF received	L2F_CONF signal was received. When sent from the tunnel server to the NAS, an L2F_CONF indicates the tunnel server's recognition of the tunnel creation request.
L2F Removing resend packet (type ...)	Removing the resend packet for the L2F management packet. There are two resend packets that have different meanings in different states of the tunnel.
L2F_OPEN received	L2F_OPEN management message was received, indicating that the tunnel server accepted the NAS configuration of an L2F tunnel.
L2F building nas2gw_mid0	L2F is building a tunnel between the NAS and the tunnel server, using the multiplex ID (MID) MID0.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to up	Line protocol came up. Indicates whether the software processes that handle the line protocol regard the interface as usable.
L2F_OPEN received	L2F_OPEN management message was received, indicating that the tunnel server accepted the NAS configuration of an L2F tunnel.
L2F Got a MID management packet	MID management packets are used to communicate between the NAS and the tunnel server.
L2F MID synced NAS/HG Clid=7/15 Mid=1 on Async6	L2F synchronized the client IDs on the NAS and the tunnel server, respectively. A MID is assigned to identify this connection in the tunnel.
Tunnel coming down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async6, changed state to down	Line protocol came down. Indicates whether the software processes that handle the line protocol regard the interface as usable.
%LINK-5-CHANGED: Interface Async6, changed state to reset	Interface was marked as reset.
L2F_CLOSE received	NAS received a request to close the tunnel.
L2F Destroying mid	Connection identified by the MID is being taken down.
L2F Tunnel is going down!	Advisory message about impending tunnel shutdown.
L2F Initiating tunnel shutdown.	Tunnel shutdown has started.
L2F_CLOSE received	NAS received a request to close the tunnel.
L2F Got closing for tunnel	NAS began tunnel closing operations.
%LINK-3-UPDOWN: Interface Async6, changed state to down	Asynchronous interface was taken down.
L2F Closed tunnel structure	NAS closed the tunnel.
L2F Deleted inactive tunnel	Now-inactivated tunnel was deleted.

Debugging Protocol-Specific Events on the Tunnel Server—Normal L2F Operations

The following is sample output from the debug vpdn l2x-events command on a tunnel server when an L2F tunnel is created:

Router# debug vpdn l2x-events

L2F_CONF received

L2F Creating new tunnel for nas1

L2F Got a tunnel named nas1, responding

L2F Open UDP socket to 172.21.9.25

L2F_OPEN received

L2F Removing resend packet (type 1)

L2F_OPEN received

L2F Got a MID management packet

%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

The following is sample output from the debug vpdn l2x-events command on a tunnel server when the L2F tunnel is brought down normally:

Router# debug vpdn l2x-events

L2F_CLOSE received

L2F Destroying mid

L2F Removing resend packet (type 3)

L2F Tunnel is going down!

L2F Initiating tunnel shutdown.

%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down

L2F_CLOSE received

L2F Got closing for tunnel 

L2F Removing resend packet

L2F Removing resend packet

L2F Closed tunnel structure

L2F Closed tunnel structure

L2F Deleted inactive tunnel

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

Table 4 describes the significant fields shown in the displays.

Table 4 debug vpdn l2x-events Field Descriptions—Tunnel Server 

Field	Description
Tunnel coming up
L2F_CONF received	L2F configuration is received from the NAS. When sent from a NAS to a tunnel server, the L2F_CONF is the initial packet in the conversation.
L2F Creating new tunnel for nas1	Tunnel named nas1 is being created.
L2F Got a tunnel named nas1, responding	Tunnel server is responding.
L2F Open UDP socket to 172.21.9.25	Opening a socket to the NAS IP address.
L2F_OPEN received	L2F_OPEN management message was received, indicating the NAS is opening an L2F tunnel.
L2F Removing resend packet (type 1)	Removing the resend packet for the L2F management packet. The two resend packet types have different meanings in different states of the tunnel.
L2F Got a MID management packet	L2F MID management packets are used to communicate between the NAS and the tunnel server.
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up	Tunnel server is bringing up virtual access interface 1 for the L2F tunnel.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up	Line protocol is up. The line can be used.
Tunnel coming down
L2F_CLOSE received	NAS or tunnel server received a request to close the tunnel.
L2F Destroying mid	Connection identified by the MID is being taken down.
L2F Removing resend packet (type 3)	Removing the resend packet for the L2F management packet. There are two resend packets that have different meanings in different states of the tunnel.
L2F Tunnel is going down! L2F Initiating tunnel shutdown.	Router is performing normal operations when a tunnel is coming down.
%LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down	The virtual access interface is coming down.
L2F_CLOSE received L2F Got closing for tunnel L2F Removing resend packet L2F Removing resend packet L2F Closed tunnel structure L2F Closed tunnel structure L2F Deleted inactive tunnel	Router is performing normal cleanup operations when the tunnel is being brought down.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down	Line protocol is down; virtual access interface 1 cannot be used.

Displaying L2TP Congestion Avoidance Settings

The following partial example of the debug vpdn l2x-events command is useful for monitoring a network running the L2TP Congestion Avoidance feature. The report shows that the congestion window (CWND) window has been reset to 1 because of packet retransmissions:

Router# debug vpdn l2x-events

.

.

.

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Congestion Control event received is retransmission

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Congestion Window size, Cwnd 1

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Slow Start threshold, Ssthresh 2

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Remote Window size, 500

*Jul 15 19:02:57.963:  Tnl 47100 L2TP: Control channel retransmit delay set to 4 seconds

*Jul 15 19:03:01.607:  Tnl 47100 L2TP: Update ns/nr, peer ns/nr 2/5, our ns/nr 5/2

The following partial example shows that traffic has been restarted with L2TP congestion avoidance throttling traffic:

Router# debug vpdn l2x-events

.

.

.

*Jul 15 14:45:16.123:  Tnl 30597 L2TP: Control channel retransmit delay set to 2 seconds

*Jul 15 14:45:16.123:  Tnl 30597 L2TP: Tunnel state change from idle to wait-ctl-reply

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Control event received is positive 
acknowledgement

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Window size, Cwnd 2

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Slow Start threshold, Ssthresh 500

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Remote Window size, 500

*Jul 15 14:45:16.131:  Tnl 30597 L2TP: Congestion Ctrl Mode is Slow Start

Table 5 briefly describes the sigificant fields shown in the displays. See RFC 2661 for more details about the information in the reports for L2TP congestion avoidance.

Table 5 debug vpdn l2x-events Field Descriptions—L2TP Congestion Avoidance

Field	Description
Control channel retransmit delay set to ...	Indicates the current value set for the retransmit delay.
Tunnel state...	Indicates the tunnel's current Control Connection State, per RFC 2661.
Congestion Control event received is...	Indicates the received congestion control event. •Retransmission—Indicates packet retransmission has been detected in the resend queue. •Positive acknowledgement—Indicates that a packet was received and acknowledged by the peer tunnel endpoint.
Congestion Window size, Cwnd 2	Current size of the congestion window (Cwnd).
Slow Start threshold, Ssthresh 500	Current value of the slow start threshold (Ssthresh).
Remote Window size, 500	Size of the advertised receive window configured on the remote peer with the l2tp tunnel receive-window command.
Congestion Ctrl Mode is...	Indicates if the router is operating in Slow Start or Congestion Avoidance mode.
Update ns/nr, peer ns/nr 2/5, our ns/nr 5/2	See RFC 2661.

Debugging Errors on the NAS—L2F Error Conditions

The following is sample output from the debug vpdn error command on a NAS when the L2F tunnel is not set up:

Router# debug vpdn error

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to down

%LINK-5-CHANGED: Interface Async1, changed state to reset

%LINK-3-UPDOWN: Interface Async1, changed state to down

%LINK-3-UPDOWN: Interface Async1, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up

VPDN tunnel management packet failed to authenticate

VPDN tunnel management packet failed to authenticate

Table 6 describes the significant fields shown in the display.

Table 6 debug vpdn error Field Descriptions for the NAS 

Field	Description
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to down	Line protocol on the asynchronous interface went down.
%LINK-5-CHANGED: Interface Async1, changed state to reset	Asynchronous interface 1 was reset.
%LINK-3-UPDOWN: Interface Async1, changed state to down %LINK-3-UPDOWN: Interface Async1, changed state to up	Link from asynchronous interface 1 link went down and then came back up.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up	Line protocol on the asynchronous interface came back up.
VPDN tunnel management packet failed to authenticate	Tunnel authentication failed. This is the most common VPDN error. Note Verify the password for the NAS and the tunnel server name. If you store the password on an AAA server, you can use the debug aaa authentication command.

The following is sample output from the debug vpdn l2x-errors command:

Router# debug vpdn l2x-errors

%LINK-3-UPDOWN: Interface Async1, changed state to up

L2F Out of sequence packet 0 (expecting 0)

L2F Tunnel authentication succeeded for cisco.com

 L2F Received a close request for a non-existent mid

 L2F Out of sequence packet 0 (expecting 0)

 L2F packet has bogus1 key 1020868 D248BA0F

L2F packet has bogus1 key 1020868 D248BA0F

Table 7 describes the significant fields shown in the display.

Table 7 debug vpdn l2x-errors Field Descriptions 

Field	Description
%LINK-3-UPDOWN: Interface Async1, changed state to up	The line protocol on the asynchronous interface came up.
L2F Out of sequence packet 0 (expecting 0)	Packet was expected to be the first in a sequence starting at 0, but an invalid sequence number was received.
L2F Tunnel authentication succeeded for cisco.com	Tunnel was established from the NAS to the tunnel server, cisco.com.
L2F Received a close request for a non-existent mid	Multiplex ID was not used previously; cannot close the tunnel.
L2F Out of sequence packet 0 (expecting 0)	Packet was expected to be the first in a sequence starting at 0, but an invalid sequence number was received.
L2F packet has bogus1 key 1020868 D248BA0F	Value based on the authentication response given to the peer during tunnel creation. This packet, in which the key does not match the expected value, must be discarded.
L2F packet has bogus1 key 1020868 D248BA0F	Another packet was received with an invalid key value. The packet must be discarded.

Debugging L2F Control Packets for Complete Information

The following is sample output from the debug vpdn l2x-packets command on a NAS. This example displays a trace for a ping command.

Router# debug vpdn l2x-packets

L2F SENDING (17): D0 1 1 10 0 0 0 4 0 11 0 0 81 94 E1 A0 4

L2F header flags: 53249 version 53249 protocol 1 sequence 16 mid 0 cid 4

length 17 offset 0 key 1701976070

L2F RECEIVED (17): D0 1 1 10 0 0 0 4 0 11 0 0 65 72 18 6 5

L2F SENDING (17): D0 1 1 11 0 0 0 4 0 11 0 0 81 94 E1 A0 4

L2F header flags: 53249 version 53249 protocol 1 sequence 17 mid 0 cid 4

length 17 offset 0 key 1701976070

L2F RECEIVED (17): D0 1 1 11 0 0 0 4 0 11 0 0 65 72 18 6 5

L2F header flags: 57345 version 57345 protocol 2 sequence 0 mid 1 cid 4

length 32 offset 0 key 1701976070

L2F-IN Output to Async1 (16): FF 3 C0 21 9 F 0 C 0 1D 41 AD FF 11 46 87

L2F-OUT (16): FF 3 C0 21 A F 0 C 0 1A C9 BD FF 11 46 87

L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4

length 32 offset 0 key -2120949344

L2F-OUT (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 3 1 0 0 1 8 0 62 B1

0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD

AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB

CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD

L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4

length 120 offset 3 key -2120949344

L2F header flags: 49153 version 49153 protocol 2 sequence 0 mid 1 cid 4

length 120 offset 3 key 1701976070

L2F-IN Output to Async1 (101): 21 45 0 0 64 0 10 0 0 FF 1 B9 85 1 0 0 1 1 0

0 3 0 0 6A B1 0 0 C A8 0 0 0 0 0 11 E E0 AB CD AB CD AB CD AB CD AB CD AB CD

AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB

CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD AB CD

Table 8 describes the significant fields shown in the display.

Table 8 debug vpdn l2x-packets Field Descriptions 

Field	Description
L2F SENDING (17)	Number of bytes being sent. The first set of "SENDING"..."RECEIVED" lines displays L2F keepalive traffic. The second set displays L2F management data.
L2F header flags:	Version and flags, in decimal.
version 53249	Version.
protocol 1	Protocol for negotiation of the point-to-point link between the NAS and the tunnel server is always 1, indicating L2F management.
sequence 16	Sequence numbers start at 0. Each subsequent packet is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 256. There is a distinct sequence counter for each distinct MID value.
mid 0	MID, which identifies a particular connection within the tunnel. Each new connection is assigned a MID currently unused within the tunnel.
cid 4	Client ID used to assist endpoints in demultiplexing tunnels.
length 17	Size in octets of the entire packet, including header, all fields pre-sent, and payload. Length does not reflect the addition of the checksum, if pre-sent.
offset 0	Number of bytes past the L2F header at which the payload data is expected to start. If it is 0, the first byte following the last byte of the L2F header is the first byte of payload data.
key 1701976070	Value based on the authentication response given to the peer during tunnel creation. During the life of a session, the key value serves to resist attacks based on spoofing. If a packet is received in which the key does not match the expected value, the packet must be silently discarded.
L2F RECEIVED (17)	Number of bytes received.
L2F-IN Otput to Async1 (16)	Payload datagram. The data came in to the VPDN code.
L2F-OUT (16):	Payload datagram sent out from the VPDN code to the tunnel.
L2F-OUT (101)	Ping payload datagram. The value 62 in this line is the ping packet size in hexadecimal (98 in decimal). The three lines that follow this line show ping packet data.

Debugging an L2TPv3 Xconnect Session—Normal Operations

The following example shows output from the debug vpdn l2x-events command for an L2TP version 3 (L2TPv3) xconnect session on an Ethernet interface:

Router# debug vpdn l2x-events

23:31:18: L2X: l2tun session [1669204400], event [client request], old state [open], new 
state [open] 

 23:31:18: L2X: L2TP: Received L2TUN message <Connect> 

 23:31:18: Tnl/Sn58458/28568 L2TP: Session state change from idle to wait-for-tunnel 

 23:31:18: Tnl/Sn58458/28568 L2TP: Create session 

 23:31:18: Tnl58458 L2TP: SM State idle 

 23:31:18: Tnl58458 L2TP: O SCCRQ 

 23:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds 

 23:31:18: Tnl58458 L2TP: Tunnel state change from idle to wait-ctl-reply 

 23:31:18: Tnl58458 L2TP: SM State wait-ctl-reply 

 23:31:18: Tnl58458 L2TP: I SCCRP from router

 23:31:18: Tnl58458 L2TP: Tunnel state change from wait-ctl-reply to established 

 23:31:18: Tnl58458 L2TP: O SCCCN to router tnlid 8012 

 23:31:18: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds 

 23:31:18: Tnl58458 L2TP: SM State established 

 23:31:18: Tnl/Sn58458/28568 L2TP: O ICRQ to router 8012/0 

 23:31:18: Tnl/Sn58458/28568 L2TP: Session state change from wait-for-tunnel to wait-reply 

 23:31:19: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds 

 23:31:20: %LINK-3-UPDOWN: Interface Ethernet2/1, changed state to up 

 23:31:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet2/1, changed state to 
up 

 23:31:25: L2X: Sending L2TUN message <Connect OK> 

 23:31:25: Tnl/Sn58458/28568 L2TP: O ICCN to router 8012/35149 

 23:31:25: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds 

 23:31:25: Tnl/Sn58458/28568 L2TP: Session state change from wait-reply to established 

 23:31:25: L2X: l2tun session [1669204400], event [server response], old state [open], new 
state [open] 

 23:31:26: Tnl58458 L2TP: Control channel retransmit delay set to 1 seconds 

Debugging Control Channel Authentication Events

The following debug messages show control channel authentication failure events in Cisco IOS Release 12.0(31)S:

Router# debug vpdn l2x-events

!

Tnl41855 L2TP: Per-Tunnel auth counter, Overall Failed, now 1

Tnl41855 L2TP: Tunnel auth counter, Overall Failed, now 219

!

Related Commands

Command	Description
debug aaa authentication	Displays information on AAA/TACACS+ authentication.
debug acircuit	Displays events and failures related to attachment circuits.
debug pppoe	Display debugging information for PPPoE sessions.
debug vpdn pppoe-data	Displays data packets of PPPoE sessions.
debug vpdn pppoe-error	Displays PPPoE protocol errors that prevent a session from being established or errors that cause an established sessions to be closed.
debug vpdn pppoe-events	Displays PPPoE protocol messages about events that are part of normal session establishment or shutdown.
debug vpdn pppoe-packet	Displays each PPPoE protocol packet exchanged.
debug xconnect	Displays errors and events related to an xconnect configuration.

l2tp congestion-control

To enable Layer 2 Transport Protocol (L2TP) congestion avoidance, use the l2tp congestion-control command in global configuration mode. To disable L2TP congestion avoidance (default state), use the no form of this command.

l2tp congestion-control

no l2tp congestion-control

Syntax Description

This command has no arguments or keywords.

Command Default

L2TP congestion avoidance is disabled.

Command Modes

Global configuration

Command History

Release	Modification
12.2(28)SB	This command was introduced.
12.4(15)T	This command was integrated into Cisco IOS Release 12.4(15)T and support was added for L2TP congestion avoidance statistics.

Usage Guidelines

The l2tp congestion-control command operates as a user-controlled on-off switch. An L2TP sliding window mechanism is enabled or disabled by this command, but only for those tunnels that come up after the configuration has been applied. In other words, tunnels that exist when the l2tp congestion-control command is enabled remain unaffected by the command. The reason for this is to avoid a situation where the the sliding window mechanism is enabled at a point in transmissions where the existing size of the resend queue is much larger than the congestion window. It is not desirable, nor is there a reason, for the configuration to have to apply to all L2TP tunnels.

The congestion window size is not allowed to exceed the size of the advertised window obtained from the receive window size set by the l2tp tunnel receive-window VPDN group configuration command. Lowering the value of the receive window will result in lowering the number of calls per second being negotiated, and if a network is congested, the receive window size should be lowered. Increasing this value depends on how congested the network is. When the network becomes less congested, the receive window size can be increased again.

Examples

The following example enables L2TP congestion avoidance:

Router(config)# l2tp congestion-control

Related Commands

Command	Description
l2tp tunnel receive-window	Specifies the size of the advertised receive window.

show vpdn tunnel

To display information about active Layer 2 tunnels for a virtual private dialup network (VPDN), use the show vpdn tunnel command in privileged EXEC mode.

show vpdn tunnel [l2f | l2tp | pptp] [all [filter] | packets [filter] | state [filter] | summary [filter] | transport [filter]]

Syntax Description

l2f	(Optional) Specifies that only information about Layer 2 Forwarding (L2F) tunnels will be displayed.
l2tp	(Optional) Specifies that only information about Layer 2 Tunnel Protocol (L2TP) tunnels will be displayed.
pptp	(Optional) Specifies that only information about Point-to-Point Tunnel Protocol (PPTP) tunnels will be displayed.
all	(Optional) Displays summary information about all active tunnels.
filter	(Optional) One of the filter parameters defined in Table 9.
packets	(Optional) Displays packet numbers and packet byte information.
state	(Optional) Displays state information for a tunnel.
summary	(Optional) Displays a summary of tunnel information.
transport	(Optional) Displays tunnel transport information.

Command Modes

Privileged EXEC

Command History

Release	Modification
11.2	This command was introduced.
12.1(1)T	Support was added for the packets and all keywords.
12.3(2)T	Support was added for the l2f, l2tp, and pptp keywords.
12.2(28)SB	This command was integrated into Cisco IOS Release 12.2(28)SB and support was added for L2TP congestion avoidance statistics.

Usage Guidelines

Use the show vpdn tunnel command to display detailed information about L2TP, L2F, and PPTP VPDN tunnels.

Table 9 defines the filter parameters available to refine the output of the show vpdn tunnel command. You may use any one of the filter parameters in place of the filter argument.

Table 9 Filter Parameters for the show vpdn tunnel Command

Syntax	Description
id local-id	Filters the output to display only information for the tunnel with the specified local ID. •local-id—The local tunnel ID number. Valid values range from 1 to 65535.
local-name local-name remote-name	Filters the output to display only information for the tunnel associated with the specified names. •local-name—The local tunnel name. •remote-name—The remote tunnel name.
remote-name remote-name local-name	Filters the output to display only information for the tunnel associated with the specified names. •remote-name—The remote tunnel name. •local-name—The local tunnel name.

Examples

The following is sample output from the show vpdn tunnel command for L2F and L2TP sessions:

Router# show vpdn tunnel

L2TP Tunnel Information (Total tunnels=1 sessions=1)

LocID RemID Remote Name   State  Remote Address  Port  Sessions

2     10    router1       est    172.21.9.13     1701  1 

L2F Tunnel

 NAS CLID HGW CLID NAS Name        HGW Name        State

 9         1        nas1           HGW1            open   

                    172.21.9.4      172.21.9.232 

%No active PPTP tunnels

Table 10 describes the significant fields shown in the display.

Table 10 show vpdn tunnel Field Descriptions 

Field	Description
LocID	Local tunnel identifier.
RemID	Remote tunnel identifier.
Remote Name	Hostname of the remote peer.
State	Status for the individual user in the tunnel; can be one of the following states: •est •opening •open •closing •closed •waiting_for_tunnel The waiting_for_tunnel state means that the user connection is waiting until the main tunnel can be brought up before it moves to the opening state.
Remote address	IP address of the remote peer.
Port	Port ID.
Sessions	Number of sessions using the tunnel.
NAS CLID	A number uniquely identifying the VPDN tunnel on the network access server (NAS).
HGW CLID	A number uniquely identifying the VPDN tunnel on the gateway.
NAS Name	Hostname and IP address of the NAS.
HGW Name	Hostname and IP address of the home gateway.

The following example shows L2TP tunnel activity, including information about the L2TP congestion avoidance:

Router# show vpdn tunnel l2tp all

L2TP Tunnel Information Total tunnels 1 sessions 1

Tunnel id 30597 is up, remote id is 45078, 1 active sessions

  Tunnel state is established, time since change 00:08:27

  Tunnel transport is UDP (17)

  Remote tunnel name is LAC1

    Internet Address 172.18.184.230, port 1701

  Local tunnel name is LNS1

    Internet Address 172.18.184.231, port 1701

  Tunnel domain unknown

  VPDN group for tunnel is 1

  L2TP class for tunnel is 

  4 packets sent, 3 received

  194 bytes sent, 42 received

  Last clearing of "show vpdn" counters never

  Control Ns 2, Nr 4

  Local RWS 500, Remote RWS 500

  Control channel Congestion Control is enabled

    Congestion Window size, Cwnd 3

    Slow Start threshold, Ssthresh 500

    Mode of operation is Slow Start

  Tunnel PMTU checking disabled

  Retransmission time 1, max 2 seconds

  Unsent queuesize 0, max 0

  Resend queuesize 0, max 1

  Total resends 0, ZLB ACKs sent 2

  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

  Control message authentication is disabled

Table 11 describes the significant fields shown in the display.

Table 11 show vpdn tunnel all Field Descriptions

Field	Description
Local RWS	Size of the locally configured recieve window.
Remote RWS	Size of the receive window configured on the remote peer.
Congestion Window size, Cwnd 3	Current size of the congestion window (Cwnd).
Slow Start threshold, Ssthresh 500	Current value of the slow start threshold (Ssthresh).
Mode of operation is...	Indicates if the router is operating in Slow Start or Congestion Avoidance mode.

Related Commands

Command	Description
show vpdn	Displays basic information about all active VPDN tunnels.
show vpdn domain	Displays all VPDN domains and DNIS groups configured on the NAS.
show vpdn group	Displays a summary of the relationships among VPDN groups and customer/VPDN profiles, or summarizes the configuration of a VPDN group including DNIS/domain, load sharing information, and current session information.
show vpdn history failure	Displays the content of the failure history table.
show vpdn multilink	Displays the multilink sessions authorized for all VPDN groups.
show vpdn redirect	Displays statistics for L2TP redirects and forwards.
show vpdn session	Displays session information about active Layer 2 sessions for a VPDN.

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007 Cisco Systems, Inc. All rights reserved.