Session and Tunnel Scalability

Note For supported scalability numbers and the recommended parameter values for achieving those numbers, see the "Important Notes" section of the Cisco 6400 Release Notes.

This chapter includes the following sections:

Recommendations

Memory

See the Cisco 6400 Release Notes for memory recommendations.

Image Versions

Make sure that the NSP and NRP simultaneously run the same software release version.

System and Console Logging

Disable logging to the console terminal by using the no logging console global configuration command:

Router(config)# no logging console

Also, log messages to an internal buffer by using the logging buffered buffer-size global configuration command. Choose a buffer size appropriate for the available memory and volume of messages logged on your systems:

Router(config)# logging buffered 131072

For more information on system and console logging, see the "Redirecting debug and error message Output" section of the "Using Debug Commands" chapter of the Cisco IOS Debug Command Reference.

Restrictions

Precloning

For the NRP-1 using 128 MB of DRAM, the total number of precloned interfaces must not exceed 3000.

IP QoS

Downloading policing parameters from a AAA server might reduce the number of PPP sessions that can be established per second. See the Cisco 6400 Release Notes for details.

Input and Output Hold-Queues

The input and output hold-queue limits determine the maximum number of incoming and outgoing control packets that the queue can accommodate. The default input and output hold-queue limits depend on the NRP type (see Table 6-1).

Table 6-1: Default Input and Output Hold-Queue Limits

NRP Type	Default Input Hold-Queue Limit	Default Output Hold-Queue Limit
NRP-1	75 packets	80 packets
NRP-2	75 packets	40 packets

Tips If the show interfaces EXEC command reveals an excessive number of discarded packets due to input or output hold-queue overflows, increase the appropriate hold-queue limit.

Configuring the Input or Output Hold-Queue Limit

To modify the input or output hold-queue limit, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# interface atm 0/0/0`	Selects the ATM interface.
Step 2	`Router(config-if)# hold-queue length {in \| out}`	Specifies the maximum number of packets in the input or output hold-queue. See Table 6-1 for default values.

Verifying the Input and Hold-Queue Limits

To display the current hold-queue limits and the number of packets discarded because of hold-queue overflows, use the show interface atm 0/0/0 EXEC command.

Example: Verifying the Input and Output Hold-Queue Limits

In the following example, the NRP-2 input and output hold-queue limits are set to 4096 packets:

Router# show interface atm 0/0/0

ATM0/0/0 is up, line protocol is up 
  Hardware is NRP2 ATM SAR
  MTU 1900 bytes, sub MTU 1900, BW 599040 Kbit, DLY 60 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ATM, loopback not supported 
  Keepalive not supported 
  Encapsulation(s):AAL5
  16384 maximum active VCs, 2048 VCs per VP, 4002 current VCCs
  VC idle disconnect time:300 seconds
  0 carrier transitions
  Last input never, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy:fifo
  
  Output queue 0/4096, 0 drops; input queue 0/4096, 0 drops
  30 second input rate 29000 bits/sec, 213 packets/sec
  30 second output rate 28000 bits/sec, 253 packets/sec
     35846 packets input, 672141 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     81291 packets output, 1110355 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
Router#

LCP Session Initiations

The first phase of PPP, Link Control Protocol (LCP), is responsible for establishing, configuring, testing, maintaining, and terminating the PPP data-link connection. By default, the NRP does not limit the number of simultaneous LCP session initiations. When a large number of PPP sessions start at the same time (due to an NRP reload or an ATM interface reset), the numerous LCP requests can cause a spike in the CPU utilization. If the CPU is unable to service all the LCP requests simultaneously, LCP sessions begin to timeout and renegotiate. This can result in a chain reaction of LCP session negotiations and excessive session recovery times. The chain reaction can be controlled by limiting the number of simultaneous LCP session initiations.

Limiting the Number of Simultaneous LCP Session Initiations

Note Only follow this procedure if the NRP has problems recovering after a reload or link dropout.

To limit the number of simultaneous LCP session initiations, enter the following commands in global configuration mode:

Command	Purpose
`Router(config)# lcp max-session-starts number`	Specifies the maximum number of simultaneous LCP sessions to be negotiated. Value must be between 100 and 3000 sessions.
`Router(config)# lcp max-load-metric number`	Specifies the maximum load metric, which determines the PPP manager process input queue length beyond which the NRP stops accepting new PPP LCP sessions.

