Présentation et dépannage des délais d'inactivité

Introduction

Un problème courant affectant les liaisons d’accès par réseau commuté entraîne des déconnexions inattendues. Cela peut provenir de défaillances matérielles ou de problèmes au sein de la compagnie de téléphone. Cependant, l’une des causes les plus courantes des déconnexions inattendues est l’échéance du délai d’inactivité.

Un autre problème courant de délai d'inactivité est que la liaison ne se déconnecte pas, car le délai d'inactivité n'expire jamais. Cela peut se traduire par des frais d'interurbain élevés pour les connexions facturées en fonction du moment où l'appel est connecté.

Ce document se concentre sur la configuration et le dépannage des problèmes de délai d'inactivité.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Problèmes courants et symptômes

Les symptômes suivants peuvent indiquer des problèmes liés au délai d'inactivité :

• Les appels sont déconnectés toutes les deux minutes (120 secondes) après l'établissement de la connexion.

  Cette déconnexion est normalement due au délai d'inactivité par défaut de 120 secondes activé, alors que la définition de trafic intéressante n'est pas définie ou n'est pas appliquée à l'interface. Bien que la commande dialer in-band active un délai d'inactivité par défaut de 120 secondes sur l'interface, cette valeur n'apparaît pas dans la sortie show running-configuration. Comme le délai d'inactivité par défaut n'est pas visible, une déconnexion de 120 secondes est souvent mal diagnostiquée.

• Les appels sont déconnectés toutes les x minutes après l'établissement de la connexion.

  Cette déconnexion est normalement due au délai d'inactivité configuré (à l'aide de la commande dialer idle-timeout), alors que la définition de trafic intéressante n'est pas définie ou n'est pas appliquée à l'interface.

• Les appels se déconnectent prématurément. Ceci est probablement dû à une faible valeur de délai d'inactivité du numéroteur combinée ou à une définition de trafic intéressante restrictive.

• Les appels ne se déconnectent pas. Ceci est probablement dû à une valeur de délai d'inactivité élevée du numéroteur, ainsi qu'à une définition de trafic peu intéressante.

Délais d'inactivité

La commande key idle timeout est dialer idle-timeout, qui est une commande de configuration d'interface pour les interfaces asynchrones, group-async, RNIS et dialer. (Une autre commande couramment utilisée, ppp timeout idle, qui est utilisée sur les interfaces d'accès virtuel, n'entre pas dans le cadre de ce document. Pour plus d'informations sur ppp timeout idle, reportez-vous au document PPP Per-User Timeouts.)

La commande dialer idle-timeout {x} peut être configurée sur n'importe quelle interface compatible avec le numéroteur. Le compteur d'inactivité contrôle la durée pendant laquelle la connexion peut être inactive (en secondes) avant d'être interrompue. Le compteur se réinitialise ou compte en fonction de ce que le routeur détermine comme « trafic intéressant ». Si le routeur voit un trafic intéressant (tel que défini dans dialer-list), il réinitialise le compteur d'inactivité, sinon le compteur d'inactivité continue de compter. Lorsque le compteur atteint zéro, l'appel est déconnecté.

Vous trouverez ci-dessous quelques points à noter à propos de cette commande :

• Cette commande ne peut être appliquée qu'aux interfaces compatibles avec le numéroteur. Par défaut, toutes les interfaces RNIS (Basic Rate Interface [BRI] et Primary Rate Interface [PRI]) sont compatibles avec le numéroteur, de sorte que cette commande peut être ajoutée sans problème.

