Understanding and Troubleshooting Idle Timeouts

Introduction

A common issue affecting dialup links is unexpected call drops. The reasons for this vary from hardware failures, to issues within the Telco. However, one of the most common causes for unexpected call drops is the expiry of the idle timeout.

Another common idle timeout issue is that the link does not disconnect since the idle timeout never expires. This can result in high toll charges for connections that are charged based on the time the call is connected.

This document focuses on configuring and troubleshooting idle timeout issues.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Common Problems and Symptoms

The following symptoms may indicate issues related to the idle timeout:

• Calls get disconnected every two minutes (120 seconds) after the connection is established.

  This disconnection is normally due to the default idle-timeout of 120 seconds being enabled, while the interesting traffic definition is either not defined or is not applied to the interface. Although the dialer in-band command enables a default idle timeout of 120 seconds on the interface, this value does not appear in the show running-configuration output. Because the default idle-timeout is not visible, a 120 second disconnect is often misdiagnosed.

• Calls get disconnected every x minutes after the connection is established.

  This disconnection is normally due to the idle-timeout being configured (using the dialer idle-timeout command), while the interesting traffic definition is either not defined or is not applied to the interface.

• Calls disconnect prematurely. This is probably due to a low dialer idle timeout value combined or a restrictive interesting traffic definition.

• Calls do not disconnect. This is probably caused by a high dialer idle timeout value along with a loose interesting traffic definition.

Idle Timeouts

The key idle timeout command is dialer idle-timeout, which is an interface configuration command for async, group-async, ISDN and dialer interfaces. (Another commonly-used command, ppp timeout idle, which is used on virtual access interfaces, is outside the scope of this document. For more information on ppp timeout idle, refer to the document PPP Per-User Timeouts.)

The dialer idle-timeout {x} command can be configured on any dialer-capable interface. The idle counter controls how long the connection can be idle (in seconds) before it is terminated. The counter resets or counts down based upon what the router determines as "interesting traffic". If the router sees interesting traffic (as defined in dialer-list), it resets the idle timer, or else the idle timer continues to count down. When the timer reaches zero, the call is disconnected.

Listed below are some points you should note about this command:

• This command can only be applied to interfaces that are dialer-capable. By default, all ISDN interfaces (Basic Rate Interface [BRI] and Primary Rate Interface [PRI]) are dialer-capable, so this command can be added without problems.

• Async interfaces (for example, interface async x or interface group-async x) are not dialer-capable by default. You must make them dialer-capable by entering the command dialer in-band. Note that virtual templates (and therefore virtual-access interfaces) are not dialer-capable, but are point-to-point only. Therefore, they cannot use this command unless running Cisco IOS® Software Version 12.2(4)T, when enhancements to the idle timeout structure were included.

• You can only configure the dialer idle-timeout after entering the dialer in-band command on the async interface.

• On a dialer-capable interface (that is, ISDN or async with dialer in-band), the default idle timeout is 120 seconds (two minutes). Unless you explicitly configure the command dialer idle-timeout with a different idle timeout value, the default value is used.

  Note: The default idle-timeout is not shown in the configuration because it is the default. Use the show dialer command to determine if an idle timeout is enforced on the interface.

• If you want users to be able to stay connected until they choose to disconnect, use the dialer idle-timeout 0 command. The zero option for dialer idle-timeout was introduced in Cisco IOS Software Release 12.1(3)T, and sets a timeout of infinity.

Interesting Traffic

With Dial-on-Demand Routing (DDR), all traffic is classified as either interesting or uninteresting. If the traffic is interesting, then the router connects to the peer. If the traffic is not interesting then the call is not connected. However, for connections that are already connected, interesting traffic has a different purpose. It is used to reset the idle timeout back to the maximum value (configured with the dialer idle-timeout command). The moment a connection is made, the idle-timer starts to decrease. Once the router receives a packet that matches the interesting traffic definition, the idle-timer is reset back to the maximum value.

Traffic that is considered to be interesting is defined by the dialer-list {n} command (in global configuration mode), where {n} matches the number in the dialer-group {n} command statement under the interface configuration.

There are two methods for defining interesting traffic. The simple method (using only the dialer-list command) specifies an entire protocol (such as IP or IPX) as either interesting or uninteresting. However, if you need give a granular interesting traffic definition (for example, if HTTP traffic is interesting, but Telnet traffic is not) you need to use the dialer-list command in conjunction with an access-list.

