Composition et accès : Routage à établissement de connexion à la demande (DDR)

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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é.

Une autre question de veille commune de délai d'attente est que le lien ne déconnecte pas puisque le délai d'attente de veille n'expire jamais. Ceci peut avoir comme conséquence les taxations élevées pour les connexions qui sont chargées ont basé le temps où l'appel est connecté.

Ce document se concentre sur configurer et dépanner les questions de veille de délai d'attente.

Conditions préalables

Conditions requises

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

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

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 le problème lié au délai d'attente de veille :

  • Les appels obtiennent ont déconnecté toutes les deux minutes (120 secondes) après que la connexion soit établie.

    Cette déconnexion est normalement due au l'inactif-délai d'attente par défaut de 120 secondes étant activées, alors que la définition du trafic intéressant n'est pas définie ou n'est pas appliquée à l'interface. Bien que les commandes enables de dialer in-band transfèrent le délai d'attente de veille de 120 secondes sur l'interface, cette valeur n'apparaît pas dans la sortie de show running-configuration. Puisque l'inactif-délai d'attente par défaut n'est pas visible, un seconde débranchement 120 est souvent mal diagnostiqué.

  • Les appels obtiennent ont déconnecté des minutes chaque x après que la connexion soit établie.

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

  • Les appels déconnectent pr3maturément. C'est probablement dû à une valeur basse de durée d'inactivité du numéroteur combinée ou à une définition du trafic intéressant restrictive.

  • Les appels ne déconnectent pas. Ceci est probablement provoqué par une valeur élevée de durée d'inactivité du numéroteur avec une définition du trafic intéressant lâche.

Délais d'attente de veille

