Guest

Cisco IOS Software Releases 12.2 SB

L2TP Congestion Avoidance

  • Viewing Options

  • PDF (531.9 KB)
  • Feedback
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.