Refer to the section Configuring Idle Timeout and Interesting Traffic for more information on configuring interesting traffic.

Specifying the Direction of Interesting Traffic

By default, the dialer idle-timeout is reset back to maximum by interesting traffic in the outbound direction. If only inbound traffic should reset the idle timeout, then use the additional keyword inbound. Use the either keyword for inbound and outbound traffic to reset the idle-timeout . This was introduced in Cisco IOS Software Release 12.1(1)T.

Benefits: By specifying that only inbound traffic will reset the dialer idle timer, you can prevent unexpected Internet traffic from keeping an idle connection from being disconnected.

Defining Interesting Traffic and Idle Timeouts

Interesting traffic must be defined on both ends of a DDR link. Even if the router receiving the call only handles incoming calls and does not make outbound calls, we must still define the interesting traffic.

The interesting traffic definition has a different purpose for incoming Async calls and ISDN calls.

For ISDN Users (Corresponding to Interface Dialer X)

The dialer-group and dialer-list commands are required on the dialer interface, regardless of whether you want to enforce idle timeout or not. The dialer-group and dialer-list commands are necessary on the dialer interface to avoid encapsulation failures. This requirement is only for ISDN users and not for Async users and the group-async interface.

To enforce an idle timeout, add the dialer in-band and dialer idle-timeout commands. However, if dialer in-band is configured but dialer idle-timeout is not, then the idle timeout will default to two minutes for ISDN users.

If you want your ISDN users to stay connected until they choose to disconnect, use the dialer idle-timeout 0 command. The zero option for dialer idle-timeout was introduced in Cisco IOS Software Release 12.1(3)T, and it sets a timeout of infinity.

For ISDN users (Corresponding to interface BRI x and interface Serial x:23)

All the physical ISDN interfaces are DDR enabled by default. This means that dialer in-band is already enabled on that interface. To enforce idle timeout, add the dialer idle-timeout command. However, if dialer in-band is configured but dialer idle-timeout is not, then the idle timeout defaults to two minutes for ISDN users.

The dialer-group and dialer-list commands are required on that interface, regardless of whether you want to enforce idle-timeout or not. The dialer-group and dialer-list commands are necessary on the interface to avoid encapsulation failures. This requirement is only for ISDN users, not for Async users and the group async-interface.

If you want your ISDN users to stay connected until they choose to disconnect, use the dialer idle-timeout 0 command. The zero option for dialer idle-timeout was introduced in Cisco IOS Software Release 12.1(3)T, and it sets a timeout of infinity.

For Async Users (Corresponding to Interface Group-Async X)

To enforce an idle timeout for Async users, configure the following commands in the group-async interface:

• dialer in-band

• dialer idle-timeout

• dialer-group

The corresponding dialer-list is also necessary. The dialer-group and dialer-list commands specify the interesting traffic on the group-async interface.

For Async users, the interesting traffic is only used to reset the idle timeout. If interesting traffic is not defined, then users will be disconnected after the dialer idle timeout (default 120 seconds) expires, regardless of whether they are passing traffic on the link. With an interesting traffic definition, the network access server (NAS) will recognize those packets and reset the idle timeout, thus disconnecting the user only when there is a truly idle link.

You can modify the interesting traffic such that, for example, only HTTP (web) traffic is interesting. In such a situation, if the user does not browse the web for 300 seconds (or for the specified dialer idle timeout), they are disconnected. Configure interesting traffic depending on the traffic patterns of your users.

If you want your Async users to be able to stay connected until they choose to disconnect, then remove the following commands from the group-async interface, as shown in the configuration:

• dialer in-band

• dialer idle-timeout

• dialer-group

You can also set the idle timeout to infinity using the dialer idle-timeout 0 command. The zero option for dialer idle timeout was introduced in Cisco IOS Software Release 12.1(3)T, and it sets a timeout of infinity.

Configuring Idle Timeout and Interesting Traffic

This section discusses how you can configure idle timeout and interesting traffic on the router. You can apply this configuration to all the DDR-enabled interfaces, such as:

interface BRI
interface async x
interface dialer x
interface group-async x
interface serial x:23

