Dépannage de modems
Contenu
Introduction
Les communications par modem analogique modernes sont devenues très complexes. Les technologies les plus récentes ne reposent plus sur une configuration de base simple, mais s'attendent à ce que le cloud de la compagnie de téléphone (Telco) repose sur la technologie numérique de bout en bout. Cela a entraîné une augmentation spectaculaire de la bande passante au prix d'une complexité accrue. La plupart des connexions d'appels par modem dépendent désormais des composants présentés dans le schéma suivant :
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
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Informations générales
Les boucles locales fournissent une interface sans erreur avec le cloud Telco. Un client distant peut avoir une boucle analogique ou numérique et les serveurs d'accès sont généralement conçus pour fonctionner sur une boucle numérique. Si l'une des boucles échoue, la connectivité entre les extrémités échoue également.
Le cloud Telco transmet les signaux numériques de bout en bout de manière transparente. Dans le cas où une liaison au milieu ne répond pas à cette exigence (par exemple, les conversions analogiques à numériques supplémentaires, les compressions des canaux vocaux, les pertes de données sporadiques, etc.), la connectivité du modem est susceptible d'être affectée, même si aucune des deux extrémités ne voit rien de mal avec leur boucle.
En résumé, le faible taux de réussite des appels (CSR), les vitesses de connexion médiocres, les trains fréquents, etc., ne sont pas nécessairement les symptômes d'une conception de modem médiocre. Ce ne sont peut-être pas les modems qui doivent être vérifiés en premier.
Dépannage
Cette section répertorie les problèmes courants liés aux modems et fournit des informations sur la façon de les résoudre.
Les clients qui placent des appels modem et numériques signalent des problèmes de connectivité
Parfois, les clients qui placent des appels modem (V.92, V.90, V.34) et numériques (RNIS, Commuté 56, V.110 ou V.120) signalent des problèmes de connectivité.
Comme indiqué dans l'introduction, les protocoles de modem sont transmis en plus de la technologie numérique. En raison de leur origine dans des communications analogiques plus sujettes aux erreurs, les protocoles de modem sont plus robustes et adaptables aux erreurs de ligne. Le problème n'est peut-être pas très visible, mais il est toujours là. Tout d'abord, dépannez les appels numériques :
-
Vérifiez les statistiques du contrôleur et de l'interface pour vous assurer que la ligne entre le serveur d'accès et l'échange Telco le plus proche est exempte d'erreurs. Pour les clients et les serveurs d'accès qui utilisent l'équipement Cisco, vous pouvez vérifier les statistiques aux niveaux contrôleur et interface. Pour les produits tiers, suivez la documentation du fournisseur ou obtenez un analyseur de protocole. Les statistiques doivent également être vérifiées côté Telco (au cas où le problème n'affecterait que les signaux envoyés à l'échange Telco le plus proche);
-
Si les compteurs sont propres, mais que la ligne n'est pas terminée directement dans l'échange Telco (extenseurs ou échanges de lignes intermédiaires sont concernés), vérifiez que le chemin complet vers l'échange Telco est erroné ;
-
Une fois la ligne confirmée propre, vérifiez la signalisation. Pour connaître les techniques de dépannage des signaux CAS (Channel Associate Signals), reportez-vous à Dépannage des connexions RNIS.
Pour plus d'informations, consultez Vue d'ensemble de la qualité générale des lignes de modem et NAS.
Remarque : effectuez tous ces contrôles avant de tenter de dépanner votre modem
Les clients avec certains comptes ne peuvent pas se connecter
Les clients disposant de certains comptes, ou ceux qui appellent depuis certains emplacements, ne peuvent pas se connecter. Certaines marques de modem tentent de se connecter, sans résultats satisfaisants, tandis que les clients d'autres sites ne semblent pas affectés.
Il est peu probable que ces problèmes soient causés par les modems eux-mêmes. Les comptes (ID, noms et mots de passe des numéros d'appel et d'appel) sont gérés par des protocoles ou des applications qui se trouvent au-dessus des protocoles de modem (PPP, AAA, RPMS, etc.). Il peut ne pas être utile de dépanner le modem si les protocoles ou les applications doivent être supprimés ou modifiés.
Pour continuer, essayez de résoudre les problèmes suivants :
-
Point to Point Protocol (PPP). Voir Technologie de numérotation : Techniques de dépannage.
-
Authentification, autorisation et comptabilité (AAA).
-
Serveur Resource Pool Manager (RPMS).
À moins que des fonctionnalités spéciales ne soient impliquées (comme l'utilisation de l'ID du numéro appelant ou du numéro appelé), le problème semble se trouver quelque part dans le cloud Telco. Si vous déplacez le même modem vers un autre emplacement, un seul facteur change : le chemin d'appel. Si la modification est suffisante pour résoudre le problème, les points d'extrémité sont configurés correctement et vous n'avez peut-être pas besoin de dépanner plus loin. La ligne Telco entre le serveur d'accès et l'échange Telco le plus proche est probablement acceptable, car seuls des clients spécifiques ont le problème. Une solution de contournement possible est de trouver des paramètres de modem, qui permettraient aux modems de se connecter, malgré les problèmes Telco. Pour plus d'informations, consultez Modems à réglage fin.
Remarque : Cette solution de contournement n'est pas une solution. Pour trouver une solution, contactez votre opérateur de téléphonie afin d'étudier la ligne entre le client et l'échange Telco le plus proche, et plus loin sur le chemin d'appel
Les clients de certains sites signalent une mauvaise connectivité
Parfois, les clients de certains sites signalent une mauvaise connectivité. Cela inclut des vitesses de connexion faibles, souvent des retrains, des taux d'erreur élevés, etc. Certaines marques de modem tentent de se connecter sans résultats satisfaisants, tandis que d'autres ne semblent pas affectées.
À moins que des fonctionnalités spéciales ne soient impliquées (comme l'utilisation de l'ID du numéro appelant ou du numéro appelé pour RPMS), le problème semble se trouver quelque part dans le cloud Telco. Lorsque vous utilisez le même modem à un autre emplacement, un seul facteur change : le chemin d'accès à l'appel (dans le cloud Telco, les chemins d'accès aux appels entrants et sortants peuvent différer). Si la modification est suffisante pour résoudre le problème, les points d'extrémité sont configurés correctement et vous n'avez peut-être pas besoin de dépanner plus loin. La ligne Telco entre le serveur d'accès et l'échange Telco le plus proche est probablement correcte, car seuls des emplacements spécifiques ont le problème. Le problème est probablement dû à l’échange de services téléphoniques le plus proche du client. Vérifiez si les appels en question arrivent au serveur d'accès, comme expliqué dans Technologie d'accès commuté : Techniques de dépannage.
Si l'appel passe, et que la ligne Telco entre le client et l'échange Telco le plus proche semble également propre (par exemple, si le client ne voit pas le problème lorsqu'il appelle d'autres numéros locaux, tels que le San-Jose Dial-In Lab ou le Australie Dial-In Lab), vous devrez peut-être vérifier l'intégralité du chemin d'appel pour dépanner plus loin.
Pour vérifier le chemin d'appel :
-
Tout d’abord, vérifiez que le câblage intérieur est une source possible de problème.
-
Raccordez deux modems clients à l'arrière sur le câblage (pour faire passer un appel à un modem sans attendre la tonalité, utilisez ATX3D et pour faire répondre l'autre modem sans attendre l'utilisation ATA du signal de sonnerie). Une fois que les modems se sont formés et sont passés en mode données, génèrent du trafic sur la ligne, puis utilisent la séquence d'échappement (généralement Hayes ++ ou TIES +++AT) pour basculer les modems en mode de commande, et vérifient les paramètres de ligne (rapport signal/bruit [SNR], qualité du signal, retrains, etc.).
-
Déconnectez tous les équipements connectés à la même ligne téléphonique en parallèle avec le modem.
-
Exécutez un cordon téléphonique (de préférence quatre paires torsadées non blindées [UTP]) depuis l'interface réseau jusqu'au modem.
-
-
Assurez-vous que le modem client exécute le dernier micrologiciel de son fabricant (conformément aux protocoles pris en charge par le modem serveur). Vérifiez également si vous souhaitez reconfigurer le modem client afin qu'il puisse se connecter de manière plus robuste. Voir Modems à réglage fin pour plus de détails. Par exemple, vous pouvez essayer de limiter la vitesse DCE du modem client. S'il s'agit d'un client Rockwell, essayez d'utiliser AT+MS=56 1 300 42 000 afin d'essayer une connexion K56Flex à 42 Kbits/s. Vous pouvez également essayer +MS=11,1,300,19200 pour une connexion V.34 à 19,2 Kbits/s.
-
Activez la journalisation du modem sur le client
pour une analyse plus approfondie. -
Si vous utilisez Microsoft Windows, vérifiez le code
de déconnexion. -
Vérifiez les diagnostics de connexion avec un modem USR AT i11
ou un modem Lucent AT i11 . -
Si vous utilisez un Winmodem piloté par le CPU, demandez au fournisseur du modem de fournir la commande AT existante pour dépanner une connexion. Certains fournisseurs de modems utilisent le code de diagnostic UnIModem de Microsoft (AT#UG).
L'analyse du chemin d'appel peut nécessiter une implication plus étroite de votre opérateur téléphonique. Pour identifier les problèmes potentiels, vérifiez les paramètres de connexion des appels spécifiques à l'aide de la commande show modem Operational-status, comme indiqué dans Vue d'ensemble de la qualité générale des lignes du modem et du NAS. Pour plus d'informations, consultez cette note de version. Une solution de contournement possible est de trouver des paramètres de modem, ce qui permettrait aux modems de se connecter même en dépit des problèmes Telco. Voir Modems à réglage fin.
Les clients de certains emplacements se connectent, mais plus tard, l'appel est abandonné
Bien que les clients de certains sites puissent se connecter, l'appel est abandonné après un certain temps. Certaines marques de modem tentent de se connecter sans résultats satisfaisants, tandis que d'autres ne semblent pas affectées.
À moins que des fonctionnalités spéciales ne soient impliquées (par exemple, ID d'appel ou d'appel pour RPMS), le problème semble se trouver quelque part dans le cloud Telco. Si vous utilisez le même modem à un autre emplacement, un seul facteur change : le chemin d'appel (rappelez-vous également que dans le cloud Telco, les chemins d'accès des appels entrants et sortants peuvent différer). Si la modification est suffisante pour résoudre le problème, le serveur d'accès est susceptible d'être configuré correctement et peut ne pas nécessiter de dépannage supplémentaire. La ligne Telco entre le serveur d'accès et l'échange Telco le plus proche est sans doute également correcte, puisque seuls des emplacements spécifiques ont rencontré le problème. Pour vous assurer que le client d'accès commuté n'est pas la racine du problème, vérifiez que :
-
Le client n’initie pas la déconnexion PPP. Voir Technologie de numérotation : Techniques de dépannage.
-
Le client n'initie pas la déconnexion du modem. Les raisons de la déconnexion du modem dans le journal des modems sont expliquées dans ces documents :
-
Le client n’initie pas la déconnexion RNIS. Voir cause de déconnexion RNIS pour plus d'informations. (Voir aussi note 3.)
Si l'enquête révèle que les appels sont déconnectés en raison d'erreurs de connectivité de montage, essayez de trouver des paramètres de modem qui permettraient aux modems de se connecter malgré les problèmes Telco. Pour plus d'informations, consultez Modems à réglage fin.
Remarque : Cette solution de contournement n'est pas une solution. Pour trouver une solution, contactez votre opérateur de téléphonie afin d'étudier la ligne entre le client et l'échange Telco le plus proche, et plus loin sur le chemin d'appel.
Certains modèles de modems ne peuvent pas se connecter, tandis que d'autres situés aux mêmes emplacements peuvent
Parfois, certains modèles de modems ne peuvent pas se connecter, alors que d'autres modèles situés au même endroit peuvent le faire. Cela peut parfois être une question de compatibilité des fournisseurs. Pour savoir pourquoi exactement la déconnexion se produit, consultez le journal du modem pour connaître les raisons de la déconnexion. (Voir aussi note 1) :
La solution de contournement possible consiste à identifier les paramètres permettant aux modems d'éviter le problème de compatibilité. Pour plus d'informations, consultez Modems à réglage fin. Si aucune solution de contournement n'est utile (par exemple, la désactivation de toutes les fonctionnalités propriétaires), contactez le fournisseur du modem client pour obtenir de plus amples informations sur le dépannage.
Assurez-vous de supprimer PPP. Le modem client doit composer un numéro à partir d'un programme de terminal, tel que Windows HyperTerminal, à l'aide des commandes AT. Configurez le serveur d'accès de sorte qu'il ne démarre pas automatiquement le protocole PPP pour tous les utilisateurs, mais autorise une connexion exec (par exemple, via le mode asynchrone interactif sur l'interface group-async et autoselect PPP sur les lignes). Cela permet au client de contrôler et de récupérer directement des informations utiles à partir du modem et, une fois connecté, il peut générer du trafic exec pour mettre la connexion en évidence.
Sur le terminal client, commencez à enregistrer la session (sélectionnez Transfert > Capture Text dans HyperTerminal).
-
Recueillez les informations suivantes à partir du modem client :
-
ATI, ATI0, ATI1, ATI2.
-
AT&V0, AT&V1, AT&V2.
Remarque : certaines commandes peuvent renvoyer une ERREUR sur certains modems. Vous pouvez ignorer de telles erreurs.
-
-
Rétablissez les paramètres d'usine par défaut du modem (ou les paramètres souhaités) et assurez-vous que le haut-parleur est toujours allumé :
-
AT&F
-
ATL2M2
-
-
Commencez à enregistrer l'appel dans un fichier .WAV. Pour ce faire sous Windows NT, sélectionnez Démarrer > Programmes > Accessoires > Multimédia > Magnétophone.
Le bouton rouge démarre l'enregistrement, mais ne le touche pas avant que vous commenciez à composer. Dans la fenêtre HyperTerminal, commencez à composer le numéro.
-
ATDT <numéro>
Si l'appel ne se connecte pas ou si la modulation requise n'est pas négociée, arrêtez l'enregistrement après l'affichage de NO CARRIER dans la fenêtre du terminal. Si le problème est que l'appel se connecte comme souhaité, mais qu'après un certain temps il est déconnecté, alors continuez à enregistrer le fichier .WAV. Vous devez appuyer à nouveau sur le bouton d'enregistrement rouge toutes les minutes si vous utilisez l'enregistreur de son.
Si l'appel se connecte, soit dans la modulation souhaitée, soit dans une modulation non désirée, collectez les informations intéressantes suivantes lors de la connexion.
-
côté serveur, les informations show modem Operational-status (MICA, NextPort) ou modem at-mode / at@e1 (Microcom).
-
côté client, passez en mode AT via +++ et obtenez ATI6, AT&V1, AT&V2. Vous pouvez revenir en ligne avec ATO.
-
-
Une fois l'appel terminé, enregistrez le fichier Magnétophone. Pour ce faire, sélectionnez Fichier > Enregistrer sous > Modifier le format.
Format : PCM
Attributs : 8,000 kHz, 8 bits, Mono 7 kbit/s
Nom de fichier: filename.wav
Envoyez les informations collectées au centre d'assistance technique Cisco (TAC) pour analyse.
Des modèles spécifiques de modems présentent une connectivité médiocre
Les modèles spécifiques sont confrontés à une connectivité médiocre en termes de faibles vitesses de connexion, souvent de rétrains, de taux d'erreur élevés, etc. D'autres modèles situés à ces mêmes emplacements ont une bonne connectivité.
Cela peut parfois être une question de compatibilité des fournisseurs. Pour savoir pourquoi exactement la déconnexion se produit, consultez le journal du modem pour connaître les raisons de la déconnexion. (Voir aussi note 1) :
L'enquête suivante peut également éclairer les raisons de l'échec de certains modems clients :
-
Tout d’abord, vérifiez que le câblage intérieur est une source possible de problème.
-
Raccordez deux modems clients à l'arrière sur le câblage (pour faire passer un appel par un modem sans attendre la tonalité, utilisez ATX3D et pour faire répondre l'autre modem sans attendre le signal de sonnerie, utilisez ATA). Une fois que les modems se sont formés et sont passés en mode données, génèrent du trafic sur la ligne, puis utilisent la séquence d'échappement (généralement Hayes ++ ou TIES +++AT) pour basculer les modems en mode de commande, et vérifier les paramètres de ligne (SNR, qualité du signal, retrains, etc.).
-
Déconnectez tous les équipements connectés à la même ligne téléphonique en parallèle avec le modem.
-
Exécutez un cordon téléphonique (de préférence quatre ou un câble à paires torsadées non blindées) depuis l'interface réseau jusqu'au modem.
-
-
Assurez-vous que le modem client exécute le dernier micrologiciel de son fabricant (conformément aux protocoles pris en charge par le modem serveur). Reconfigurez également le modem client de sorte qu'il puisse se connecter de manière plus robuste. Voir Modems à réglage fin pour plus de détails. Par exemple, vous pouvez essayer de limiter la vitesse DCE du modem client. S'il s'agit d'un client Rockwell, essayez AT+MS=56,1,300,42000 afin d'essayer une connexion K56Flex à 42 Kbits/s. Vous pouvez également essayer +MS=11,1,300,19200 pour une connexion V.34 à 19,2 Kbits/s.
-
Activez la journalisation du modem sur le client
pour une analyse plus approfondie. -
Si vous utilisez Microsoft Windows, vérifiez le code
de déconnexion. -
Vérifiez les diagnostics de connexion avec un modem USR AT i11
ou un modem Lucent AT i11 . -
Si vous utilisez un Winmodem piloté par le CPU, demandez au fournisseur du modem de fournir la commande AT existante pour dépanner une connexion. Certains fournisseurs de modems utilisent le code de diagnostic UnIModem de Microsoft (AT#UG).
Une solution de contournement possible est de trouver les paramètres, ce qui permettrait aux modems d'éviter le problème de compatibilité. Voir Modems de réglage fin. Si aucune solution de contournement n'est utile (par exemple, la désactivation des retrains sur les modems internes du serveur d'accès), contactez le fournisseur du modem client pour résoudre les problèmes.
Modèles spécifiques de connexion de modems, mais plus tard l'appel est abandonné
Certains modèles de modems peuvent se connecter, mais l'appel est abandonné ultérieurement. D'autres modèles situés aux mêmes emplacements restent connectés.
Cela peut parfois être une question de compatibilité des fournisseurs. Pour savoir pourquoi la déconnexion se produit, vérifiez les points suivants (voir aussi la note 1) :
-
Indique si une terminaison PPP a été demandée. Voir Technologie de numérotation : Techniques de dépannage.
-
Indique si la terminaison du modem a été demandée. Les raisons de déconnexion du modem dans le journal des modems sont expliquées à l'adresse :
-
Cause de déconnexion RNIS. (Voir aussi note 3).
Si l'enquête révèle que les appels sont déconnectés en raison d'erreurs de connectivité de montage, une solution de contournement possible est d'obtenir les derniers microprogrammes ou paramètres du modem, ce qui permet aux modems d'éviter le problème de compatibilité. Pour plus de détails et une matrice de compatibilité, voir Modems à réglage fin. Si la solution de contournement ne vous aide pas (par exemple limiter la vitesse maximale manuellement ou en utilisant un plafonnement agressif du modem), contactez le fournisseur du modem client pour résoudre les problèmes.
Échec de connexion des appels à certains numéros (DS1 ou serveur d'accès)
Les appels de différents emplacements avec différents modèles de modem vers certains numéros (DS1 ou serveur d'accès) ne parviennent pas à se connecter. Les mêmes clients situés aux mêmes emplacements se connectent facilement à d'autres numéros locaux (tels que le laboratoire de numérotation San-Jose ou le laboratoire de numérotation Australie).
Vérifiez les statistiques aux niveaux contrôleur et interface pour les erreurs (voir l'introduction pour plus d'informations). Par exemple, si le serveur d'accès termine plus d'une ligne Telco, assurez-vous que toutes les lignes sont synchronisées (généralement, les lignes doivent être prises du même fournisseur), comme expliqué dans Synchronisation d'horloge. La vérification doit être effectuée à la fois sur le serveur d'accès et sur le côté Telco (si le problème affecte les signaux provenant du serveur d'accès à l'échange Telco le plus proche, le serveur d'accès ne peut signaler aucune erreur). Avant de poursuivre le dépannage du modem, assurez-vous qu'il n'y a pratiquement aucune erreur au niveau de la couche T1/E1.
Ensuite, assurez-vous que les appels atteignent le serveur d'accès, comme expliqué dans la technologie d'accès commuté : Techniques de dépannage. Si les appels arrivent, vérifiez la commande show controller <e1|t1> call-counters. Pour certains problèmes Telco, certains canaux DS0 signalent généralement des temps de connexion très faibles et un très grand nombre d’appels.
Pour le dernier test, la compagnie de téléphone doit permettre au serveur d’accès de s’appeler par l’intermédiaire de l’échange de la compagnie de téléphone. Vérifiez également qu'il n'y a pas de conversions analogiques/numériques superflues dans le chemin entre le serveur d'accès et le commutateur. Cela produit un écho proche de la fin, que les modems numériques peuvent ne pas être en mesure de gérer, et empêche les connexions de modem PCM de fonctionner. Lorsque vous provisionnez une liaison T1 ou E1 vers le Telco, assurez-vous qu'il existe un chemin purement numérique entre le serveur d'accès et le commutateur du Telco. C'est le cas s'il existe une liaison directe T1 ou E1 vers le commutateur. Si les canaux sont routés par une banque de canaux, par exemple, et convertis ainsi du numérique à l'analogique, puis de nouveau, l'intégrité numérique des canaux est perdue. Cela signifie que :
-
Impossible d'utiliser la modulation par modem PCM (V.90, K56Flex ou X2). Seules les versions V.34 et ultérieures peuvent être utilisées, et même les performances V.34 peuvent être altérées.
-
Les services numériques tels que les données commutées 56 ou RNIS ne peuvent pas être fournis.
-
Les modems numériques, tels que MICA, ne fonctionneront pas correctement, en raison du niveau élevé d'écho proche de l'extrémité.
Les symptômes typiques sur MICA avec une conversion A-D proche de la fin sont les suivants :
-
Pas de porteuse PCM (K56Flex ou V.90).
-
Support médiocre (19.2 - 26.4) V.34 pour les appels locaux.
-
Les appels longue distance ne peuvent pas être formés en V.34, V.32bis ou V.32. Cependant, si le modem client est plafonné à 2 400 bits/s V.22bis, il peut s'entraîner correctement.
Note : V.22bis ne nécessite pas d'annulation d'écho.
Si la compagnie de téléphone ne peut pas fournir un chemin purement numérique vers le serveur d'accès, il n'est pas recommandé d'utiliser MICA (ou d'autres modems numériques) et il est préférable d'utiliser des modems V.34 analogiques, tels que Sara (modems Microcom analogiques intégrés dans les routeurs Cisco 2600 ou 3600).
Pour déterminer si le chemin vers le commutateur convient aux modems numériques, procédez comme suit :
-
Assurez-vous que la ligne DS1 est provisionnée pour permettre la numérotation.
-
Activez debug modem et debug modem csm ou debug csm modem pour identifier le modem qui répond à l'appel.
-
Établissez une connexion Telnet inverse à un modem et passez l'appel.
-
Une fois les modems montés, générez du trafic (par exemple, longueur de terminal 0 et show tech-support), puis vérifiez show modem Operational-status aux deux extrémités.
Les symptômes les plus typiques qui indiquent des problèmes avec la ligne vers l'échange Telco le plus proche sont les suivants :
-
Retransmissions régulières de correction d'erreur (EC).
-
Augmentation continue du nombre total de trains à rebours.
-
La qualité du signal (SQ) est inférieure à trois.
-
Rapport signal/bruit (SNR) inférieur à 30 dB.
-
Niveau de réception bien en dessous du niveau de transmission.
-
Décalage de fréquence non nulle, fréquence de gigue de phase, niveau de gigue de phase ou roulis de phase.
-
Niveau d'écho extrême inférieur à -40 dB.
-
Écarts au milieu de la forme de la ligne ou volants considérables au(x) bord(s).
L'écho de proximité (également appelé locuteur ou local) est une partie du signal d'un émetteur qui est réfléchi à l'émetteur, depuis le central téléphonique local (CO), sur la boucle locale de l'émetteur. L’écho de proximité est généralement uniquement visible par les modems sur les lignes analogiques, car il est dû à une incompatibilité d’impédance au niveau de l’hybride, qui est le transformateur qui relie la boucle locale analogique à deux fils au réseau de transmission Telco à quatre fils.
L'écho lointain est la partie du signal analogique transmis qui a rebondi sur l'extrémité avant analogique du modem distant.
Dans le schéma suivant :
-
FEC - Echo de bout en bout
-
NEC - Écho proche de la fin
Les modulations modernes (V.32 et supérieures) utilisent des suppresseurs d'écho pour permettre aux signaux transmis et reçus simultanément d'occuper la même bande de fréquences. Ils disposent d'un processeur de signal numérique (DSP) pour suivre le signal transmis, puis soustraire ce signal du signal reçu. Les modems clients modernes (côté ligne analogique) contiennent des suppresseurs d'écho de bout en bout et de bout en bout. Les modems MICA ne contiennent que des suppresseurs d'écho de bout en bout et non de bout en bout, car ils ne s'attendent pas à être connectés à une boucle locale analogique. Avec une connexion numérique locale, il ne doit y avoir pratiquement aucun écho de proximité.
Voici quelques exemples de sortie show modem Operational-status d'un bon T1 (numérique vers le commutateur) et d'un mauvais T1 (converti en A-D). En plus de la différence dans l'écho de bout en bout, notez également la différence SNR (41 dB contre 35 dB) qui résulte en une porteuse 33600 parfaite par rapport à une porteuse 28800 médiocre.
Bonne connexion
isdn2-9>show modem operation 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
T1 (CAS) incorrect - connexion de la banque de canaux au commutateur - l'écho d'extrémité distante est de -36 dBm
term-server-1#show modem operation 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
Pour plus d'informations, consultez Vue d'ensemble de la qualité générale des lignes de modem et NAS et cette note de version.
Si les tests n'indiquent aucun problème avec la ligne, poursuivez avec Telco le long des chemins d'appel.
Les appels destinés à certains numéros (DS1 ou serveur d'accès) présentent une mauvaise connectivité
Les appels de divers emplacements avec différents modèles de modems vers certains numéros (DS1 ou serveur d'accès) présentent une connectivité médiocre en termes de faible débit de connexion, souvent de retrains, de taux d'erreur élevés, etc. Les mêmes clients aux mêmes emplacements ont une bonne connectivité lorsqu'ils appellent d'autres numéros locaux (comme le San-Jose Dial-In Lab ou le Australie Dial-In Lab).
Vérifiez les statistiques aux niveaux contrôleur et interface pour les erreurs (voir l'introduction pour plus d'informations). Par exemple, si le serveur d'accès termine plus d'une ligne Telco, assurez-vous que toutes les lignes sont synchronisées (généralement, les lignes doivent être prises du même fournisseur), comme expliqué dans Synchronisation d'horloge. La vérification doit être effectuée à la fois sur le serveur d'accès et sur le côté Telco (si le problème affecte les signaux provenant du serveur d'accès à l'échange Telco le plus proche, le serveur d'accès ne peut signaler aucune erreur).
Si vous avez vérifié que les choses vont bien au niveau de la couche T1 ou E1, mais que les choses ne se comportent pas correctement au niveau de la couche modem, voici quelques éléments à vérifier :
-
Recueillir des statistiques représentatives (voir aussi la note 1) sur quel côté se déconnecte et quelle en est la raison. Pour connaître les raisons de déconnexion côté serveur d'accès, reportez-vous à l'adresse suivante :
Vérifiez si les modems à réglage fin ont un impact sur les temps de connexion ou les raisons de déconnexion.
-
Assurez-vous d'utiliser un bon code de modem (reportez-vous à Modems de réglage fin)
-
Assurez-vous de régler les chemins DS0 par l’intermédiaire du Telco pour des performances optimales. Notez que les sous-optimisations se trouvent n'importe où dans le chemin DS0 / 3.1KHz :
-
Dans le câblage du modem client (par exemple, les postes).
-
La boucle locale du client (boucle longue, bobines de chargement, robinets de pont).
-
Dans une configuration de commutateur, trop de remplissage numérique ou analogique, ou pas assez
-
Agrégations problématiques au sein de la compagnie de téléphone (anciennes liaisons hyperfréquences, anciennes liaisons analogiques E&M à quatre fils).
-
Afin de prendre en compte (la plupart) le réseau de transmission du réseau Telco local et les boucles locales, il est recommandé de composer le numéro de votre propre bon client connu (modem et boucle vers le commutateur Telco le plus proche) vers le serveur d'accès cible. Si vous obtenez une connexion de la qualité souhaitée, cela prouve que le serveur d'accès, ses modems et sa ligne DS1 sont sains.
Pour déterminer si le chemin vers le commutateur convient aux modems numériques, procédez comme suit :
-
Assurez-vous que la ligne DS1 est provisionnée pour permettre la numérotation.
-
Activez debug modem et debug modem csm ou debug csm modem pour identifier le modem qui répond à l'appel.
-
Établissez une connexion Telnet inverse à un modem et passez l'appel.
-
Une fois les modems montés, générez du trafic (par exemple, longueur de terminal 0 et show tech-support), puis vérifiez show modem Operational-status aux deux extrémités.
Les symptômes les plus typiques qui indiquent des problèmes avec la ligne vers l'échange Telco le plus proche sont les suivants :
-
Retransmissions régulières de correction d'erreur (EC).
-
Augmentation continue du nombre total de trains à rebours.
-
La qualité du signal (SQ) est inférieure à trois.
-
Rapport signal/bruit (SNR) inférieur à 30 dB.
-
Niveau de réception bien en dessous du niveau de transmission.
-
Décalage de fréquence non nulle, fréquence de gigue de phase, niveau de gigue de phase ou roulis de phase.
-
Niveau d'écho extrême inférieur à -40 dB.
-
Écarts au milieu de la forme de la ligne ou volants considérables au(x) bord(s).
L'écho de proximité (également appelé locuteur ou local) est une partie du signal d'un émetteur qui est répercuté à l'émetteur, du central téléphonique local, sur la boucle locale de l'émetteur. L’écho de proximité est généralement uniquement visible par les modems sur les lignes analogiques, car il est dû à une incompatibilité d’impédance au niveau de l’hybride, qui est le transformateur qui relie la boucle locale analogique à deux fils au réseau de transmission Telco à quatre fils.
L'écho lointain est la partie du signal analogique transmis qui a rebondi sur l'extrémité avant analogique du modem distant.
Dans le schéma suivant :
-
FEC - Echo de bout en bout
-
NEC - Écho proche de la fin
Les modulations modernes (V.32 et supérieures) utilisent des suppresseurs d'écho pour permettre aux signaux transmis et reçus simultanément d'occuper la même bande de fréquences. Ils ont un DSP qui garde le suivi du signal transmis, puis soustrait ce signal du signal reçu. Les modems clients modernes (côté ligne analogique) contiennent des suppresseurs d'écho de bout en bout et de bout en bout. Les modems MICA ne contiennent que des suppresseurs d'écho de bout en bout et non de bout en bout, car ils ne s'attendent pas à être connectés à une boucle locale analogique. Avec une connexion numérique locale, il ne doit pas y avoir (virtuellement) d'écho proche.
Voici des exemples de show modem Operational-status d'un bon (numérique au commutateur) et d'un mauvais (converti en A-D) T1. En plus de la différence dans l'écho de bout en bout, notez également la différence SNR (41 dB contre 35 dB) qui résulte en une porteuse 33600 parfaite par rapport à une porteuse 28800 médiocre.
Bonne connexion
isdn2-9>show modem operation 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
T1 (CAS) incorrect - connexion de la banque de canaux au commutateur - l'écho d'extrémité distante est de -36 dBm
term-server-1#show modem operation 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
Pour plus d'informations, consultez Vue d'ensemble de la qualité générale des lignes de modem et NAS et cette note de version.
Si les boucles vers les commutateurs Telco les plus proches (du côté client et du côté serveur d'accès) semblent propres, et que les sous-optimisations se trouvent quelque part dans le chemin Telco, voici certaines choses que vous pouvez faire :
-
Passer un appel non CE en V.22bis à 2 400 bits/s. Si le circuit est sain, aucune erreur ne doit être détectée. Si vous laissez la connexion inactive et que vous voyez des erreurs récurrentes (en particulier avec le code 0x7B, '{' dans ASCII), cela indique la présence de bordures (contrôlées) (par exemple, dans les étendues T de l'opérateur téléphonique, rarement vues)
-
Si les niveaux de puissance de transmission ou de réception observés sur nos clients sont trop élevés ou trop bas, ajustez les niveaux de transmission et ajoutez ou supprimez le remplissage de ligne ou de liaison.
Si vous voyez un support V.34 sain, mais que vous recevez une faible ou aucune modulation PCM (Pulse Code modulation) se connecte (où le code PCM sur les clients est connu comme compatible avec les modems serveur) :
-
Vérifiez que les chemins de circuit vers les modems clients peuvent supporter une connexion PCM. En d'autres termes, assurez-vous qu'ils n'ont pas de conversion analogique-numérique supplémentaire.
-
Examinez le remplissage numérique dans le chemin.
Passez à Telco pour approfondir vos recherches sur les chemins d'appel.
Appels vers certains numéros (DS1 ou Access Server) Connect, mais plus tard l'appel est abandonné
Les appels de différents emplacements avec différents modèles de modems vers certains numéros (DS1 ou serveur d'accès) se connectent correctement, mais plus tard l'appel est abandonné. Les mêmes clients aux mêmes emplacements ont une bonne connectivité lorsqu'ils appellent d'autres numéros locaux (comme le San-Jose Dial-In Lab ou le Australie Dial-In Lab).
Tout d'abord, vérifiez les statistiques aux niveaux contrôleur et interface pour les erreurs (voir l'introduction pour plus d'informations). Par exemple, si le serveur d'accès termine plus d'une ligne Telco, assurez-vous que toutes les lignes sont synchronisées (généralement, les lignes doivent être prises du même fournisseur), comme expliqué dans Synchronisation d'horloge. La vérification doit être effectuée à la fois sur le serveur d'accès et sur le côté Telco (si le problème affecte les signaux provenant du serveur d'accès à l'échange Telco le plus proche, le serveur d'accès ne peut signaler aucune erreur).
Ensuite, assurez-vous que les appels atteignent le serveur d'accès, comme expliqué dans la technologie commutée : Techniques de dépannage. Vérifiez ensuite les compteurs d'appels show controller <e1|t1>. Pour certains problèmes Telco, certains canaux DS0 signalent généralement des temps de connexion très faibles et un très grand nombre d’appels. Recueillir des statistiques représentatives (voir également la note 1) sur quel côté se déconnecte et en quoi cela s'explique-t-il ?
-
Indique si une terminaison PPP a été demandée. Voir Technologie de numérotation : Techniques de dépannage.
-
Indique si la terminaison du modem a été demandée. Les raisons de déconnexion du modem dans le journal des modems sont expliquées à l'adresse :
-
Cause de déconnexion RNIS. (Voir aussi note 3).
Si les appels se déconnectent en raison d'erreurs de connectivité de montage, vérifiez si les modems de réglage fin ont un impact sur les temps de connexion et/ou les raisons de déconnexion.
-
Assurez-vous d'utiliser un bon code de modem (reportez-vous à Modems de réglage fin)
-
Assurez-vous de régler les chemins DS0 par l’intermédiaire du Telco pour des performances optimales. Notez que les sous-optimisations se trouvent n'importe où dans le chemin DS0 / 3.1KHz :
-
Dans le câblage du modem client (par exemple, les postes).
-
La boucle locale du client (boucle longue, bobines de chargement, robinets de pont).
-
Dans une configuration de commutateur, trop de remplissage numérique ou analogique, ou pas assez
-
Agrégations problématiques au sein de la compagnie de téléphone (anciennes liaisons hyperfréquences, anciennes liaisons analogiques E&M à quatre fils).
-
Afin de prendre en compte (la plupart) le réseau de transmission du réseau Telco local et les boucles locales, il est recommandé de composer le numéro de votre propre bon client connu (modem et boucle vers le commutateur Telco le plus proche) vers le serveur d'accès cible. Si vous obtenez une connexion de la qualité souhaitée, cela prouve que le serveur d'accès, ses modems et sa ligne DS1 sont sains.
Pour déterminer si le chemin vers le commutateur convient aux modems numériques, procédez comme suit :
-
Assurez-vous que la ligne DS1 est provisionnée pour permettre la numérotation.
-
Activez debug modem et debug modem csm ou debug csm modem pour identifier le modem qui répond à l'appel.
-
Établissez une connexion Telnet inverse à un modem et passez l'appel.
-
Une fois les modems montés, générez du trafic (par exemple, longueur de terminal 0 et show tech-support), puis cochez show modem Operational-status aux deux extrémités.
Les symptômes les plus typiques qui indiquent des problèmes avec la ligne vers l'échange Telco le plus proche sont les suivants :
-
Retransmissions régulières de correction d'erreur (EC).
-
Augmentation continue du nombre total de trains à rebours.
-
La qualité du signal (SQ) est inférieure à trois.
-
Rapport signal/bruit (SNR) inférieur à 30 dB.
-
Niveau de réception bien en dessous du niveau de transmission.
-
Décalage de fréquence non nulle, fréquence de gigue de phase, niveau de gigue de phase ou roulis de phase.
-
Niveau d'écho extrême inférieur à -40 dB.
-
Écarts au milieu de la forme de la ligne ou volants considérables au(x) bord(s).
L'écho de proximité (également appelé locuteur ou local) est une partie du signal d'un émetteur qui est répercuté à l'émetteur, du central téléphonique local, sur la boucle locale de l'émetteur. L’écho de proximité est généralement uniquement visible par les modems sur les lignes analogiques, car il est dû à une incompatibilité d’impédance au niveau de l’hybride, qui est le transformateur qui relie la boucle locale analogique à deux fils au réseau de transmission Telco à quatre fils.
L'écho lointain est la partie du signal analogique transmis qui a rebondi sur l'extrémité avant analogique du modem distant.
L'écho lointain est la partie du signal analogique transmis qui a rebondi sur l'extrémité avant analogique du modem distant.
Dans le schéma suivant :
-
FEC - Echo de bout en bout
-
NEC - Écho proche de la fin
Les modulations modernes (V.32 et supérieures) utilisent des suppresseurs d'écho pour permettre aux signaux transmis et reçus simultanément d'occuper la même bande de fréquences. Ils ont un DSP qui garde le suivi du signal transmis, puis soustrait ce signal du signal reçu. Les modems clients modernes (côté ligne analogique) contiennent des suppresseurs d'écho de bout en bout et de bout en bout. Les modems MICA ne contiennent que des suppresseurs d'écho de bout en bout et non de bout en bout, car ils ne s'attendent pas à être connectés à une boucle locale analogique. Avec une connexion numérique locale, il ne doit pas y avoir (virtuellement) d'écho proche.
Voici des exemples de show modem Operational-status d'un bon (numérique au commutateur) et d'un mauvais (converti en A-D) T1. En plus de la différence dans l'écho de bout en bout, notez également la différence SNR (41 dB contre 35 dB) qui résulte en une porteuse 33600 parfaite par rapport à une porteuse 28800 médiocre.
Bonne connexion
isdn2-9>show modem operational 1/55
Modem(1/55) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 0
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 44 secs
Parameter #6 Total Retrains: 0
Parameter #7 Sq Value: 4
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 33600, 33600
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 0
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 41 dB
Parameter #22 Receive Level: -12 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -73 dBm
Parameter #27 Phase Roll: 22 degrees
Parameter #28 Round Trip Delay: 3 msecs
Parameter #30 Characters transmitted, received: 83, 3194
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 81, 105
Parameter #38 EC packets (Received BAD/ABORTED): 0
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
*
T1 (CAS) incorrect - connexion de la banque de canaux au commutateur - l'écho d'extrémité distante est de -36 dBm
term-server-1#show modem operational 1/38
Modem(1/38) Operational-Status:
Parameter #0 Disconnect Reason Info: (0x0)
Type (=0 ): <unknown>
Class (=0 ): Other
Reason (=0 ): no disconnect has yet occurred
Parameter #1 Connect Protocol: LAP-M
Parameter #2 Compression: V.42bis both
Parameter #3 EC Retransmission Count: 2
Parameter #4 Self Test Error Count: 0
Parameter #5 Call Timer: 96 secs
Parameter #6 Total Retrains: 1
Parameter #7 Sq Value: 3
Parameter #8 Connected Standard: V.34+
Parameter #9 TX,RX Bit Rate: 28800, 28800
Parameter #11 TX,RX Symbol Rate: 3429, 3429
Parameter #13 TX,RX Carrier Frequency: 1959, 1959
Parameter #15 TX,RX Trellis Coding: 16, 16
Parameter #16 TX,RX Preemphasis Index: 0, 6
Parameter #17 TX,RX Constellation Shaping: Off, Off
Parameter #18 TX,RX Nonlinear Encoding: Off, Off
Parameter #19 TX,RX Precoding: Off, Off
Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm
Parameter #21 Signal Noise Ratio: 35 dB
Parameter #22 Receive Level: -13 dBm
Parameter #23 Frequency Offset: 0 Hz
Parameter #24 Phase Jitter Frequency: 0 Hz
Parameter #25 Phase Jitter Level: 0 degrees
Parameter #26 Far End Echo Level: -36 dBm
Parameter #27 Phase Roll: 0 degrees
Parameter #28 Round Trip Delay: 6 msecs
Parameter #30 Characters transmitted, received: 8636, 116
Parameter #32 Characters received BAD: 0
Parameter #33 PPP/SLIP packets transmitted, received: 0, 0
Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0
Parameter #36 EC packets transmitted, received OK: 124, 63
Parameter #38 EC packets (Received BAD/ABORTED): 4
Parameter #39 Robbed Bit Signalling (RBS) pattern: 0
Parameter #40 Digital Pad: None, Digital Pad Compensation: None
Line Shape:
.........*
......*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.........*
.......*
........*
*
Pour plus d'informations, consultez Vue d'ensemble de la qualité générale des lignes de modem et NAS et cette note de version.
Si les boucles vers les commutateurs Telco les plus proches (du côté client et du côté serveur d'accès) semblent propres, et que les sous-optimisations se trouvent quelque part dans le chemin Telco, voici certaines choses que vous pouvez faire :
-
Passer un appel non CE en V.22bis à 2 400 bits/s. Si le circuit est sain, aucune erreur ne doit être détectée. Si vous laissez la connexion inactive et que vous voyez des erreurs récurrentes (en particulier avec le code 0x7B, '{' dans ASCII), cela indique la présence de bordures (contrôlées) (par exemple, dans les étendues T de l'opérateur téléphonique, rarement vues)
-
Si les niveaux de puissance de transmission ou de réception observés sur nos clients sont trop élevés ou trop bas, ajustez les niveaux de transmission et ajoutez ou supprimez le remplissage de ligne ou de liaison.
Si vous voyez un support V.34 sain, mais que vous recevez une faible ou aucune modulation PCM (Pulse Code modulation) se connecte (où le code PCM sur les clients est connu comme compatible avec les modems serveur) :
-
Vérifiez que les chemins de circuit vers les modems clients peuvent supporter une connexion PCM. En d'autres termes, assurez-vous qu'ils n'ont pas de conversion analogique-numérique supplémentaire.
-
Examinez le remplissage numérique dans le chemin.
Passez à Telco pour approfondir vos recherches sur les chemins d'appel.
Les modems ne sélectionnent pas d'appels
Pour résoudre ce problème, procédez comme suit :
-
Vérifiez si l'appel arrive sur le serveur d'accès avec la technologie de numérotation : Techniques de dépannage.
-
Vérifiez si les appels RNIS ont la fonctionnalité de support correcte et assurez-vous que DoV n'est pas configuré.
-
Vérifiez si les modems sont configurés pour sélectionner des appels vocaux.
-
Vérifiez que les paramètres de modemcap, comme expliqué dans Modem Management Operations (voir aussi Note 2), sont corrects (par exemple, le registre S0 n'est pas défini sur 0 ou une valeur trop élevée) :
-
Si RPM ou RPMS est utilisé, vérifiez d'abord si le problème persiste après la désactivation de la fonction. Si cela vous aide, poursuivez avec le RPM configuré localement et vérifiez les paramètres du modemcap.
-
Vérifiez si les canaux B ne sont pas occupés (show isdn active) et s'il existe des modems gratuits (show modem). Si les modems sont marqués comme défectueux, il peut s'agir d'un problème matériel ou logiciel.
-
La défaillance matérielle réside généralement avec une certaine carte porteuse ou une certaine carte modem. Les modems ne doivent pas nécessairement être marqués comme défectueux, mais ils échouent sur tous les appels depuis le démarrage. Le remplacement du matériel est la solution.
-
En cas de panne logicielle, les modems fonctionnent généralement bien après chaque redémarrage, mais plus tard sont marqués comme mauvais au hasard (peut être dans des clusters de un, deux, trois, six ou 12 dans une même carte modem) ou échouent tout simplement tous les autres appels. Si le problème n'est détecté que pendant les heures de pointe, vérifiez les statistiques du modem show modem . Un taux élevé de non-réponse réparti uniformément sur tous les modems indique que le serveur d'accès ne peut tout simplement pas traiter un tel volume d'appels. Si un taux élevé de No Answer est spécifique à quelques modems seulement, il est toujours probable qu'il indique une défaillance logicielle. Le rechargement du micrologiciel est une solution de contournement. La solution consiste à mettre à niveau le logiciel et à activer la récupération automatique du modem (pour les routeurs Cisco 3600, le module de réseau [NM] peut nécessiter un remplacement si le résultat de la commande show diag indique que la référence n'est pas -02 : 800-0553x-02). Pour plus d'informations, référez-vous aux modems MICA et Nextport.
-
Les modems prennent des appels, mais ne s'entraînent pas
Parfois, les modems prennent des appels, mais ne s'entraînent pas. Pour vérifier cela, recueillir des statistiques représentatives (voir également la note 1) sur quel côté initie la déconnexion et en quelle raison. Pour le côté serveur d'accès, les raisons de déconnexion sont expliquées à l'adresse :
En outre, le CSR doit diminuer et les modems doivent s'arrêter quelque part au milieu des transitions d'état du modem.
Vérifiez d'abord si le pays du modem est configuré correctement. Recherchez les erreurs sur le contrôleur ou l'interface du côté du serveur d'accès et du côté de Telco (si le problème affecte les signaux provenant du serveur d'accès à l'échange Telco le plus proche, le serveur d'accès ne peut signaler aucune erreur). Si RPM ou RPMS est utilisé, vérifiez si le problème persiste une fois la fonctionnalité désactivée. Ensuite, essayez avec le RPM configuré localement et vérifiez que les paramètres du modemcap, comme expliqué dans Opérations de gestion du modem (voir également Note 2), sont corrects :
Vérifiez les statistiques du modem à l'aide de la commande show modem (MICA) ou show spe (NextPort). Si les clusters d'un, deux, trois, six ou 12 modems d'une même carte modem ont un nombre anormalement élevé d'appels en panne ou sont marqués comme défectueux, cela peut être un problème matériel ou logiciel.
-
En cas de panne matérielle, il est généralement préférable de rester avec une carte d'opérateur ou une carte modem. Les modems ne doivent pas nécessairement être marqués comme défectueux, mais ils échouent tous les appels depuis le démarrage. Le remplacement du matériel est la solution.
-
En cas de panne logicielle, il est généralement normal que les modems fonctionnent correctement après chaque redémarrage, mais plus tard sont marqués comme défectueux au hasard (peut être dans des clusters de un, deux, trois, six ou 12 dans la même carte modem) ou échouent tout simplement tous les autres appels. Le rechargement du micrologiciel est une solution de contournement. La solution consiste à mettre à niveau le logiciel et à activer la récupération automatique du modem (pour les routeurs Cisco 3600, le NM peut avoir besoin d'être remplacé, si le résultat de la commande show diag indique que la référence n'est pas la version -02 : 800-0553x-02). Pour plus d'informations, référez-vous aux modems MICA et Nextport.
Si le problème n'est pas spécifique à l'architecture du serveur d'accès, vérifiez si les modems à réglage fin ont un impact sur les temps de connexion et les raisons de déconnexion.
Les modems s'entraînent, mais la connectivité est médiocre
Ces problèmes peuvent également être attribués à Telco, aux modems clients ou au serveur d'accès. Si aucune statistique n'est disponible précédemment pour l'emplacement, les recommandations de la série ITU-T V.56 peuvent servir à une première approximation dont les taux de connexion dans lesquels vous pouvez vous attendre. Recherchez les erreurs sur le contrôleur et l'interface. La vérification doit être effectuée à la fois sur le serveur d'accès et sur le côté Telco (si le problème affecte les signaux provenant du serveur d'accès au central téléphonique le plus proche, le serveur d'accès ne peut signaler aucune erreur). Il peut également être nécessaire de continuer avec Telco plus loin sur le chemin.
Si RPM ou RPMS est utilisé, vérifiez d'abord si le problème persiste après la désactivation de la fonction. Si cela vous aide, examinez le RPM et le modemcap configurés localement, comme expliqué ci-dessous.
Vérifiez que les paramètres de modemcap tels qu'ils sont décrits dans Opérations de gestion de modems (voir également Note 2) sont corrects :
Essayez des modems à réglage fin et vérifiez s'il apporte des améliorations avec n'importe quel type de modems. Vérifiez les paramètres de connexion pour les appels spécifiques avec show modem Operational-status, comme discuté dans Vue d'ensemble de la qualité générale des lignes de modem et NAS et cette note de version pour identifier les problèmes potentiels.
Les modems s'activent, mais le protocole PPP ne démarre pas
Pour vérifier cela, vérifiez le motif de déconnexion dans les journaux du modem. Vérifiez que le CSR ne diminue pas et que les modems passent par toutes les transitions d'état avec succès. Dans le contrôle de configuration :
-
Indique si le protocole PPP sur le serveur d'accès est configuré en mode interactif ou dédié. Si le protocole PPP est configuré pour être sélectionné de manière interactive et que le client n'envoie pas de séquence de sélection automatique PPP, comme spécifié dans la RFC 1662, la connectivité PPP du point de vue du serveur d'accès est impossible. Examinez le côté client ou Telco.
-
Si les lignes de modem et l'interface de modem (généralement group-async) sont configurées correctement (pour des exemples de configuration, reportez-vous à l'introduction de cette section ou Technologie commutée : Techniques de dépannage).
-
Indique si des modems sont laissés orphelins en dehors de la plage de groupes d'interfaces asynchrones-groupe. Aucun ne doit être laissé orphelin.
Les modems s'activent et le protocole PPP démarre, mais l'appel plus tard tombe
Vérifiez si les clients, la compagnie de téléphone ou le serveur d'accès initient les déconnexions.
-
Vérifiez tout d'abord si la liaison PPP a été interrompue correctement (cette déconnexion peut être initiée par le client ou le serveur d'accès) avec la technologie commutée : Techniques de dépannage.
-
Si le protocole PPP n’a pas été correctement terminé, le Telco peut en être la raison. Décodez les raisons de déconnexion dans le journal du modem. (Voir aussi note 1).
-
Si les modems signalent également une déconnexion inattendue, la compagnie de téléphone est peut-être responsable. Il est préférable de comparer les raisons de déconnexion des deux extrémités de la connexion. Reportez-vous à la cause de déconnexion RNIS. (Voir aussi note 3).
-
Si le serveur d'accès a abandonné la connexion, vérifiez que le trafic intéressant est correctement défini sur l'interface de numérotation correspondante. La commande debug dialer events doit signaler si le serveur d'accès a déconnecté les appels en cas d'expiration.
Si les abandons sont initiés par les clients, le dépannage du serveur d'accès ne sera probablement pas utile. Essayez les recommandations de la section de dépannage du modem client et commencez par étudier le côté client. Même si les pertes abruptes se produisent uniquement pour chaque client testé, ce seul fait n'est pas suffisant pour identifier exactement ce qui les rend tous déconnectés du serveur d'accès. Si les résultats de l'enquête nécessitent une assistance supplémentaire de la part de Cisco, documentez vos résultats et ouvrez un dossier auprès du TAC Cisco.
Aucun problème spécifique détecté, mais CSR est faible
Pour déterminer si le CSR est élevé ou faible, vous avez besoin de chiffres de référence typiques de la zone. L'objectif est d'atteindre une RSE de 95 %. Cependant, dans un environnement FAI, avec une grande variété de modems clients et une grande variété de conditions de boucle locale, il est difficile d’atteindre un objectif. Étant donné que la RSE est un problème complexe, il est difficile de citer les taux de réussite attendus des appels. Cela est dû aux diverses conditions qui affectent un appel par modem. Exemple :
-
Quels types de commutateurs sont utilisés ?
-
Le site utilise-t-il des CO en tandem ?
-
Les lignes ont-elles été qualifiées (tests BERT, etc.) pour s'assurer qu'elles sont propres ?
-
Quelle est la qualité et l’intégrité de l’installation de câblage en cuivre ?
-
La topologie des appels inclut-elle des sauts analogiques ?
-
Les banques de canaux ou les cartes SLIC sont-elles utilisées sur le réseau ?
-
Les lignes RNIS PRI ou E1 multicanaux fractionnés sont-elles des lignes ?
-
Quelle est la distribution des modems clients ?
Note : Ce ne sont que quelques-uns des facteurs.
Les statistiques doivent être représentatives. Il doit y avoir au moins dix appels par modem pour pouvoir tirer des conclusions préliminaires, mais il est généralement recommandé d'attendre quelques milliers d'appels (voir aussi Note 1). Chaque connexion modem est unique. Deux appels du même modem vers le même numéro de destination peuvent emprunter deux chemins complètement différents via le réseau RTPC et peuvent bien finir sur différents modems hôtes physiques. La boucle locale, la connexion en cuivre entre les locaux du client et l'unité de distribution locale, peut souffrir de conditions environnementales propres à ce client, bien que la plupart des fournisseurs de boucle locale s'efforcent de s'assurer que la caractéristique de boucle locale se situe dans une plage acceptable. Les modems clients utilisent des chipsets différents qui varient d'un fabricant à l'autre et souvent dans les gammes de produits du même fabricant.
Voici les paramètres à surveiller :
-
CSR : show modem summary
-
Vitesses de connexion : show modem connect-speed, show modem log (MICA) ou show port modem log (NextPort)
-
Rapport signal/bruit (SNR) : show modem Operational-status (MICA, NextPort), AT@E1 (Microcom), show modem log (MICA) ou show port modem log (NextPort)
-
Niveaux de transmission et de réception : show modem Operational-status (MICA, NextPort), AT@E1 (Microcom)
-
Modules et protocoles de modem : show modem log (MICA) ou show port modem log (NextPort)
-
Motifs de déconnexion du modem : show modem call-stats
-
Retrains et retransmissions par blocs CE : show modem log (MICA) ou show port modem log (NextPort), show modem Operational-status (MICA, NextPort)
Pour plus d'informations, consultez Vue d'ensemble de la qualité générale des lignes de modem et NAS et cette note de version.
Il est acceptable que le CSR signalé par les serveurs d'accès Cisco soit inférieur de quelques pour cent au CSR signalé par les serveurs d'accès tiers en raison de différences dans la manière dont ils considèrent que l'appel a réussi. Dans les serveurs d'accès Cisco, l'appel est marqué comme ayant réussi uniquement après avoir réussi la phase initiale de mise en service et la phase de négociation EC (à moins qu'EC ne soit négocié, les données utilisateur ne peuvent pas être transmises sur la liaison). Les serveurs d'accès tiers ont tendance à considérer l'appel comme ayant réussi immédiatement après la fin du train initial (c'est-à-dire qu'aucune défaillance EC n'est prise en compte).
Le problème faible de la CSR peut être également attribué à l’opérateur téléphonique, aux clients ou au serveur d’accès. Essayez d'améliorer la CSR en réglant les modems. Pour dépanner les modems et les opérateurs téléphoniques, reportez-vous à la section dépannage des modems clients. Ces symptômes sont typiques pour les problèmes liés au serveur d'accès :
-
show modem signale des clusters de un, deux, trois, six ou 12 modems dans une même carte modem ayant un nombre inhabituellement élevé d'appels en panne ou sans réponse.
-
show modemcall-stats signale des clusters d'un, deux, trois, six ou 12 modems dans une même carte ayant plus de dix pour cent de leurs déconnexions attribuées à des colonnes que dtrDrop ou hostDrop et rmtLink (lossCarr peut également compter une bonne déconnexion si les modems clients ne terminent pas LAP-M avant de se déconnecter);
-
les clusters d'un, deux, trois, six ou 12 modems d'une même carte modem sont marqués comme défectueux mais, après le rechargement du microprogramme, peuvent reprendre des appels.
Si les symptômes correspondent, mettez à niveau le logiciel et configurez la récupération automatique du modem. Pour plus d'informations, référez-vous aux modems MICA et Nextport.
Notes
Note 1
Pour automatiser l'analyse des statistiques des modems, utilisez les outils 
disponibles dans le cadre de l'Open Source Initiative (COSI) centrée sur Cisco.
Note 2
Pour automatiser l'analyse des modemcap, utilisez les outils disponibles dans le cadre de l'initiative Open Source (COSI) axée sur Cisco.
Note 3
L'analyse de signalisation RNIS peut être automatisée à l'aide des outils disponibles dans le cadre de l'Open Source Initiative (COSI) centrée sur Cisco.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
03-Sep-2006 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)