• Par défaut, les interfaces asynchrones (par exemple, interface async x ou interface group-async x) ne sont pas compatibles avec le numéroteur. Vous devez les rendre compatibles avec le numéroteur en entrant la commande dialer in-band. Notez que les modèles virtuels (et donc les interfaces d'accès virtuel) ne sont pas compatibles avec la numérotation, mais sont uniquement point à point. Par conséquent, ils ne peuvent pas utiliser cette commande à moins d'exécuter le logiciel Cisco IOS® Version 12.2(4)T, lorsque des améliorations à la structure de délai d'inactivité ont été incluses.

• Vous ne pouvez configurer le délai d'inactivité du numéroteur qu'après avoir entré la commande dialer in-band sur l'interface asynchrone.

• Sur une interface de numérotation (RNIS ou asynchrone avec numéroteur intrabande), le délai d'inactivité par défaut est de 120 secondes (deux minutes). Sauf si vous configurez explicitement la commande dialer idle-timeout avec une valeur de délai d'inactivité différente, la valeur par défaut est utilisée.

  Remarque : Le délai d'inactivité par défaut n'est pas affiché dans la configuration, car il s'agit de la valeur par défaut. Utilisez la commande show dialer pour déterminer si un délai d'inactivité est appliqué sur l'interface.

• Si vous souhaitez que les utilisateurs restent connectés jusqu'à ce qu'ils choisissent de se déconnecter, utilisez la commande dialer idle-timeout 0. L'option zéro pour le délai d'inactivité du numéroteur a été introduite dans le logiciel Cisco IOS Version 12.1(3)T et définit un délai d'infini.

Trafic intéressant

Avec le routage à établissement de connexion à la demande (DDR), tout le trafic est classé comme intéressant ou non. Si le trafic est intéressant, le routeur se connecte à l’homologue. Si le trafic n'est pas intéressant, l'appel n'est pas connecté. Cependant, pour les connexions déjà connectées, le trafic intéressant a une fonction différente. Il est utilisé pour rétablir la valeur maximale du délai d'inactivité (configuré avec la commande dialer idle-timeout). Dès qu'une connexion est établie, le compteur d'inactivité commence à diminuer. Une fois que le routeur reçoit un paquet correspondant à la définition de trafic intéressante, le compteur d’inactivité est réinitialisé à la valeur maximale.

Le trafic considéré comme intéressant est défini par la commande dialer-list {n} (en mode de configuration globale), où {n} correspond au numéro de l'instruction de commande dialer-group {n}sous la configuration d'interface.

Il existe deux méthodes pour définir le trafic intéressant. La méthode simple (en utilisant uniquement la commande dialer-list) spécifie un protocole entier (comme IP ou IPX) comme intéressant ou non. Cependant, si vous avez besoin de donner une définition de trafic granulaire intéressante (par exemple, si le trafic HTTP est intéressant, mais pas le trafic Telnet), vous devez utiliser la commande dialer-list en conjonction avec une liste d'accès.

Référez-vous à la section Configuration du délai d'inactivité et du trafic intéressant pour plus d'informations sur la configuration du trafic intéressant.

Spécification de la direction du trafic intéressant

Par défaut, le délai d'inactivité du numéroteur est rétabli au maximum par le trafic intéressant dans la direction sortante. Si seul le trafic entrant doit réinitialiser le délai d'inactivité, utilisez le mot clé supplémentaire entrant. Utilisez le mot clé soit pour le trafic entrant et sortant pour réinitialiser le délai d'inactivité . Ceci a été introduit dans le logiciel Cisco IOS Version 12.1(1)T.

Avantages: En spécifiant que seul le trafic entrant réinitialisera le minuteur d'inactivité du numéroteur, vous pouvez empêcher le trafic Internet inattendu de déconnecter une connexion inactive.

Définition du trafic intéressant et des délais d'inactivité

Le trafic intéressant doit être défini aux deux extrémités d’une liaison DDR. Même si le routeur recevant l'appel ne gère que les appels entrants et ne passe pas d'appels sortants, nous devons toujours définir le trafic intéressant.

La définition de trafic intéressante a une fonction différente pour les appels asynchrones entrants et les appels RNIS.

Pour les utilisateurs RNIS (correspondant à Interface Dialer X)

Les commandes dialer-group et dialer-list sont requises sur l'interface de numérotation, que vous souhaitiez ou non appliquer le délai d'inactivité. Les commandes dialer-group et dialer-list sont nécessaires sur l'interface de numérotation pour éviter les échecs d'encapsulation. Cette exigence s’applique uniquement aux utilisateurs RNIS et non aux utilisateurs asynchrones et à l’interface asynchrone de groupe.

Pour appliquer un délai d'inactivité, ajoutez les commandes dialer in-band et dialer idle-timeout. Cependant, si dialer in-band est configuré mais que dialer idle-timeout ne l'est pas, le délai d'inactivité sera par défaut de deux minutes pour les utilisateurs RNIS.

Si vous souhaitez que vos utilisateurs RNIS restent connectés jusqu'à ce qu'ils choisissent de se déconnecter, utilisez la commande dialer idle-timeout 0. L'option zéro pour le délai d'inactivité du numéroteur a été introduite dans le logiciel Cisco IOS Version 12.1(3)T, et elle définit un délai d'infini.

Pour les utilisateurs RNIS (correspondant aux interfaces BRI x et Serial x:23)

Toutes les interfaces RNIS physiques sont DDR activées par défaut. Cela signifie que le numéroteur intrabande est déjà activé sur cette interface. Pour appliquer le délai d'inactivité, ajoutez la commande dialer idle-timeout. Cependant, si dialer in-band est configuré mais que dialer idle-timeout ne l'est pas, le délai d'inactivité par défaut est de deux minutes pour les utilisateurs RNIS.

Les commandes dialer-group et dialer-list sont requises sur cette interface, que vous souhaitiez ou non appliquer le délai d'inactivité. Les commandes dialer-group et dialer-list sont nécessaires sur l'interface pour éviter les échecs d'encapsulation. Cette condition est uniquement requise pour les utilisateurs RNIS, et non pour les utilisateurs asynchrones et l'interface asynchrone de groupe.

Si vous souhaitez que vos utilisateurs RNIS restent connectés jusqu'à ce qu'ils choisissent de se déconnecter, utilisez la commande dialer idle-timeout 0. L'option zéro pour le délai d'inactivité du numéroteur a été introduite dans le logiciel Cisco IOS Version 12.1(3)T, et elle définit un délai d'infini.

Pour les utilisateurs asynchrones (correspondant au groupe d'interfaces Async X)

Pour appliquer un délai d'inactivité aux utilisateurs asynchrones, configurez les commandes suivantes dans l'interface group-async :

• dialer in-band

• dialer idle-timeout

• dialer-group

La liste de numérotation correspondante est également nécessaire. Les commandes dialer-group et dialer-list spécifient le trafic intéressant sur l'interface group-async.

Pour les utilisateurs asynchrones, le trafic intéressant est uniquement utilisé pour réinitialiser le délai d'inactivité. Si le trafic intéressant n'est pas défini, les utilisateurs seront déconnectés après l'expiration du délai d'inactivité du numéroteur (120 secondes par défaut), qu'ils transmettent ou non le trafic sur la liaison. Avec une définition de trafic intéressante, le serveur d'accès au réseau (NAS) reconnaîtra ces paquets et réinitialisera le délai d'inactivité, déconnectant ainsi l'utilisateur uniquement en présence d'une liaison réellement inactive.

Vous pouvez modifier le trafic intéressant de sorte que, par exemple, seul le trafic HTTP (web) est intéressant. Dans une telle situation, si l'utilisateur ne navigue pas sur le Web pendant 300 secondes (ou pour le délai d'inactivité du numéroteur spécifié), il est déconnecté. Configurez le trafic intéressant en fonction des modèles de trafic de vos utilisateurs.

Si vous souhaitez que vos utilisateurs asynchrones restent connectés jusqu'à ce qu'ils choisissent de se déconnecter, supprimez les commandes suivantes de l'interface group-async, comme indiqué dans la configuration :

• dialer in-band

• dialer idle-timeout

• dialer-group

Vous pouvez également définir le délai d'inactivité à l'infini à l'aide de la commande dialer idle-timeout 0. L'option zéro pour le délai d'inactivité du numéroteur a été introduite dans le logiciel Cisco IOS Version 12.1(3)T, et elle définit un délai d'infini.

Configuration du délai d'inactivité et du trafic intéressant

Cette section explique comment configurer le délai d'inactivité et le trafic intéressant sur le routeur. Vous pouvez appliquer cette configuration à toutes les interfaces compatibles DDR, telles que :

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

Vous pouvez également utiliser un serveur AAA (Authentication, Authorization, and Accounting) pour fournir des délais d'attente par utilisateur. Référez-vous au document PPP Per-User Timeouts pour plus d'informations.

Exemple de configuration

L'exemple de configuration suivant inclut une définition simple du trafic intéressant. Cet exemple particulier désigne tout le trafic IP comme intéressant :

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

La configuration ci-dessus maintient la connexion active pendant au moins 900 secondes (15 minutes) et permet au trafic IP dans les deux directions (la valeur par défaut) de rétablir le délai d'inactivité à 900 secondes. Par conséquent, si aucun trafic IP ne passe dans l'une ou l'autre direction pendant 15 minutes, le routeur déconnecte la ligne car le délai d'inactivité a expiré.

Remarque : si vous exécutez un protocole de routage sur cette liaison DDR, le trafic périodique maintient la liaison indéfiniment. Par conséquent, la définition de trafic intéressante présentée ci-dessus n'est pas recommandée pour les liaisons avec des protocoles de routage (ou tout autre trafic périodique) qui le traversent.

Utilisation des listes d'accès

L'exemple suivant montre un routeur avec l'interface BRI (Basic Rate Interface) qui reçoit l'appel et a activé la commande dialer idle-timeout avec le mot clé entrant. Cette commande permet uniquement au trafic entrant conforme à la liste de numérotation de réinitialiser le compteur d'inactivité du numéroteur. Ici, seul le trafic TCP sur le port 80 (trafic HTTP) est autorisé à rétablir le délai d'inactivité à dix minutes (600 secondes). Par conséquent, si l'utilisateur final ne navigue pas sur le Web pendant dix minutes, la connexion est déconnectée.

Utilisation des interfaces RNIS

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

Utilisation des interfaces asynchrones

Les interfaces asynchrones ne sont pas compatibles DDR par défaut, donc l'utilisation de la numérotation intrabande les rend compatibles DDR.

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

Améliorations du délai d'inactivité

Avant la version 12.2(4)T du logiciel Cisco IOS, le minuteur d'inactivité du numéroteur ne pouvait être réinitialisé que pour le trafic intéressant sur les interfaces qui étaient activées par numérotation (par exemple, BRI, PRI et group-async avec la commande dialer in-band). Les délais d'inactivité n'ont pas pu être appliqués aux utilisateurs connectés aux interfaces de modèle virtuel.

Depuis la version 12.2(4)T du logiciel Cisco IOS, la fonctionnalité d'amélioration du compteur d'inactivité du profil client pour le trafic intéressant fournit de nouvelles commandes et fonctionnalités qui traitent des problèmes de compteur d'inactivité pour les sessions VPDN (Virtual Access Dialup Network), qui utilisent des interfaces d'accès virtuel (projetées) et s'appuient sur le mécanisme de compteur d'inactivité PPP.

Vérification du délai d'inactivité

Procédez comme suit pour vérifier et dépanner le comportement de délai d'inactivité :

1. Vérifiez que l'appel est connecté à l'aide de la commande show user.

2. Utilisez show caller timeout, show dialer et show caller user pour déterminer si le délai d'inactivité est correctement attribué à l'interface connectée. Si vous exécutez les commandes show plusieurs fois, le temps de déconnexion devrait diminuer.

3. Lancez un trafic intéressant (tel que défini par la liste de numérotation x) sur la liaison. Vous devez examiner la configuration en cours pour déterminer la définition de trafic intéressante.

4. Exécutez show caller timeout, show dialer et show caller user une fois de plus pour déterminer si le délai d'inactivité a été réinitialisé. Si cela ne se produit pas, soit le trafic intéressant n'est pas défini correctement (en utilisant dialer-list), soit il n'a pas été appliqué à l'interface (en utilisant dialer-group).

Les commandes utilisées pour vérifier le comportement de délai d'inactivité sont répertoriées ci-dessous :

• show caller timeout - Affiche le délai d'attente absolu et inactif installé, ainsi que le temps avant que l'utilisateur ne soit déconnecté par les délais d'attente.

• show dialer [numéro de type d'interface] - Affiche des informations générales de diagnostic pour les interfaces configurées pour DDR. Si le numéroteur s'est correctement activé, le message indiquant que la couche liaison de données est active s'affiche. Si la couche physique apparaît, cela signifie que le protocole de ligne est activé, mais pas le protocole NCP (Network Control Protocol). Les adresses source et de destination du paquet qui a initié la numérotation sont indiquées dans la ligne de motif de numérotation. Cette commande affiche également la configuration du minuteur et le délai avant l'expiration de la connexion.

• show caller user username detail - Affiche les paramètres de l'utilisateur particulier, tels que l'adresse IP attribuée, les paramètres PPP et PPP, etc. Si votre version du logiciel Cisco IOS ne prend pas en charge cette commande, utilisez la commande show user.

Pour les appels RNIS

Voici la configuration du routeur côté récepteur avec une interface BRI liée à l'interface dialer 1 avec la commande dialer rotatif-group 1. Gardez à l'esprit que l'interface dialer 1 est compatible DDR à l'aide de la commande 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
 
 !

Procédez comme suit pour vérifier le délai d'inactivité :

1. Assurez-vous que l'appel est connecté. Vous pouvez utiliser la commande show user pour vérifier que l'utilisateur est connecté. Exemple :

   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. Vérifiez que le délai d'inactivité est appliqué à la connexion. Dans l'exemple ci-dessous, l'utilisateur Preet a composé et terminé sur l'interface dialer 1 et a obtenu l'adresse IP 10.1.1.2 à partir de la numérotation du pool. Maintenant, vérifions que la connexion utilise un délai d'inactivité de 600 secondes (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
   

   Le temps de déconnexion est compté car aucun trafic intéressant ne passe sur la liaison. Il n'y a eu aucun trafic intéressant dans les deux sens depuis les 43 dernières secondes. Par conséquent, l'utilisateur est déconnecté en 600 - 43 = 557 secondes. La durée jusqu'à ce que le champ de déconnexion commence à compter une fois l'utilisateur connecté et est réinitialisée au maximum lorsque le trafic intéressant est reçu.

   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

   Une autre commande qui peut être utilisée pour vérifier le délai d'inactivité est 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
   

   Le champ de limite indique le délai d'inactivité maximal (en minutes) configuré et le champ restant indique le délai jusqu'à la déconnexion.

3. Lancez un trafic intéressant vers l'homologue. Nous allons maintenant lancer un trafic intéressant vers l'homologue. Vérifiez la configuration en cours pour déterminer la définition exacte du trafic intéressant. Access-list 101 définit le protocole ICMP (Internet Control Message Protocol) et le trafic TCP vers le port 80 comme intéressant. Par conséquent, nous allons maintenant envoyer une requête ping à 10.1.1.2 (adresse IP que l'utilisateur Preet a négociée) à partir du routeur.

   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. Vérifiez que le délai d'inactivité a été réinitialisé. Utilisez les commandes show caller timeout, show dialer et show caller user pour vérifier que le délai d'inactivité a été réinitialisé :

   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# 
   

Une autre commande utile qui peut être utilisée pour afficher les informations de délai d'attente en fonction du nom d'utilisateur est la commande show caller user.

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

Si le délai d'inactivité n'est pas réinitialisé, passez à la section Dépannage des problèmes de délai d'inactivité.

Pour les appels asynchrones

Voici une configuration typique pour les appels asynchrones que vous pouvez voir dans l'environnement du FAI.

 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.

Comme avec RNIS, utilisez show users, show dialer et show caller timeout pour vérifier le délai d'inactivité.

Utilisez la commande show users pour rechercher l'interface et l'adresse IP sur lesquelles l'homologue est connecté.

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

Utilisez la commande show dialer (en spécifiant l'interface qui vient d'être déterminée) pour observer les valeurs du compteur :

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

La commande show caller timeout peut également afficher l'heure de déconnexion :

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 

Nous allons maintenant lancer un trafic intéressant. Access-list 101 définit le trafic ICMP et TCP vers le port 80 (trafic HTTP) comme intéressant. Envoyez une requête ping à 10.1.1.3 (adresse IP négociée par l'utilisateur Preet) à partir du routeur pour réinitialiser le délai d'inactivité.

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

Vérifiez que le délai d'attente a été réinitialisé :

   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

Ceci prouve que le trafic intéressant est correctement défini et appliqué correctement. Vous pouvez également utiliser la commande show dialer pour vérifier les valeurs de temporisation :

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

Vous pouvez également utiliser la commande show caller user {username} detail pour vérifier les paramètres spécifiques à l'utilisateur :

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

Dépannage des problèmes de délai d'inactivité

Symptôme : L'appel se déconnecte prématurément ou l'appel ne se déconnecte pas du tout

Si l'appel se déconnecte de manière inattendue ou si l'appel ne se déconnecte jamais, vérifiez le délai d'inactivité du numéroteur et la définition intéressante du trafic. Vous pouvez utiliser la commande debug dialer packet pour voir si un paquet particulier est intéressant ou non. Exemple :

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)

Dans l'exemple ci-dessus, les paquets Hello OSPF ne sont pas intéressants par liste d'accès 101, tandis que le deuxième paquet est intéressant par liste d'accès 101. Dépannez comme suit :

1. Réglez le délai d'inactivité du numéroteur dans la configuration de l'interface de numérotation. La valeur par défaut est de 120 secondes, mais vous pouvez augmenter ou diminuer cette valeur selon vos besoins.

   router(config-if)#dialer idle-timeout 

   Remarque : si l'appel ne se déconnecte pas, vérifiez que l'option zéro pour le délai d'inactivité du numéroteur (introduite dans le logiciel Cisco IOS Version 12.1(3)T) n'est pas définie.

2. Modifiez la définition de trafic intéressante (configurée avec la commande dialer-list). Si l'appel se déconnecte prématurément, vous pouvez définir le trafic intéressant de manière plus souple (en refuser quelques-uns et autoriser tout le reste). Si l'appel ne se déconnecte jamais, modifiez votre définition de trafic intéressante pour la rendre plus restrictive (autorisez-en quelques-uns et refusez tout le reste).

   Astuce : Si votre liaison ne se déconnecte pas, assurez-vous de définir le trafic du protocole de routage (ou tout autre trafic périodique) comme étant inintéressant. Cela empêche les HELLO périodiques de réinitialiser le délai d'inactivité. Voici un exemple de définition intéressante du trafic :

   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.
   
   

   Pour plus d'informations, reportez-vous au document Technologie commutée : Présentation et explications.

Symptôme : L'appel se déconnecte toutes les quelques secondes

Un autre problème est que l'appel se déconnecte toutes les « x » secondes (la plupart du temps 120 secondes). Dans certaines situations, même si le trafic passe sur la liaison, DDR ne réinitialise pas le délai d'inactivité. Cela est probablement dû à :

• Le trafic intéressant n'est pas défini

• La définition de trafic intéressante n’est pas appliquée à l’interface

• L’interface n’est pas rendue compatible avec le numéroteur

Pour résoudre ce problème :

1. Vérifiez que la liste de numérotation est définie et que le groupe de numérotation (pointant vers la liste de numérotation) est configuré sous l'interface. Configurez une définition de trafic simple et intéressante :

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

   Après avoir résolu le problème de déconnexion fréquent, vous pouvez ajuster la définition de trafic intéressante en fonction de vos besoins.

2. Assurez-vous que dialer in-band est configuré sur les interfaces group-async et dialer. Cette commande n'est pas nécessaire sur les interfaces compatibles avec la numérotation, telles que l'interface BRI x et l'interface Serial x:23 (pour les PRI).

3. Réglez le délai d'inactivité du numéroteur sur la valeur souhaitée.

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

Informations connexes

• Page de support pour la technologie de ligne commuté
• Support technique - Cisco Systems