You can also use an Authentication, Authorization, and Accounting (AAA) server to provide per-user timeouts. Refer to the document PPP Per-User Timeouts for more information.

Sample Configuration

The following configuration sample includes a simple definition of interesting traffic. This particular example designates all IP traffic as interesting:

interface BRI0/0
ip address 10.1.1.1 255.255.255.0
no ip directed-broadcast
encapsulation ppp
dialer idle-timeout 900
!--- Idle-timeout is set at 900 seconds (15 minutes)
dialer-group 1
!--- Apply interesting traffic definition from dialer-list 1
isdn switch-type basic-5ess
no cdp enable
ppp authentication chap
!
dialer-list 1 protocol ip permit
!--- Designate all IP traffic as interesting. This definition was applied to BRI0/0 using dialer-group 1. Note that the dialer-list and dialer-group numbers match

The above configuration keeps the connection active for at least 900 seconds (15 minutes) and allows IP traffic in either direction (the default) to reset the idle timeout back to 900 seconds. Therefore, if no IP traffic passes in either direction for 15 minutes, the router disconnects the line because the idle timeout has expired.

Note: If you run a routing protocol over this DDR link, the periodic traffic keeps the link up indefinitely. Hence, the interesting traffic definition shown above is not recommended for links with routing protocols (or other periodic traffic) running across it.

Using Access Lists

The following example shows a router with the Basic Rate Interface (BRI) interface that is receiving the call and has enabled the dialer idle-timeout command with the inbound keyword. This command allows only inbound traffic that conforms to the dialer list to reset the dialer idle timer. Here, only the TCP traffic on port 80 (HTTP traffic) is allowed to reset the idle timeout back to ten minutes (600 seconds). Therefore, if the end user does not browse the web for ten minutes, the connection is disconnected.

Using ISDN Interfaces

interface BRI0/0   
ip address 10.1.1.1 255.255.255.0
no ip directed-broadcast
encapsulation ppp
dialer idle-timeout 600 inbound

!--- Idle timeout is 600 seconds. Only inbound interesting traffic will reset the idle timeout

dialer-group 1

!--- Apply the interesting traffic defintion from dialer-list 1 
peer default ip address pool dialin
isdn switch-type basic-5ess
no cdp enable
ppp authentication chap
!
access-list 101 permit tcp any any eq 80

!--- Permit tcp port 80 (http) from any host to any other host

access-list 101 deny ip any any

!--- All other IP traffic is uninteresting

dialer-list 1 protocol ip list 101

!--- Use list 101 for granular interesting traffic definition
ip local pool dialin 10.1.1.2 10.1.1.254

Using Async Interfaces

Async interfaces are not DDR-enabled by default, so using dialer in-band renders them DDR-enabled.

Interface group-async 1
ip unnumbered ethernet 0
no ip directed-broadcast
encapsulation ppp
dialer in-band
dialer idle-timeout 600
dialer-group 1
peer default ip address pool dialin
no cdp enable
ppp authentication chap
!
access-list 101 permit tcp any any eq 80
access-list 101 deny ip any any

!--- Access-lists have an implicit deny. However, we are explicitly denying IP here for clarity. 

dialer-list 1 protocol ip list 101
ip local pool dialin 10.1.1.2 10.1.1.254

Idle Timeout Enhancements

Prior to Cisco IOS Software Release 12.2(4)T, the dialer idle timer could only be reset for interesting traffic on interfaces which were dialer-enabled (for example, BRI, PRI, and group-async with the dialer in-band command). Idle timeouts could not be applied to users connected to virtual-template interfaces.

As of Cisco IOS Software Release 12.2(4)T, the Customer Profile Idle Timer Enhancements for Interesting Traffic feature provides new commands and functionality that address idle timer issues for virtual access dialup network (VPDN) sessions, which use virtual access (projected) interfaces and rely on the PPP idle timer mechanism.

Verifying the Idle Timeout

Perform the following steps to verify and troubleshoot idle timeout behavior:

1. Ensure that the call is connected using the show user command.

2. Use show caller timeout, show dialer, and show caller user to determine whether the idle timeout is correctly assigned to the connected interface. If you run the show commands multiple times, you should see the time to disconnect decreasing.

