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é.
Aucune spécification déterminée n'est requise pour ce document.
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.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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
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
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.
Procédez comme suit pour vérifier et dépanner le comportement de délai d'inactivité :
Vérifiez que l'appel est connecté à l'aide de la commande show user.
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.
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.
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.
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é :
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
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.
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#
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é.
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
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 :
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.
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.
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 :
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.
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).
Réglez le délai d'inactivité du numéroteur sur la valeur souhaitée.
router(config-if)#dialer idle-timeout 900