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.

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 debugvpdn command in privileged EXEC mode. To disable debugging output, use the no form of this command.

Command Modes

Command History

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.

%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:

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:

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:

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.

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.

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.