3. Initiate interesting traffic (as defined by dialer-list x) across the link. You should look at the running configuration to determine the interesting traffic definition.

4. Run show caller timeout, show dialer, and show caller user once again to determine if the idle timeout has been reset. If this does not happen, then either the interesting traffic is not defined properly (using dialer-list) or it has not been applied to the interface (using dialer-group).

The commands used to verify idle timeout behavior are listed below:

• show caller timeout - Shows the installed absolute and idle timeout, as well as how much time before the user is disconnected by any timeouts.

• show dialer [interface type number] - Displays general diagnostic information for interfaces configured for DDR. If the dialer has come up properly, the dialer state is data link layer up message appears. If physical layer up appears, this means the line protocol has come up, but the Network Control Protocol (NCP) has not. The source and destination addresses of the packet that initiated the dialing are shown in the dial reason line. This command also displays the timer's configuration and the time before the connection times out.

• show caller user username detail - Shows parameters for the particular user such as the IP address assigned, PPP and PPP bundle parameters, and so on. If your version of Cisco IOS software does not support this command, use the show user command.

For ISDN Calls

Here is the configuration for the receiving side router with a BRI interface linked to the interface dialer 1 with the dialer rotary-group 1 command. Bear in mind that interface dialer 1 is DDR-enabled using the command dialer in-band.

interface BRI0
   description 96665500
   no ip address
   encapsulation ppp
   no ip route-cache
   no ip mroute-cache
   dialer rotary-group 1
   dialer-group 1
   isdn switch-type basic-5ess
   no cdp enable
   ppp authentication pap
 !
 interface Dialer1
   ip address 10.1.1.1 255.255.255.0
   encapsulation ppp
   no ip route-cache
   no ip mroute-cache
   dialer in-band
   dialer idle-timeout 600
   dialer-group 1
   peer default ip address pool dialin
   no cdp enable
   ppp authentication chap callin
   ppp chap hostname cisco
   ppp chap password 7 <deleted>
 !
 ip local pool dialin 10.1.1.2 10.1.1.255
 dialer-list 1 protocol list 101
 access-list 101 permit icmp any any
 access-list 101 permit tcp any any eq 80
 access-list 101 deny ip any any

!--- Only http traffic and icmp traffic are interesting
 
 !

Perform the following steps to verify the idle timeout:

1. Ensure that the call is connected. You can use the show user command to verify that the user is connected. For example:

   isdn2-4#show user
   
   Line   User  Host(s)       Idle     Location
   * 2 vty 0  idle         00:00:00 172.22.88.109
   
   Interface   User  Mode     Idle      Peer Address
   BR0:1       Preet Sync PPP 00:00:51  PPP: 10.1.1.2
   

2. Verify that the idle timeout is applied to the connection. In the example below, the user Preet dialed in and terminated on interface dialer 1, and obtained the IP address 10.1.1.2 from the pool dialin. Now let's verify that the connection is using an idle timeout of 600 seconds (10 minutes).

   isdn2-4#show dialer interface dialer1
   Di1 - dialer type = IN-BAND SYNC NO-PARITY
   Load threshold for dialing additional calls is 255
   Idle timer (600 secs), Fast idle timer (20 secs)
   !--- The idle timeout value configured on int dialer 1. If the default is in use, this value will be 120.
   
   Wait for carrier (30 secs), Re-enable (15 secs)
   Number of active calls = 1
   
   Dial String   Successes   Failures   Last DNIS   Last status
   
   BRI0 - dialer type = ISDN
   Rotary group 1, priority = 0
   0 incoming call(s) have been screened.
   0 incoming call(s) rejected for callback.
   
   BRI0:1 - dialer type = ISDN
   Idle timer (600 secs), Fast idle timer (20 secs)
   !--- The user Preet obtained the idle timeout of 600 seconds.
   
   Wait for carrier (30 secs), Re-enable (15 secs)
   Dialer state is data link layer up
   Time until disconnect 557 secs
   

   The time to disconnect is counting down as no interesting traffic is passing on the link. There has been no interesting traffic passing in either direction for the last 43 seconds. Hence, the user is disconnected in 600 - 43 = 557 seconds. The time until disconnect field begins counting down once the user is connected and is reset to the maximum when interesting traffic is received.

   Connected to 4086666700 (Preet)
   BRI0:2 - dialer type = ISDN
   Idle timer (600 secs), Fast idle timer (20 secs)
   Wait for carrier (30 secs), Re-enable (15 secs)
   Dialer state is idle

   Another command that can be used to verify the idle timeout is show caller timeout:

   isdn2-4#show caller timeout
   Line    User   Limit     Remaining   Timer  Type
   vty 2    -     00:10:00  00:09:59    Idle   Exec
   BR0:1   Preet  00:10:00  00:09:13    Dialer idle
   

   The limit field shows the maximum idle timeout (in minutes) configured and the remaining field shows the time until disconnect.