Note The nominal values depend on many factors. Check the "Important Notes" section of the Cisco 6400 Release Notes for recommended values to use as a starting point. Try several numbers and select the combination that results in the shortest session recovery time after a link dropout.

Verifying the Simultaneous LCP Session Initiation Limit

To check the configured load metric and LCP session initiation limits, use the show running-config EXEC command.

PPP Timeouts

The PPP authentication timeout determines how long the system waits for a response from the remote peer before retransmitting one of the following packets:

Password Authentication Protocol (PAP) authentication request
Challenge Handshake Authentication Protocol (CHAP) challenge
CHAP response

The PPP retry timeout determines how long the PPP state machine (for LCP and all NCP's) waits for a response from the remote peer before retransmitting one of the following packets:

Configuration request
Connection termination request

The default PPP authentication timeout is 10 seconds, and the default PPP retry timeout is 2 seconds. By modifying these values, you can help to optimize the number of stable PPP sessions.

Configuring the PPP Timeouts

To modify the PPP timeouts, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# interface virtual-template number`	Selects or creates the virtual template interface and enters interface configuration mode.
Step 2	`Router(config-if)# ppp timeout authentication seconds`	0 - 255. Specifies the PPP authentication timeout, in seconds. Default is 10 seconds.
Step 3	`Router(config-if)# ppp timeout retry seconds`	1 - 255. Specifies the PPP retry timeout, in seconds. Default is 2 seconds.

Note The nominal value depends on many factors. Check the "Important Notes" section of the Cisco 6400 Release Notes for recommended values to use as a starting point. Try several values and select the combination that results in the highest number of stable sessions.

Verifying the PPP Timeouts

To check the configured PPP authentication and retry timeouts, use the show running-config EXEC command.

Keepalives

You can configure the keepalive interval, which is the frequency at which the Cisco IOS software sends messages to ensure that a network interface or L2TP tunnel is alive. By default, the interface keepalive is 10 seconds, and the L2TP tunnel keepalive is 60 seconds. An interface is declared down after the fourth successive keepalive is sent without an echo reply.

The L2TP tunnel keepalive timers do not have to use the same value on both sides of the tunnel. For example, a LAC can use a keepalive value of 30 seconds, and an LNS can use the default value of 60 seconds.

A high interface keepalive interval is required when scaling up your session count. As rough examples, a value around 120 seconds may be best for an NRP-1 with 2000 sessions, while 200 seconds may be best for an NRP-2 with 8000 sessions. See the Cisco 6400 Release Notes for specific recommended values.

Keepalive interval configuration consists of the following tasks:

Configuring the Interface Keepalive Interval

To configure the interface keepalive interval, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# interface virtual-template number`	Selects or creates the virtual template interface and enters interface configuration mode.
Step 2	`Router(config-if)# keepalive [seconds]`	Sets the keepalive timer. Default is 10 seconds.

Verifying the Interface Keepalive Interval

To verify the interface keepalive interval, use the show interface virtual-template EXEC command.

Example: Verifying the Interface Keepalive Interval

In the following example, the interface keepalive interval is set to 200 seconds:

Router# show interface virtual-template 1

Virtual-Template1 is down, line protocol is down 
  Hardware is Virtual Template interface
  Interface is unnumbered. Using address of GigabitEthernet0/0/0 (10.24.24.1)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, loopback not set
  Keepalive set (200 sec)
  DTR is pulsed for 5 seconds on reset
  LCP Closed
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 02:11:27
  Queueing strategy:fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
Router#

Configuring the L2TP Tunnel Keepalive Interval

To configure the L2TP tunnel keepalive interval, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# vpdn-group number`	Selects the VPDN group.
Step 2	`Router(config-vpdn)# l2tp tunnel hello hello-interval`	The interval, in seconds, that the LAC and LNS wait before sending the next L2TP tunnel keepalive packet. Default is 60 seconds.

Verifying the L2TP Tunnel Keepalive Interval

To verify the L2TP tunnel keepalive interval, use the show running-config EXEC command.

Virtual Access Interface Precloning

Precloning (or allocating) virtual access interfaces when you start the system reduces the load on the system during call setup. Precloning is required to optimize scalability on:

Network access server (NAS)—PPPoE terminated
LAC and LNS—PPPoE/L2TP

LNS—PPPoA/L2TP

Note Do not use precloning with PPPoA terminated.

Note The precloning operation might take a long time to complete (on the order of minutes for a large number of interfaces). Avoid incoming calls at the LNS until precloning is finished. You can monitor the precloning operation with the show vtemplate privileged EXEC command.

Precloning Virtual Access Interfaces

To preclone a virtual access interface, enter the following command in global configuration mode.

Command	Purpose
`Router(config)# virtual-template template-number pre-clone number`	Specifies the number of virtual access interfaces to be created and cloned from a specific virtual template.

Verifying the Precloned Virtual Access Interfaces

To check the successful precloning of virtual access interfaces, enter the privileged EXEC command show vtemplate. In the following example, precloning is on for Virtual-Template 1, 250 virtual access interfaces have been precloned, and 249 virtual access interfaces are available for new L2TP sessions. Only one virtual access interface is in use by L2TP, and no virtual access interfaces were cloned during call setup.

Router# show vtemplate

 
 Virtual-Template 1, pre-cloning is on
  Pre-clone limit: 250, current number: 249
  Active vaccess number: 1
 
 Generic free vaccess number:0

L2TP Control Channel Parameters

By default, the NRP attempts 10 L2TP control channel retransmissions that follow an exponential backoff (such as 1, 2, 4, 8, 8, 8 seconds), starting at the minimum retransmission timeout (1 second by default), and ending at the maximum retransmission timeout (8 seconds by default).

To determine the best minimum and maximum retransmission timeouts for a given topology, enter the privileged EXEC command show vpdn tunnel all. Check the displayed retransmit time distribution:

Retransmit time distribution: 0 0 0 0 1 0 0 0 1

Each value corresponds to the number of retransmissions at 0, 1, 2,..., 8 seconds, respectively, displaying a histogram of all tunnel retransmission times.

The local control channel receive window size (RWS) determines how many incoming control messages can be acknowledged and waiting on the recipient's queue, instead of waiting on the peer's queue. Large values enable the NRP to open PPP sessions more quickly. The default local RWS is 3000 packets, which allows the L2TP control channel to send requests as fast as possible.

By improving L2TP control channel processing, the following tasks can provide resilience to dropouts between the LAC and the LNS:

Configuring the Control Channel Retransmission Parameters

To configure the L2TP control channel retransmission parameters, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# vpdn-group number`	Selects the VPDN group.
Step 2	`Router(config-vpdn)# l2tp tunnel retransmit retries value`	Specifies the number of control channel retransmission attempts. Default is 10 retries.
Step 3	`Router(config-vpdn)# l2tp tunnel retransmit timeout min seconds`	Specifies the minimum timeout for control channel retransmissions. Default is 1 second.
Step 4	`Router(config-vpdn)# l2tp tunnel retransmit timeout max seconds`	Specifies the maximum timeout (up to 8 seconds) for control channel retransmissions. Default is 8 seconds.

Verifying the Control Channel Retransmission Parameters

To check the configured L2TP control channel retransmission parameters, enter the show running-config EXEC command.

To check general control channel retransmission parameters, enter the show vpdn tunnel all privileged EXEC command.

Configuring the Local Control Channel Receive Window Size

To configure the local control channel RWS, enter the following commands beginning in global configuration mode:

	Command	Purpose
Step 1	`Router(config)# vpdn-group number`	Selects the VPDN group.
Step 2	`Router(config-vpdn)# l2tp tunnel receive-window packets`	Specifies the size of advertised receive window. Default is 3000 packets.
Step 3	`Router(config-vpdn)# exit`	Returns to global configuration mode.
Step 4	`Router(config)# end`	Returns to privileged EXEC mode.
Step 5	`Router# clear vpdn tunnel l2tp remote-name local-name`	Clears all sessions and drops the tunnel.

Verifying the Local Control Channel Receive Window Size

To display the local control channel RWS, use the show vpdn tunnel all privileged EXEC command.

Router# show vpdn tunnel all

 
 L2TP Tunnel Information (Total tunnels=1 sessions=500)
 
 Tunnel id 20 is up, remote id is 12, 500 active sessions
   Tunnel state is established, time since change 00:00:33
   Remote tunnel name is LAC
     Internet Address 10.1.1.1, port 1701
   Local tunnel name is LNS
     Internet Address 10.1.1.2, port 1701
   971 packets sent, 1259 received, 19892 bytes sent, 37787 received
   Control Ns 501, Nr 746
  
   Local RWS 3000 (default), Remote RWS 3000 (max)
   Retransmission time 4, max 8 seconds
   Unsent queuesize 0, max 0
   Resend queuesize 251, max 261
   Total resends 390, ZLB ACKs 251
   Current nosession queue check 0 of 5
   Retransmit time distribution: 0 0 0 0 1 0 0 0 1 
   Sessions disconnected due to lack of resources 0

L2TP Tunnel Timeout

The tunnel timeout determines how long a tunnel lingers after all its sessions are gone. The default tunnel timeout is 10 seconds for an LNS and 15 seconds for a LAC. Configuring a longer tunnel timeout is useful:

After all the tunnel sessions are gone and you expect sessions to come back immediately.
If you plan to examine the tunnel status after the sessions have ended.

Configuring the L2TP Tunnel Timeout

To configure the L2TP tunnel timeout, enter the following commands beginning in global configuration mode.

	Command	Purpose
Step 1	`Router(config)# vpdn-group number`	Selects the VPDN group.
Step 2	`Router(config-vpdn)# l2tp tunnel nosession-timeout seconds`	Specifies the tunnel timeout length. LNS default is 10 seconds, and LAC default is 15 seconds.

Verifying the L2TP Tunnel Timeout

To check the configured tunnel timeout, use the show running-config EXEC command.

An Example Configuration of Session and Tunnel Scalability Parameters

For general L2TP configuration examples, see the Layer 2 Tunnel Protocol feature module and the "Configuring Virtual Private Networks" chapter in the "Virtual Templates, Profiles, and Networks" part of the Cisco IOS Dial Technologies Configuration Guide.

The following example shows a configuration implementing the session and tunnel scalability optimization commands described in this chapter.The input hold queue limit on an ATM interface is set to 1200, and virtual template 1 is used to preclone 2000 virtual access interfaces. VPDN group 1 is set to use 7 retransmission attempts, with the retransmission timeouts beginning at 2 seconds and ending at 4 seconds. The L2TP tunnel timeout is set to 10 seconds. The local RWS is set to 500 packets. The number of simultaneous LCP session initiations are limited to 100, and the load metric is limited to 100. Both the PPP authentication and retry timeouts are set to 15 seconds.

!
vpdn enable
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate from hostname LAC1
 local name LNS1
 l2tp tunnel receive-window 500
 l2tp tunnel nosession-timeout 10
 l2tp tunnel retransmit retries 7
 l2tp tunnel retransmit timeout min 2
 l2tp tunnel retransmit timeout max 4
!
!
virtual-template 1 pre-clone 2000
!
interface ATM 0/0/0
 hold-queue 1200 in
!
interface FastEthernet 0/0/0
 ip address negotiated
 no ip directed-broadcast
!
interface Virtual-Template 1
 ip unnumbered FastEthernet 0/0/0
 no ip directed-broadcast
 no logging event link-status
 no keepalive
 peer default ip address pool pool-1
 ppp authentication chap
 ppp timeout retry 15
 ppp timeout authentication 15
!
lcp max-session-starts 100
lcp max-load-metric 100
!

Monitoring and Troubleshooting PPP Scalability

Use the following commands to monitor and maintain PPP scalability:

Command	Purpose
`Router# show atm pvc ppp`	(PPPoA and PPPoE) Displays each PVC configured for PPP.
`Router# show ip local pool`	(PPPoA and PPPoE) Displays the local address pools.
`Router# show vpdn tunnel [all \| packets \| state \| summary \| transport] [id \| local-name \| remote-name]`	(PPPoE only) Displays VPDN tunnel information including tunnel protocol, ID, packets sent and received, receive window sizes, retransmission times, and transport status.
`Router> clear vpdn tunnel l2tp remote-name local-name`	(PPPoE only) Shuts down a specific tunnel and all the sessions within the tunnel.

Examples

Router# show atm pvc ppp VCD / Peak Avg/Min Burst ATM Int. Name VPI VCI Type VA VASt SC Kbps Kbps Cells VCSt 0/0/0.101 2 1 41 PVC 1 DOWN UBR 599040 UP 0/0/0.101 3 1 42 PVC 2 DOWN UBR 599040 UP 0/0/0.101 4 1 43 PVC 3 DOWN UBR 599040 UP 0/0/0.101 5 1 44 PVC 4 DOWN UBR 599040 UP 0/0/0.101 6 1 45 PVC 5 DOWN UBR 599040 UP 0/0/0.101 7 1 46 PVC 6 DOWN UBR 599040 UP 0/0/0.101 8 1 47 PVC 7 DOWN UBR 599040 UP 0/0/0.101 9 1 48 PVC 8 DOWN UBR 599040 UP 0/0/0.101 10 1 49 PVC 9 DOWN UBR 599040 UP 0/0/0.101 11 1 50 PVC 10 DOWN UBR 599040 UP 0/0/0.101 12 1 51 PVC 11 DOWN UBR 599040 UP 0/0/0.101 13 1 52 PVC 12 DOWN UBR 599040 UP 0/0/0.101 14 1 53 PVC 13 DOWN UBR 599040 UP Router# show ip local pool Pool Begin End Free In use pool1 110.1.1.1 110.1.1.250 10 240 110.1.2.1 110.1.2.250 3 247 110.1.3.1 110.1.3.250 1 249 110.1.4.1 110.1.4.250 6 244 110.1.5.1 110.1.5.250 1 249 110.1.6.1 110.1.6.250 4 246 110.1.7.1 110.1.7.250 2 248 110.1.8.1 110.1.8.250 2 248 110.1.9.1 110.1.9.250 3 247 110.1.10.1 110.1.10.250 3 247 110.1.11.1 110.1.11.250 3 247 110.1.12.1 110.1.12.250 7 243 110.1.13.1 110.1.13.250 2 248

Monitoring and Troubleshooting L2TP Scalability

For general information on monitoring and troubleshooting L2TP, see the Layer 2 Tunnel Protocol feature module and the "Configuring Virtual Private Networks" chapter in the "Virtual Templates, Profiles, and Networks" part of the Cisco IOS Dial Technologies Configuration Guide.

Use the following commands to monitor and maintain L2TP scalability:

Command	Purpose
`Router# show vpdn tunnel [all \| packets \| state \| summary \| transport] [id \| local-name \| remote-name]`	Displays VPDN tunnel information including tunnel protocol, ID, packets sent and received, receive window sizes, retransmission times, and transport status.
`Router# show vpdn session [all [interface \| tunnel \| username]\| packets \| sequence \| state \| timers \| window]`	Displays VPDN session information including interface, tunnel, username, packets, status, and window statistics.
`Router> clear vpdn tunnel l2tp remote-name local-name`	Shuts down a specific tunnel and all the sessions within the tunnel.

The show vpdn tunnel all privileged EXEC command output includes scalability parameters. Scalability-related fields are described in Table 6-2.

Router# show vpdn tunnel all

 
 L2TP Tunnel Information (Total tunnels=1 sessions=500)
 
 Tunnel id 20 is up, remote id is 12, 500 active sessions
   Tunnel state is established, time since change 00:00:33
   Remote tunnel name is LAC
     Internet Address 10.1.1.1, port 1701
   Local tunnel name is LNS
     Internet Address 10.1.1.2, port 1701
   971 packets sent, 1259 received, 19892 bytes sent, 37787 received
   Control Ns 501, Nr 746
   Local RWS 3000 (default), Remote RWS 3000 (max)
   Retransmission time 4, max 8 seconds
   Unsent queuesize 0, max 0
   Resend queuesize 251, max 261
   Total resends 390, ZLB ACKs 251
   Current nosession queue check 0 of 5
   Retransmit time distribution: 0 0 0 0 1 0 0 0 1 
   Sessions disconnected due to lack of resources 0

Table 6-2: Scalability-Related show vpdn tunnel all Field Descriptions

Field (as it appears in previous example)	Description
Retransmission time 4, max 8 seconds	Current retransmit timeout for the tunnel; maximum retransmit timeout reached by the tunnel.
Unsent queuesize 0, max 0	Number of control packets waiting to be sent to the peer; maximum number of control packets in the unsent queue.
Resend queuesize 251, max 261	Number of control packets sent but not acknowledged; maximum number of unacknowledged control packets in the resend queue.
Total resends 390, ZLB ACKs 251	Total number of packets resent; number of zero length body acknowledgment messages sent.
Current nosession queue check 0 of 5	Number of tunnel timeout periods since the last session ended. Up to 5 tunnel timeouts are used if there are outstanding control packets on the unsent or resend queue. Otherwise, the tunnel is dropped after 1 tunnel timeout.
Retransmit time distribution: 0 0 0 0 1 0 0 0 1	Histogram showing the number of retransmissions at 0, 1, 2,..., 8 seconds, respectively.
Sessions disconnected due to lack of resources 0	Number of sessions for which there were no precloned interfaces available. By default, a request for a new session at an LNS is refused if a precloned interface is not available.

Table of Contents

Session and Tunnel Scalability