La commande de veille principale de délai d'attente est le dialer idle-timeout, qui est une commande de configuration d'interface pour async, group-async, le RNIS et les interfaces de numérotation. (Une autre commande utilisée généralement, le ppp timeout idle, qui est utilisé sur les interfaces d'accès virtuelles, est hors de portée de ce document. Pour plus d'informations sur le ppp timeout idle, référez-vous aux délais d'attente de Par-utilisateur de PPP de document.)

La commande du dialer idle-timeout {x} peut être configurée sur n'importe quelle interface numéroteur-capable. Les contre- contrôles de veille combien de temps la connexion peut être de veille (en quelques secondes) avant qu'elle soit terminée. Les contre- remises ou les comptes vers le bas basés sur ce que le routeur détermine en tant que « trafic intéressant ». Si le routeur voit le trafic intéressant (comme défini dans le dialer-list), il remet à l'état initial le temporisateur de veille, ou bien le temporisateur de veille continue à compter vers le bas. Quand le temporisateur atteint zéro, l'appel est déconnecté.

Répertoriés ci-dessous sont quelques points que vous devriez noter au sujet de cette commande :

  • Cette commande peut seulement être appliquée aux interfaces qui sont numéroteur-capables. Par défaut, toutes les interfaces RNIS (accès de base [BRI] et accès primaire [PRI]) sont numéroteur-capables, ainsi cette commande peuvent être ajoutées sans problèmes.

  • Interfaces asynchrones (par exemple, l'interface async x ou le group-async d'interface x) ne sont pas numéroteur-capable par défaut. Vous devez les rendre numéroteur-capables en présentant l'intrabande de commande dialer. Notez que les modèles virtuels (et donc les interfaces d'accès virtuel) ne sont pas numéroteur-capables, mais soyez point par point seulement. Par conséquent, ils ne peuvent pas utiliser cette commande à moins qu'exécutant la version de logiciel 12.2(4)T de ½ du ¿  de Cisco IOSïÂ, quand des améliorations à la structure de veille de délai d'attente ont été incluses.

  • Vous pouvez seulement configurer le dialer idle-timeout après avoir écrit l'ordre de dialer in-band sur l'interface asynchrone.

  • Sur une interface numéroteur-capable (c'est-à-dire, le RNIS ou async avec le dialer in-band), le délai d'attente de veille par défaut est de 120 secondes (deux minutes). À moins que vous configuriez explicitement l'inactif-délai d'attente de commande dialer avec une valeur du dépassement de durée de veille différente, la valeur par défaut est utilisée.

    Remarque: L'inactif-délai d'attente par défaut n'est pas affiché dans la configuration parce que c'est le par défaut. Utilisez la commande de show dialer de déterminer si un délai d'attente de veille est imposé sur l'interface.

  • Si vous voulez que les utilisateurs puissent rester connecté jusqu'à ce qu'ils choisissent de déconnecter, utilisez la commande du dialer idle-timeout 0. L'option zéro pour le dialer idle-timeout a été introduite dans le Logiciel Cisco IOS version 12.1(3)T, et place un délai d'attente d'infini.

Le trafic intéressant

Avec le Routage à établissement de connexion à la demande (DDR), tout le trafic est classifié comme intéressant ou inintéressant. Si le trafic est intéressant, alors le routeur se connecte au pair. Si le trafic n'est pas intéressant puis l'appel n'est pas connecté. Cependant, pour les connexions qui sont déjà connectées, le trafic intéressant a un but différent. Il est utilisé pour remettre à l'état initial le délai d'attente de veille de nouveau à la valeur maximale (configurée avec la commande de dialer idle-timeout). Le moment où un rapport est établi, le compteur de durée d'inactivité commence à diminuer. Une fois que le routeur reçoit un paquet qui apparie la définition du trafic intéressant, le compteur de durée d'inactivité est remis à l'état initial de nouveau à la valeur maximale.

Trafiquez qui est considéré intéressant est défini par la commande du dialer-list {n} (en mode de configuration globale), où {n} apparie le nombre dans l'appel de procédure du dialer-group {n} sous la configuration d'interface.

Il y a deux méthodes pour définir le trafic intéressant. La méthode simple (utilisant seulement la commande de dialer-list) spécifie un protocole entier (tel que l'IP ou l'IPX) comme intéressant ou inintéressant. Cependant, si vous le besoin donnez une définition du trafic intéressant granulaire (par exemple, si le trafic http est intéressant, mais le trafic de telnet n'est pas) que vous devez utiliser la commande de dialer-list en même temps qu'une liste d'accès.

Référez-vous à la section configurant le délai d'attente et le trafic intéressant de veille pour plus d'informations sur configurer le trafic intéressant.

Spécifier la direction du trafic intéressant

Par défaut, le dialer idle-timeout est remis à l'état initial de nouveau au maximum par le trafic intéressant dans la direction sortante. Si seulement le trafic d'arrivée remet à l'état initial le délai d'attente de veille, alors utilisez le mot clé supplémentaire d'arrivée. Employez l'un ou l'autre de mot clé pour que le trafic en entrée et en sortie remette à l'état initial l'inactif-délai d'attente. Ceci a été introduit dans le Logiciel Cisco IOS version 12.1(1)T.

Avantages : En spécifiant cela que seulement le trafic d'arrivée remettra à l'état initial le temporisateur d'inactif de numéroteur, vous peut empêcher le trafic Internet inattendu de garder une connexion de veille d'être déconnecté.

Définir des délais d'attente du trafic intéressant et d'inactif

Le trafic intéressant doit être défini sur les deux fins d'un lien DDR. Même si le routeur recevant l'appel traite seulement des appels entrant et ne fait pas des appels sortants, nous devons encore définir le trafic intéressant.

La définition du trafic intéressant a un but différent pour des appels d'asynchrone entrant et des appels RNIS.

Pour des utilisateurs RNIS (correspondant à interface dialer X)

Les commandes de dialer-group et de dialer-list sont exigées sur l'interface de numérotation, indépendamment de, que vous vouliez imposer le délai d'attente de veille ou pas. Les commandes de dialer-group et de dialer-list sont nécessaires sur l'interface de numérotation pour éviter des échecs d'encapsulation. Cette condition requise est seulement pour des utilisateurs RNIS et pas pour les utilisateurs asynchrones et l'interface asynchrone du groupe.

Pour imposer un délai d'attente de veille, ajoutez les commandes de dialer in-band et de dialer idle-timeout. Cependant, si le dialer in-band est configuré mais le dialer idle-timeout n'est pas, puis le délai d'attente de veille se transférera sur deux minutes pour des utilisateurs RNIS.

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

Pour des utilisateurs RNIS (correspondant à interface bri X et à interface x:23 séquentiels)

Toutes les interfaces physiques RNIS sont DDR activé par défaut. Ceci signifie que le dialer in-band est déjà activé sur cette interface. Pour imposer le délai d'attente de veille, ajoutez la commande de dialer idle-timeout. Cependant, si le dialer in-band est configuré mais le dialer idle-timeout n'est pas, puis le délai d'attente d'inactif se transfère sur deux minutes pour des utilisateurs RNIS.

Les commandes de dialer-group et de dialer-list sont exigées sur cette interface, indépendamment de, que vous vouliez imposer l'inactif-délai d'attente ou pas. Les commandes de dialer-group et de dialer-list sont nécessaires sur l'interface pour éviter des échecs d'encapsulation. Cette condition requise est seulement pour des utilisateurs RNIS, pas pour les utilisateurs asynchrones et l'interface asynchrone de groupe.

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

Pour des utilisateurs asynchrones (correspondant pour relier group-async X)

Pour imposer un délai d'attente de veille pour des utilisateurs asynchrones, configurez les commandes suivantes dans l'interface asynchrone du groupe :

  • dialer in-band

  • dialer idle-timeout

  • dialer-group

Le dialer-list correspondant est également nécessaire. Les commandes de dialer-group et de dialer-list spécifient le trafic intéressant sur l'interface asynchrone du groupe.

Pour des utilisateurs asynchrones, le trafic intéressant est seulement utilisé pour remettre à l'état initial le délai d'attente de veille. Si le trafic intéressant n'est pas défini, alors des utilisateurs seront déconnectés après que la durée d'inactivité du numéroteur (par défaut 120 secondes) expire, indépendamment de s'ils passent le trafic sur le lien. Avec une définition du trafic intéressant, le serveur d'accès à distance (NAS) identifiera ces paquets et remettra à l'état initial le délai d'attente de veille, de ce fait déconnectant l'utilisateur seulement quand il y a un lien véritablement de veille.

Vous pouvez modifier le trafic intéressant tels que, par exemple, seulement le trafic de HTTP (Web) est intéressant. Dans une telle situation, si l'utilisateur ne parcourt pas le Web pendant 300 secondes (ou pour le délai d'attente d'inactif de numéroteur indiqué), ils sont déconnectés. Configurez le trafic intéressant selon les structures de trafic de vos utilisateurs.

Si vous voulez que vos utilisateurs asynchrones puissent rester connecté jusqu'à ce qu'ils choisissent de déconnecter, alors retirez les commandes suivantes de l'interface asynchrone du groupe, suivant les indications de la configuration :

  • dialer in-band

  • dialer idle-timeout

  • dialer-group

Vous pouvez également placer le délai d'attente de veille à l'infini utilisant la commande du dialer idle-timeout 0. L'option zéro pour la durée d'inactivité du numéroteur a été introduite dans le Logiciel Cisco IOS version 12.1(3)T, et elle place un délai d'attente d'infini.

Configurer le délai d'attente et le trafic intéressant de veille

Cette section discute comment vous pouvez configurer le délai d'attente et le trafic intéressant de veille sur le routeur. Vous pouvez s'appliquer cette configuration à toutes les interfaces DDR-activées, comme :

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

Vous pouvez également utiliser un serveur d'Authentification, autorisation et comptabilité (AAA) pour fournir des délais d'attente de par-utilisateur. Référez-vous au pour en savoir plus de délais d'attente de Par-utilisateur de PPP de document.

Exemple de configuration

L'exemple de configuration suivant inclut une définition simple du trafic intéressant. Cet exemple particulier indique 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 l'un ou l'autre de direction (le par défaut) pour remettre à l'état initial le délai d'attente de veille de nouveau à 900 secondes. Par conséquent, si aucun trafic IP ne passe dans l'un ou l'autre de direction pendant 15 minutes, le routeur déconnecte la ligne parce que le délai d'attente de veille a expiré.

Remarque: Si vous exécutez un protocole de routage au-dessus de ce lien DDR, le trafic périodique garde le lien indéfiniment. Par conséquent, la définition du trafic intéressant affichée ci-dessus n'est pas recommandée pour des liens avec les protocoles de routage (ou tout autre trafic périodique) s'exécutant à travers elle.

Utilisant des Listes d'accès

L'exemple suivant affiche un routeur avec l'interface d'accès de base (BRI) qui reçoit l'appel et a activé la commande de dialer idle-timeout avec le mot clé d'arrivée. Cette commande permet seulement le trafic d'arrivée qui se conforme à la liste d'appels pour remettre à l'état initial le temporisateur d'inactif de numéroteur. Ici, seulement on permet au le trafic TCP sur le port 80 (le trafic http) pour remettre à l'état initial le délai d'attente de veille de nouveau à dix minutes (600 secondes). Par conséquent, si l'utilisateur final ne parcourt pas le Web pendant dix minutes, la connexion est déconnectée.

Utilisant 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

Utilisant des interfaces asynchrones

Des interfaces asynchrones DDR-ne sont pas activées par défaut, ainsi l'utilisation du dialer in-band les rend DDR-activées.

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 de veille de délai d'attente

Avant le Logiciel Cisco IOS version 12.2(4)T, le temporisateur d'inactif de numéroteur pourrait seulement être remis à l'état initial pour le trafic intéressant sur les interfaces qui numéroteur-ont été activées (par exemple, BRI, PRI, et group-async avec l'ordre de dialer in-band). Des délais d'attente de veille n'ont pas pu être appliqués aux utilisateurs connectés aux interfaces de modèle virtuel.

En date du Logiciel Cisco IOS version 12.2(4)T, la caractéristique de Fonction Customer Profile Idle Timer Enhancements for Interesting Traffic fournit de nouvelles commandes et fonctionnalité que le temporisateur de veille d'adresse émet pour les sessions virtuelles du réseau commuté d'accès (VPDN), qui utilisent les interfaces virtuelles d'accès (projeté) et se fondent sur le mécanisme de temporisateur d'inactif de PPP.

Vérifier le délai d'attente de veille

Exécutez les étapes suivantes pour vérifier et dépanner le comportement de veille de délai d'attente :

  1. Assurez-vous que l'appel est connecté utilisant l'ordre d'utilisateur d'exposition.

  2. Utilisez le délai d'attente de show caller, le show dialer, et l'utilisateur de show caller pour déterminer si le délai d'attente de veille est correctement assigné à l'interface connectée. Si vous exécutez les plusieurs temps de commandes show, vous devriez voir l'heure de déconnecter la diminution.

  3. Le trafic intéressant initié (comme défini par dialer-list x) à travers le lien. Vous devriez regarder la configuration en cours pour déterminer la définition du trafic intéressant.

  4. Exécutez le délai d'attente de show caller, le show dialer, et l'utilisateur de show caller de nouveau pour déterminer si le délai d'attente de veille a été remis à l'état initial. Si ceci ne se produit pas, alors ou le trafic intéressant n'est pas défini correctement (utilisant le dialer-list) ou il n'a pas été appliqué à l'interface (utilisant le dialer-group).

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

  • délai d'attente de show caller - Affiche le délai d'attente absolu et de veille installé, aussi bien que combien d'heure avant l'utilisateur est déconnectée par tous les délais d'attente.

  • show dialer [nombre de type d'interface] - Affiche les informations générales de diagnostic pour des interfaces configurées pour le DDR. Si le numéroteur a monté correctement, l'état du numéroteur est couche liaison de données vers le haut de message apparaît. Si la couche physique haute apparaît, ceci signifie que la ligne protocole a été soulevée, mais le protocole de contrôle de réseau (NCP) n'a pas. La source et les adresses de destination du paquet qui a initié la composition sont affichées dans la ligne raison d'appel. Cette commande affiche également la configuration et le temps du temporisateur avant les temps de connexion.

  • détail de nom d'utilisateur d'utilisateur de show caller - Affiche des paramètres pour l'utilisateur particulier tel que l'adresse IP assignée, des paramètres d'ensemble de PPP et de PPP, et ainsi de suite. Si votre version de logiciel de Cisco IOS ne prend en charge pas cette commande, utilisez l'ordre d'utilisateur d'exposition.

Pour des appels RNIS

Voici la configuration pour le routeur de côté réception avec une interface BRI liée à l'interface dialer 1 avec la commande du groupe rotatif de routeurs d'appels 1. Considérez que l'interface dialer 1 DDR-est activée utilisant l'intrabande de commande dialer.

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
 
 !

Exécutez les étapes suivantes pour vérifier le délai d'attente de veille :

  1. Assurez-vous que l'appel est connecté. Vous pouvez utiliser l'ordre d'utilisateur d'exposition de 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'attente de veille est appliqué à la connexion. Dans l'exemple ci-dessous, l'utilisateur Preet s'est connecté et s'est terminé sur l'interface dialer 1, et a obtenu l'adresse IP 10.1.1.2 du dialin de groupe. Permettez-maintenant nous vérifient que la connexion utilise un délai d'attente de veille 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
    

    L'heure de déconnecter compte vers le bas car aucun trafic intéressant ne passe sur le lien. Il n'y a eu aucun trafic intéressant passant dans l'un ou l'autre de direction pour les 43 dernières secondes. Par conséquent, l'utilisateur est déconnecté en 600 - 43 = 557 secondes. Le temps jusqu'à ce que le champ de débranchement commence comptant vers le bas une fois l'utilisateur est connecté et est remis à l'état initial au maximum quand 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'attente de veille est délai d'attente de show caller :

    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 affiche que le délai d'attente de veille maximum (en quelques minutes) configuré et le champ restant affiche le temps jusqu'au débranchement.

  3. Le trafic intéressant initié au pair. Nous initierons maintenant le trafic intéressant au pair. Veillez-vous pour regarder la configuration courante pour déterminer la définition du trafic intéressant précise. La liste d'accès 101 définit le Protocole ICMP (Internet Control Message Protocol) et le trafic TCP au port 80 comme intéressants. Par conséquent, nous cinglerons maintenant 10.1.1.2 (adresse IP que l'utilisateur Preet a négocié) 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'attente de veille a été remis à l'état initial. Utilisez le délai d'attente de show caller, le show dialer, et les ordres d'utilisateur de show caller de vérifier que le délai d'attente de veille a été remis à l'état initial :

    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 voir l'information en fonction de délai d'attente sur le nom d'utilisateur, est l'ordre d'utilisateur de show caller.

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'attente de veille n'est pas remis à l'état initial, poursuivez aux questions de délai d'attente d'inactif de dépannage de section.

Pour des appels asynchrones

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

 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.

Tout comme avec le RNIS, employez les utilisateurs d'exposition, le show dialer, et le délai d'attente de show caller pour vérifier le délai d'attente de veille.

Utilisez les utilisateurs d'exposition commandent de trouver l'interface et l'adresse IP le pair est connectée en fonction.

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 de show dialer (spécifiant l'interface juste déterminée) d'observer les valeurs de temporisateur :

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 de délai d'attente de show caller peut également afficher l'heure de déconnecter :

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 initierons maintenant le trafic intéressant. La liste d'accès 101 définit l'ICMP et le trafic TCP au port 80 (le trafic http) comme intéressant. Cinglez 10.1.1.3 (adresse IP que l'utilisateur Preet a négocié) du routeur pour remettre à l'état initial le délai d'attente de veille.

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é remis à l'état initial :

   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 montre que le trafic intéressant est correctement défini et est appliqué correctement. Alternativement, vous pouvez utiliser la commande de show dialer de vérifier les valeurs du dépassement de durée :

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 le show caller que l'utilisateur {nom d'utilisateur} a détaillé la commande de 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 questions de veille de délai d'attente

Symptôme : Les débranchements d'appel pr3maturément ou l'appel ne déconnecte pas du tout

Si les débranchements d'appel inopinément, ou d'appel les débranchements jamais, vérifient la durée d'inactivité du numéroteur et la définition du trafic intéressant. Vous pouvez utiliser la commande de paquet de numéroteur de débogage de voir si un paquet particulier est intéressant ou pas. 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 hellos OSPF sont inintéressants par liste d'accès 101, alors que le deuxième paquet est intéressant par liste d'accès 101. Dépannez comme suit :

  1. Ajustez la durée d'inactivité du numéroteur en configuration de l'interface du numéroteur. Le par défaut est de 120 secondes, mais vous pouvez souhaiter soulever ou diminuer cette valeur selon vos besoins.

    router(config-if)#dialer idle-timeout 

    Remarque: Si l'appel ne déconnecte pas, vérifiez que l'option zéro pour la durée d'inactivité du numéroteur (introduite dans le Logiciel Cisco IOS version 12.1(3)T) n'est pas placée.

  2. Changez la définition du trafic intéressant (configurée avec la commande de dialer-list). Si les débranchements d'appel pr3maturément, vous peuvent souhaiter définir le trafic intéressant plus lâchement (refusez quelques uns et laissez tout autrement). Si l'appel ne déconnecte jamais, changez votre définition du trafic intéressant pour être plus restrictif (laissez quelques uns et refusez tout autrement).

    Conseil : Si votre lien ne déconnecte pas, soyez sûr de définir le trafic de protocole de routage (ou tout autre trafic périodique) comme inintéressant. Ceci empêche des hellos périodiques de remettre à l'état initial le délai d'attente de veille. Voici une définition du trafic intéressant d'échantillon :

    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.
    
    

    Le pour en savoir plus, se rapportent au document Technologie d'appel commuté : Aperçus et explications.

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

Un autre problème est que l'appel déconnecte des secondes chaque « x » (le plus souvent 120 secondes). Dans certaines situations, même si le trafic transmet le lien, le DDR ne remet pas à l'état initial le délai d'attente de veille. C'est vraisemblablement dû à :

  • le trafic intéressant n'étant pas défini

  • la définition du trafic intéressant non appliquée à l'interface

  • l'interface non rendue numéroteur-capable

Pour résoudre ceci :

  1. Vérifiez que le dialer-list est défini et le dialer-group (indiquant le dialer-list) est configuré sous l'interface. Configurez une définition du trafic intéressant simple :

    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 que vous obteniez la question fréquente de débranchement résolue, vous pouvez ajuster la définition du trafic intéressant pour adapter à vos besoins.

  2. Assurez-vous que le dialer in-band est configuré sur le group-async et les interfaces de numérotation. Cette commande n'est pas nécessaire sur les interfaces numéroteur-capables comme l'interface bri X et l'interface x:23 séquentiel (pour PRIs).

  3. Ajustez la durée d'inactivité du numéroteur à la valeur désirée.

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

Informations connexes


Document ID: 23423