3. Initiate interesting traffic to the peer. We will now initiate interesting traffic to the peer. Make sure you look at the running-configuration to determine the exact interesting traffic definition. Access-list 101 defines Internet Control Message Protocol (ICMP) and TCP traffic to port 80 as interesting. Therefore, we will now ping 10.1.1.2 (IP address that user Preet has negotiated) from the router.

   isdn2-4#ping 10.1.1.2
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 36/37/40 ms
   isdn2-4#

4. Verify that the idle timeout has been reset. Use the show caller timeout, show dialer, and show caller user commands to verify that the idle timeout has been reset:

   isdn2-4#show caller timeout 
    Line     User      Limit    Remaining  Timer Type 
    vty 2    -         00:10:00 00:09:59   Idle Exec 
    BR0:1    Preet     00:10:00 00:09:59   Dialer idle
   !--- Idle-timout is reset back to maximum
   
   
   isdn2-4#show dialer interface dialer1
   
   Di1 - dialer type = IN-BAND SYNC NO-PARITY
   Load threshold for dialing additional calls is 255
   Idle timer (600 secs), Fast idle timer (20 secs)
   Wait for carrier (30 secs), Re-enable (15 secs)
   Number of active calls = 1
   
   Dial String   Successes   Failures   Last DNIS   Last status
   
   BRI0 - dialer type = ISDN
   Rotary group 1, priority = 0
   0 incoming call(s) have been screened.
   0 incoming call(s) rejected for callback.
   
   BRI0:1 - dialer type = ISDN
   Idle timer (600 secs), Fast idle timer (20 secs)
   Wait for carrier (30 secs), Re-enable (15 secs)
   Dialer state is data link layer up
   Time until disconnect 599 secs
   
   !--- Idle timeout is reset back to maximum.
   
   
   Connected to 4086666700 (Preet)
   
   BRI0:2 - dialer type = ISDN
   Idle timer (600 secs), Fast idle timer (20 secs)
   Wait for carrier (30 secs), Re-enable (15 secs)
   Dialer state is idle
   isdn2-4# 
   

Another useful command that can be used to see the timeout information based on the username, is the show caller user command.

isdn2-4#show caller user Preet
 User: Preet, line BR0:1, service PPP 
 Connected for 00:05:36, Idle for 00:02:37
!--- Shows the inactivity for the last two minutes and 37 seconds. This counter increments to ten minutes and then the call is disconnected.


Timeouts: Limit    Remaining Timer  Type
          00:10:00 00:07:22  Dialer idle
!--- Time until idle disconnect. 

PPP: LCP Open, PAP (<- none), IPCP
Dialer: Connected to 4086666700, inbound
        Type is ISDN, group Di1
IP: Local 10.1.1.1/24, remote 10.1.1.2
Counts: 215 packets input, 5392 bytes, 0 no buffer
        0 input errors, 0 CRC, 0 frame, 0 overrun
        230 packets output, 5603 bytes, 0 underruns
        0 output errors, 0 collisions, 7 interface resets

If the idle timeout is not reset, proceed to the section Troubleshooting Idle Timeout Issues.

For Async Calls

Here is a typical configuration for the Async calls you can see in the ISP's environment.

 interface Group-Async0
   ip unnumbered Loopback0
   encapsulation ppp
   dialer in-band

!--- Make this interface dialer capable
 
   dialer idle-timeout 600

!--- Idle timeout of 600 seconds (10 minutes)

   dialer-group 1

!--- Interesting traffic definition from dialer-list 1

   async mode interactive
   peer default ip address pool dialin
   ppp authentication pap chap callin
   group-range 1/3/00 1/3/71
   !
   ip local pool dialin 10.1.1.3 10.1.1.255
 dialer-list 1 protocol list 101

!--- Interesting traffic definition is defined by access-list 101

access-list 101 permit icmp any any

!--- Permit icmp from any host to any other host 
 access-list 101 permit tcp any any eq 80

!--- Permit tcp port 80 (http traffic)

access-list 101 deny ip any any

!--- Deny all other IP traffic. This interesting traffic definition will allow icmp and http traffic to reset the idle timeout. All other IP traffic will not affect the timeout.

Just as with ISDN, use the show users, show dialer, and show caller timeout to verify the idle timeout.

Use the show users command to find the interface and IP address the peer is connected on.

c5800#show users
      Line      User  Host(s)         Idle     Location
   * 0 con 0          idle            00:00:00 
     tty 1/3/01 Preet Async interface 00:00:09 PPP: 10.1.1.3
!--- User Preet is connected to async interface 1/3/01 and has IP address 10.1.1.3 
Interface    User Mode             Idle     Peer          Address

Use the show dialer command (specifying the interface just determined) to observe the timer values:

c5800#show dialer interface async 1/3/01
As1/3/01 - dialer type = IN-BAND ASYNC NO-PARITY
Idle timer (600 secs), Fast idle timer (20 secs)
!--- Idle timeout of 600 seconds is applied to the interface if this value is 120 seconds.


!--- Verify that dialer in-band is configured under the group-async interface. 
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Time until disconnect 574 secs (Preet)
!--- Call will be disconnected in 574 seconds unless it receives interesting traffic.
Dial String     Successes    Failures    Last DNIS     Last status

The show caller timeout command can also display the time to disconnect:

c5800#show caller timeout
                        Session    Idle      Disconnect
   Line        User     Timeout    Timeout     User in
   con 0        -        -          -           - 
   tty 1/3/01  Preet     -          -           - 
   As1/3/01    Preet     -         00:10:00    00:09:19 

We will now initiate interesting traffic. Access-list 101 defines ICMP and TCP traffic to port 80 (HTTP traffic) as interesting. Ping 10.1.1.3 (IP address that user Preet has negotiated) from the router to reset the idle timeout.

c5800#ping 10.1.1.3
   Type escape sequence to abort.
   Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
   !!!!!
   Success rate is 100 percent (5/5), round-trip min/avg/max = 108/113/124 ms

Verify that the timeout has been reset:

   c5800#show caller timeout
                      Session Idle    Disconnect
   Line       User    Timeout Timeout User in
   con 0      -        -       -      - 
   tty 1/3/01 Preet    -       -      - 
   As1/3/01   Preet    -     00:10:00 00:09:58
!--- Time to disconnect is close to 10 minutes

This proves that the interesting traffic is correctly defined and is applied correctly. Alternately, you can use the show dialer command to verify the timeout values:

c5800#show dialer interface async 1/3/01
   As1/3/01 - dialer type = IN-BAND ASYNC NO-PARITY
   Idle timer (600 secs), Fast idle timer (20 secs)
   Wait for carrier (30 secs), Re-enable (15 secs)
   Dialer state is data link layer up
   Time until disconnect 594 secs (Preet)
   Dial String   Successes    Failures   Last DNIS    Last status

You can also use the show caller user {username} detailed command to verify the parameters specific to the user:

c5800#show caller user preet detailed 
User:   Preet, line tty 1/3/01, service Async
        Active time 00:01:14, Idle time 00:00:18
Timeouts:          Absolute   Idle      Idle
                              Session   Exec
Limits:            -          -         00:10:00
Disconnect in:     -          -         -    
TTY: Line 1/3/01, running PPP on As1/3/01   
Location: PPP: 10.1.1.3   
DS0: (slot/unit/channel)=1/4/0   
Status: Ready, Active, No Exit Banner, Async Interface Active
        HW PPP Support Active   
Capabilities: No Flush-at-Activation, Hardware Flowcontrol In
              Hardware Flowcontrol Out, Modem Callout, Modem RI is CD                 
              Line usable as async interface, Telnet Faststream   
Modem State: Ready

User: Preet, line As1/3/01, service PPP
      Active time 00:01:11, Idle time 00:00:18   
Timeouts:        Absolute Idle
Limits:          -        00:10:00    
Disconnect in:   -        00:09:41 
!--- Idle timeout of 10 minutes. The call will be disconnected in 9 minutes 41 secs unless it receives interesting traffic during that time. If the absolute column has a value, then the call will be disconnected at that time regardless of the idle timeout.

PPP: LCP Open, CHAP (<- local), IPCP
LCP: -> peer, ACCM, AuthProto, MagicNumber, PCompression, ACCompression          
     <- peer, ACCM, MagicNumber, PCompression, ACCompression   
NCP: Open IPCP   
IPCP: <- peer, Address
      -> peer, Address   
Dialer: Connected, inbound
        Idle timer 600 secs, idle 20 secs
        Type is IN-BAND ASYNC, group As1/3/01   
IP: Local 10.1.1.251, remote 10.1.1.3   
Counts: 12 packets input, 651 bytes, 0 no buffer 
        0 input errors, 0 CRC, 0 frame, 0 overrun           
        13 packets output, 666 bytes, 0 underruns           
        0 output errors, 0 collisions, 0 interface resets

Troubleshooting Idle Timeout Issues

Symptom: Call Disconnects Prematurely or Call Does Not Disconnect At All

If the call disconnects unexpectedly, or the call never disconnects, check the dialer idle timeout and interesting traffic definition. You can use the debug dialer packet command to see if a particular packet is interesting or not. For example:

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 
64 bytes, outgoing uninteresting (list 101)
Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 
100 bytes, outgoing interesting (list 101)

In the above example, OSPF hellos are uninteresting per access-list 101, while the second packet is interesting per access-list 101. Troubleshoot as follows:

1. Adjust the dialer idle timeout in the dialer interface configuration. The default is 120 seconds, but you may wish to raise or lower this value depending on your needs.

   router(config-if)#dialer idle-timeout 

   Note: If the call does not disconnect, verify that the zero option for dialer idle timeout (introduced in Cisco IOS Software Release 12.1(3)T) is not set.

2. Change the interesting traffic definition (configured with the dialer-list command). If the call disconnects prematurely, you may wish to define the interesting traffic more loosely (deny a few and permit everything else). If the call never disconnects, change your interesting traffic definition to be more restrictive (permit a few and deny everything else).

   Tip: If your link does not disconnect, be sure to define routing protocol traffic (or any other periodic traffic) as uninteresting. This prevents periodic hellos from resetting the idle timeout. Here is a sample interesting traffic definition:

   access-list 101 remark Interesting traffic for dialer-list 1   
   access-list 101 deny ospf any any
   !--- Mark OSPF as uninteresting. This will prevent OSPF hellos from keeping the link up. 
   
   access-list 101 deny udp any any eq ntp
   
   !--- Define ntp traffic as NOT interesting. This will prevent periodic ntp traffic from keeping the link up indefinitely. 
   
   access-list 101 permit ip any any
   !--- All other IP traffic is interesting. Change this depending on your traffic needs.
   
   dialer-list 1 protocol ip list 101
   !--- This interesting traffic is applied to the dialer interface using dialer-group 1.
   
   

   For more information, refer to the document Dialup Technology: Overviews and Explanations.

Symptom: Call Disconnects Every Few Seconds

Another problem is that the call disconnects every "x" seconds (most often 120 seconds). In certain situations, even if traffic passes on the link, DDR does not reset the idle timeout. This is likely due to:

• the interesting traffic not being defined

• the interesting traffic definition not applied to the interface

• the interface not made dialer-capable

To resolve this:

1. Verify that the dialer-list is defined and the dialer-group (pointing to the dialer-list) is configured under the interface. Configure a simple interesting traffic definition:

   router(config)#interface dialer 1
   router(config-if)#dialer-group 1
   router(config-if)#exit
   router(config)#dialer-list 1 protocol ip permit
   

   After you get the frequent disconnect issue resolved, you can adjust the interesting traffic definition to suit your needs.

2. Ensure that dialer in-band is configured on the group-async and dialer interfaces. This command is not needed on dialer-capable interfaces like interface BRI x and interface Serial x:23 (for PRIs).

3. Adjust the dialer idle timeout to the desired value.

   router(config-if)#dialer idle-timeout 900
   

Related Information

• Dial Technology Support Page
• Technical Support - Cisco Systems