Introduction
Ce document décrit les procédures utilisées pour dépanner les produits MCU (Multipoint Control Unit) Cisco TelePresence. Ce document est destiné aux administrateurs de systèmes vidéo et aux partenaires Cisco dont les clients sont des administrateurs de systèmes vidéo.
La gamme de produits MCU est un produit de conférence multimédia de pointe. Il s'agit de systèmes intégrés complexes, dotés d'un matériel conçu par Cisco afin d'offrir les meilleures performances. Ce document a pour but de faciliter la résolution de toute situation pouvant être causée par une défaillance matérielle d'un produit MCU Cisco. Une autorisation de retour à la fabrication (RMA) doit être fournie par un ingénieur de l'assistance technique Cisco, qui vérifie que le produit a réellement échoué au cours d'une série de tests, en fonction du composant suspecté. Ce guide vise à accélérer ce processus avec une vision d'ensemble de ces tests.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Gamme MCU Cisco TelePresence MSE
- Cisco TelePresence MCU, série 5300
- Cisco TelePresence MCU, série 4500
- Cisco TelePresence MCU, série 4200
- Passerelle RNIS Cisco TelePresence (GW)
Components Used
Les informations de ce document sont basées sur la gamme Cisco TelePresence MCU Media Services Engine (MSE).
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.
Produits connexes
Ce document peut également être utilisé avec les versions de matériel et de logiciel suivantes :
- Serveur Cisco Telepresence 7010
- Cisco TelePresence MCU, série 5300
- Cisco TelePresence MCU, série 4500
- Cisco TelePresence MCU, série 4200
- Gamme de passerelles RNIS Cisco Telepresence
Liste de contrôle RMA de la gamme MCU Cisco TelePresence MSE
Cette section décrit quelques-unes des vérifications les plus basiques qui sont utilisées afin de confirmer que votre lame MCU MSE Series est opérationnelle et ne souffre pas d'une défaillance matérielle. Le comportement de l'unité MCU doit être documenté au fur et à mesure que ces vérifications sont effectuées.
Effectuer un contrôle rapide sur l'unité MCU
Cette section fournit une liste de contrôle que vous pouvez utiliser afin de dépanner la configuration de base d'une MCU via son interface Web. Ceci est complété par des vérifications des paramètres H.323, de la réception automatique, de l'utilisation de la licence de port et des appels de bouclage.
Vérifiez que la lame peut passer un appel vidéo. Si l'interface Web de l'unité MCU est accessible et qu'un appel peut être effectué, elle est fondamentalement fonctionnelle. Procédez comme suit :
- Ouvrez un navigateur Web et accédez à l'adresse IP de l'unité MCU. La page d'accueil doit s'afficher immédiatement.
Note: Si la page Web est inaccessible, reportez-vous à la section Vérifier la connectivité réseau du MCU de ce document.
- Cliquez sur le lien Status afin de vérifier la version du logiciel qui s'exécute actuellement sur le MCU.
Note: Si une version antérieure à la version 4.3 est actuellement utilisée, il est recommandé de consulter les dernières notes de version et d'envisager une mise à niveau.
- Si vous pouvez accéder à l'interface Web, procédez comme suit :
- Accédez à Paramètres > H.323 et définissez l'utilisation du contrôleur d'accès H.323 sur Désactivé. Cette étape est essentielle car certains contrôleurs d'accès empêchent les appels directement d'une unité MCU vers une adresse IP.
- Accédez à Paramètres > Conférences > Paramètres avancés, et assurez-vous que les appels entrants vers des conférences ou des participants automatiques inconnus sont définis sur Standard automatique par défaut.
- Créez une nouvelle conférence et ajoutez un participant H.323 avec l'adresse IP 127.0.0.1. Cela entraîne le rappel de l'unité MCU à sa propre réception automatique (AA). L'écran AA s'affiche dans la miniature d'aperçu et les codecs audio et vidéo sont négociés dans chaque direction.
Voici un exemple de l'écran MCU MSE 8510 où l'unité MCU peut s'appeler correctement :

Si cela fonctionne et qu'un participant connecté est vu (comme dans l'image précédente), il y a très probablement un problème d'interopérabilité de gatekeeper, de réseau ou de point d'extrémité. Composez un numéro de terminal réel, puis corrigez-le à l'aide du journal des événements et du journal SIP (Session Initiation Protocol) H323. Si la connexion échoue immédiatement, mais que l'interface Web fonctionne toujours, poursuivez cette procédure.
- Afin de vérifier que les licences de port sont attribuées à l'unité MCU, accédez à la section Gestion des licences de port de la lame Supervisor. Voici une image qui montre l'allocation de licence de port à partir de la lame Supervisor MSE 8050 :

Dans l'image, le bloc vide sous le logement 4 montre qu'il y a une lame dans ce logement sans licence de port qui lui est attribuée. Cette lame ne peut pas passer d'appels, de sorte que le test de bouclage décrit à l'étape 3 aurait échoué sur cette lame. Les blocs bleus sous les logements 2, 3, 5, et 7 montrent que ces logements ont une allocation complète de licences de port. Si un emplacement affiche un symbole d'avertissement, il n'y a aucune lame dans le logement. Un bloc à demi-bleu indique que la lame dispose de certaines licences de port qui lui sont attribuées, mais pas qu'elle est à pleine capacité. Une lame comme celle-ci ne peut pas connecter son nombre total de ports annoncés tant qu'elle ne dispose pas de davantage de licences.
- Attribuez des licences de port si aucune n'est attribuée à la lame (ce processus est décrit dans l'aide en ligne). Si aucune clé n'est présente pour les licences de port, contactez votre gestionnaire de compte.
Note: Si l'appel échoue, même si la lame dispose de licences de port suffisantes, reportez-vous aux MCU Reach dans la section Interface Web de ce document. Si l'interface Web devient indisponible pendant ce test et que le contact avec la lame est perdu, la lame peut avoir redémarré ; récupérez le journal de diagnostic des lames et contactez le support technique Cisco.
Vérification de la connectivité réseau de l'unité MCU
Utilisez cette section afin de résoudre les problèmes liés aux tentatives de connexion à l'interface Web du MCU à partir d'un navigateur, en fonction de la vérification de la connectivité réseau et de la configuration du réseau.
Vous pouvez rencontrer l'un de ces problèmes lorsque vous tentez de vous connecter à l'interface Web du MCU à partir d'un navigateur :
- Un problème avec le réseau entre le PC et le MCU
- Un problème avec la MCU elle-même (carte réseau, matériel ou configuration)
Complétez ces étapes afin de résoudre le problème :
- Essayez d'envoyer une requête ping à l'adresse IP du MCU.
Note: Les produits NetBSD ont une taille maximale de 76 octets. La plupart des routeurs ont une valeur par défaut de 100 octets.
Si l'unité MCU répond aux requêtes ping, mais que l'interface Web est désactivée, l'unité MCU n'a peut-être pas pu démarrer complètement ou elle peut être verrouillée dans un cycle de redémarrage. Si c'est le cas, reportez-vous à la section Vérification physique de la lame de ce document. Si le MCU ne répond pas aux requêtes ping, poursuivez cette procédure.
- Accédez à l'interface Web de la lame Supervisor MSE 8050 du châssis qui contient la lame MCU MSE 8510. Si l'interface utilisateur de la lame Supervisor n'est pas accessible, contactez vos administrateurs réseau locaux afin d'étudier un problème réseau éventuel. Si l'interface utilisateur de la lame de superviseur est accessible et que le superviseur et l'unité MCU ne se trouvent pas sur des réseaux différents, il est probable que le problème concerne la lame ou ses paramètres IP.
- Dans l'interface utilisateur de la lame Supervisor, accédez à Matériel, puis cliquez sur le lien du numéro de logement de la lame MCU MSE 8510. Cliquez ensuite sur l'onglet Port A.
- Vérifiez la configuration IP du port MCU A et vérifiez qu'aucune autre adresse IP n'est attribuée à un autre hôte du réseau. Les adresses IP dupliquées sont un problème étonnamment courant. Si nécessaire, consultez l'administrateur réseau afin de vérifier ces paramètres.
- Vérifiez la section Port A Ethernet status. Si l'état de la liaison n'est pas actif, vérifiez que le câble réseau est connecté au commutateur. Il peut y avoir un problème avec le câble ou le port de commutateur.
- Si l’unité MCU est maintenant accessible sur le réseau, répétez la première étape de cette procédure. Si les paramètres d'adresse IP sont corrects et que l'état de la liaison Ethernet est activé, mais que la lame ne peut toujours pas être contactée depuis n'importe quel point du réseau, reportez-vous à la section Contrôler la lame de la gamme MCU MSE 8510 via la section Superviseur de ce document.
Vérifiez la carte MCU MSE 8510 via le superviseur
Complétez ces étapes afin de vérifier l'état de la lame MCU et de la conférence, l'état de santé et les rapports sur la disponibilité, la version du logiciel, la température et la tension :
- Cliquez sur Matériel, puis sur le numéro de logement de la lame qui présente le problème. La page de résumé fournit des informations sur :
- État de la lame, avec l'adresse IP, la disponibilité, le numéro de série et la version du logiciel
- La santé des lames, avec la batterie Températures, Tension et horloge en temps réel (RTC)
- État signalé pour les conférences actives, le nombre de participants, les ports audio/vidéo utilisés et les visionneuses en continu
Cette image montre la section Intégrité des lames :

- Si l'état de tension (courant ou pire) n'apparaît pas OK, assurez-vous qu'un nombre suffisant de redresseurs sont installés dans les étagères d'alimentation qui alimentent le châssis. Vérifiez également que la source d'alimentation répond aux exigences actuelles du châssis, comme indiqué dans le document Calculating power and current Requirements for an MSE 8000 Cisco article.
- Si le module d'alimentation ne s'affiche pas OK, contactez le support technique de Cisco.
- Si l'un des autres états actuels de la section Intégrité des lames ne s'affiche pas comme OK, contactez le support technique Cisco.
- Si tous les états actuels indiquent OK, mais qu'un ou plusieurs des pires états affichés ne s'affichent pas OK, consultez le journal des événements et les journaux des alarmes auprès du superviseur et contactez le support technique Cisco.
- Vérifiez la disponibilité. Si le temps de fonctionnement est inattendu (moins de 30 minutes) et qu'il n'y a aucune raison connue (si le moteur n'a pas été mis sous tension ou si la lame n'a pas été réinstallée, par exemple), la lame peut avoir récemment redémarré. La cause du redémarrage peut être un défaut logiciel ou un problème matériel. Cela dépend de s'il s'agit d'un redémarrage unique ou d'un redémarrage cyclique.
Complétez ces étapes afin de déterminer ceci :
- Attendez 30 minutes.
- Actualiser la page.
- Vérifiez à nouveau la disponibilité.
Si vous pouvez déterminer à partir du temps de disponibilité actualisé que la lame a redémarré ultérieurement, reportez-vous à la section Crashes de ce document.
- Si la lame ne redémarre pas après avoir vérifié l'état de la page et qu'elle semble fonctionner à tous les autres égards (par le biais de la vérification des paramètres réseau et des licences de port), il est possible que la lame ait démarré sans que ses ressources DSP (Digital Signal Processor) soient disponibles.
Complétez ces étapes afin de vérifier ceci :
- Vérifiez la section État des rapports sur la page de résumé des lames à partir de l'interface utilisateur Supervisor :

- La lame affiche le nombre total de ressources vidéo qu'elle a démarrées avec succès et sous licence. Cette valeur doit être égale au nombre de licences de port attribuées à la lame, jusqu'à un maximum de 20 lorsque la lame est en mode haute définition (HD)/HD+ ou 80 lorsque la lame est en mode définition standard (SD). S'ils ne sont pas égaux, contactez le support technique de Cisco avec le comportement, les versions et le journal de diagnostic documentés.
Vérifications physiques sur la lame
Cette section décrit les étapes utilisées pour effectuer des contrôles physiques sur la lame, en fonction de l'interprétation de la lumière des DEL et du déplacement de la lame vers un autre emplacement.
Si vous ne parvenez pas à déterminer que la lame présente un problème matériel après avoir effectué les étapes décrites dans les sections précédentes, vérifiez physiquement le châssis de la gamme MSE 8000. Complétez ces étapes afin d'effectuer la vérification physique :
- Assurez-vous que le délai de démarrage de la lame est suffisant après avoir mis le châssis sous tension (ou installez la lame dans un châssis déjà sous tension). Cela prend environ 20 minutes.
- Observez et notez la couleur des DEL qui sont allumées à l'avant de la lame. Les principaux voyants LED sont les suivants :
- Alimentation (bleue) : ce voyant est situé juste au-dessus de la languette plastique inférieure et est allumé dès que la lame est alimentée.
- Status (vert) : ce voyant s'allume lorsque la lame est correctement amorcée.
- Alarme (rouge) : ce voyant est allumé lorsque la lame démarre ou lorsqu'elle ne peut pas démarrer.
- Liaison Ethernet Port A (trois vertes) : ce voyant indique l'activité, le duplex et la vitesse. Depuis la version 4.4, le 8510 prend uniquement en charge les connexions sur le port A ; Les ports B, C et D ne sont pas pris en charge.
Cette image montre huit lames MCU de la gamme MSE 8510 amorcées avec succès, et une qui est toujours en cours de démarrage ou ne peut pas démarrer correctement :

- Complétez ces étapes si vous rencontrez des problèmes lorsque vous observez les voyants LED :
- Si aucun des voyants n'est allumé, vérifiez que le reste du châssis est alimenté et que la lame est correctement insérée dans le logement.
- Si les voyants ne s'allument toujours pas, déplacez la lame vers un autre emplacement du châssis. De préférence, échangez-le avec un emplacement dont la lame de travail est connue.
- Si la lame ne s'allume toujours pas, contactez le support technique de Cisco.
- Si le voyant Power est allumé et qu'aucun autre voyant n'est allumé, contactez le support technique de Cisco. Si le feu d'alarme rouge reste allumé pendant plus de 30 minutes, reportez-vous à la section Accidents de ce document.
- Si le feu Power et le feu Status vert sont allumés, mais que le feu vert Port A n'est pas allumé, une RMA n'est pas nécessaire. Cela indique un problème de connexion au port du commutateur. Utilisez un nouveau port/commutateur/câble et vérifiez la configuration du port lame Ethernet A dans l'onglet Matériel du superviseur. Il est fortement recommandé de définir les deux côtés de la liaison pour la négociation automatique.
Note: Lors du dépannage, il est important d'obtenir un journal série et un journal de diagnostic. Celles-ci doivent être fournies lorsque vous ouvrez une demande de service auprès de l'assistance technique Cisco.
Atteindre les MCU sur l'interface Web
Les MCU Cisco Telepresence sont accessibles via une session de console via le câble de console fourni avec l'unité. Si le système n'est pas accessible via l'interface Web et ne répond pas aux requêtes ping, vous pouvez ouvrir une session de console à l'unité afin de le dépanner avec des vérifications des services activés, de la configuration des ports et de l'état.
Complétez ces étapes afin d'atteindre l'unité MCU si le système ne peut pas envoyer de requête ping, ou si vous ne pouvez pas accéder à l'interface Web du système après qu'une adresse IP lui a été attribuée :
- Vérifiez qu'aucun feu d'alarme rouge n'est allumé à l'avant de l'unité. Si l'unité est sous tension pendant plus de 20 minutes et que le voyant d'alarme rouge reste allumé, reportez-vous à la section Crashes de ce document.
- Si le voyant Status vert est allumé sur le périphérique, connectez votre PC au port de console via le câble de console fourni qui est arrivé avec l'unité.
Note: Reportez-vous à l'article Connexion au port de console d'une unité Codian acquise par Cisco pour obtenir des instructions sur la façon de réaliser cette étape.
- Afin de vérifier que la session de terminal connectée est effectivement connectée, appuyez plusieurs fois sur la touche Entrée et l'invite apparaît. L'invite qui s'affiche indique votre périphérique (IPGW:>, ISDNGW:> ou MCU:>, par exemple) :

- Afin de vérifier que les services HTTP et/ou HTTPS sont activés, entrez la commande service show :

- Afin de vérifier l'état de la liaison sur le périphérique, entrez la commande status :

- Si aucune liaison n'apparaît sur le port A, essayez de connecter votre câble Ethernet au port B afin de voir si l'état de la liaison change :

- Si le port B est en mesure de détecter la liaison mais que le port A ne l'est pas, procédez comme suit afin de vérifier à nouveau la configuration IP sur le port A :
- Si le port A semble ne pas poser de problème, essayez une procédure reset_config afin de rétablir les paramètres d'usine par défaut de l'unité.
Note: Référez-vous à l'article Réinitialisation d'un mot de passe et restauration d'une unité dans ses paramètres d'usine de Cisco pour plus d'informations sur cette procédure.
- Une fois le processus de réinitialisation en usine terminé, reconfigurez une adresse IP statique sur le port.
- Si vous rencontrez toujours des problèmes, redémarrez le système à partir de la console et collectez la sortie du démarrage dans un fichier texte via le client terminal utilisé :

Les lames MCU de la gamme MSE 8510 et les lames MCU de la gamme MSE 8710 présentent les deux interfaces Ethernet comme vfx0 et vfx1. Les systèmes montables en rack (gammes MCU 4500 et 4200, IPGW 3500 et RNIS GW 3241) présentent leurs interfaces Ethernet comme bge0 et bge1.
- Sur les lames des gammes MCU MSE 8510 et 8710, vérifiez que les adresses MAC sont attribuées et qu'il n'y a aucun problème avec vfx0 et ou vfx1.
- Sur les unités montables en rack, vous pouvez voir la sortie illustrée dans l'image suivante, avec bge0, ce qui indique une défaillance de la carte d'interface réseau (NIC) sur le périphérique. Ceci montre que la couche physique n'est pas détectée. Si cela s'affiche, contactez le support technique de Cisco.

- Si aucune liaison n'apparaît après l'échange du port, vérifiez la connectivité réseau. Idéalement, le résultat doit apparaître comme illustré dans l'image suivante, avec toutes les informations IP affichées. Cela indique que les paramètres IP de l'unité sont configurés correctement.
Note: Les informations d'adresse IP sont masquées dans l'image pour des raisons de sécurité.

- Modifiez l'adresse IP de l'unité afin de détecter un problème avec n'importe quel ensemble d'adresses IP sur le réseau.
- Déplacez le câble Ethernet sur un port de commutateur distinct afin d'éliminer tout problème de port de commutateur.
- Si un problème de port de commutateur est résolu, connectez un ordinateur portable directement à l'unité via un câble croisé et configurez l'ordinateur portable avec le même masque de sous-réseau, la même passerelle par défaut et la même adresse IP que celle contenue dans ce sous-réseau.
- Une fois l'adresse IP configurée sur l'ordinateur portable, envoyez une requête ping de l'ordinateur portable à l'unité. Essayez d'accéder à l'interface Web de l'unité à partir de l'ordinateur portable. En outre, essayez d'envoyer une requête ping à l'adresse IP de l'ordinateur portable à partir de la session de console de l'unité via la commande ping. S'il existe une connectivité et un accès Web, cela indique un problème de connectivité réseau. Si ce n'est pas le cas, il est possible qu'une broche de port Ethernet soit endommagée et vous devez contacter le support technique de Cisco.
Crashs
Une panne sur un produit MCU Cisco Telepresence peut être causée par un échec de démarrage complet, un cycle de redémarrage continu ou un incident qui se produit lors d'une conférence continue.
Si le voyant Alarme rouge de l'unité reste allumé pendant plus de 20 minutes, que vous ne pouvez pas naviguer jusqu'à l'interface Web de l'unité ou que vous ne pouvez pas passer d'appels vidéo, il est probable que l'unité n'a pas pu démarrer complètement ou qu'elle est bloquée dans un cycle de redémarrage. Dans ce cas, procédez comme suit afin de résoudre le problème :
- Débranchez le câble d'alimentation de l'unité. S'il s'agit d'une lame, retirez-la du châssis.
- Attendez cinq minutes et mettez l'unité sous tension.
- Si l'unité ne démarre pas normalement, collectez un journal de console, qui indique l'unité qui tente de démarrer. C'est le meilleur outil de diagnostic pour cette situation. Référez-vous à l'article Connexion au port de console d'une unité Codian acquise par Cisco pour plus d'informations sur la façon d'obtenir un journal de console.
- Mettez l'unité hors tension, puis sous tension.
- Attendez que la sortie s'arrête complètement ou que l'unité ait redémarré trois ou quatre fois. Contactez l'assistance technique Cisco et fournissez le journal de la console.
Dépannage du plateau de ventilation de la gamme MSE 8000, des redresseurs d'alimentation et de l'étagère d'alimentation
Le plateau de ventilation, les redresseurs d'alimentation et les étagères d'alimentation sont tous surveillés par le biais de la lame Supervisor MSE 8050. Vous pouvez résoudre tout problème ou problème lié à ces problèmes via l'interface Web de Supervisor. Cette section décrit les étapes utilisées pour dépanner un ventilateur, une étagère d'alimentation ou un redresseur d'alimentation en vérifiant les journaux et l'état.
Voici une image qui montre l'ensemble du châssis de la gamme MSE 8000 :

Remarque dans l'image précédente :
- Plateaux de ventilation supérieur et inférieur
- Les lames insérées
- Gros plan d'une lame individuelle
- Montage sur bâti
Note: Pour plus d'informations sur l'installation du châssis de la gamme MSE 8000, reportez-vous au guide de démarrage de Cisco TelePresence MSE 8000.
Dépannage d'une défaillance du ventilateur de la gamme MSE 8000
Utilisez cette section afin de dépanner les pannes de ventilateur sur un châssis de la gamme MSE 8000 par le biais de vérifications de l'état des alarmes et des journaux des événements sur la lame de la gamme Supervisor MSE 8050.
Voici un extrait d'un journal des événements qui présente les problèmes liés au plateau de ventilation supérieur :
37804 2012/07/03 18:43:28.567 HEALTH Warning
upper fan tray, fan 3 too slow - 1569 rpm
37805 2012/07/03 18:43:28.567 ALARMS Info
set alarm : 2 / Fan failure SET
37806 2012/07/03 18:43:44.568 ALARMS Info
clear alarm : 2 / Fan failure CLEAR
37807 2012/07/03 18:44:00.569 HEALTH Warning
upper fan tray, fan 3 too slow
Lorsque des erreurs comme celles-ci apparaissent, procédez comme suit afin de collecter les journaux requis :
- Afin de télécharger le fichier texte des journaux d'alarmes, accédez à Alarms > Alarms Log > Download as Text. Observez la date la plus récente à laquelle ce journal a été enregistré.
- Pour télécharger le fichier texte du journal des événements, accédez à Logs > Event Log > Download as Text.
- Accédez à Alarms > Alarms Status, puis prenez une capture d'écran de la page Alarm Status.
- Retirez le plateau de ventilation supérieur et vérifiez que tous les ventilateurs fonctionnent correctement.
- Retirez le plateau de ventilation inférieur et vérifiez que tous les ventilateurs fonctionnent correctement.
- Pour effacer les alarmes historiques du superviseur, naviguez jusqu'à Alarmes > Alarmes Status > Clear Historic Alarms.
- Pour effacer le journal des alarmes, accédez à Alarms > Alarms Log > Clear Log.
- Surveillez et vérifiez si les alarmes retournent.
- Si le problème se reproduit, remplacez le plateau supérieur par le plateau inférieur et déterminez si le problème suit le plateau de ventilation. Si le problème se reproduit et suit le plateau de ventilation, contactez le support technique de Cisco avec les journaux que vous avez collectés.
Problèmes liés à l'étagère d'alimentation
Dans le châssis de la gamme MSE 8000, deux entrées d'alimentation CC indépendantes peuvent être connectées directement à deux alimentations CC ou à deux étagères Valere qui convertissent le courant alternatif en courant continu. Le châssis de la gamme MSE 8000 peut être utilisé avec une ou deux étagères d'alimentation - A et B. Ces alimentations alimentent indépendamment chaque plateau de ventilation et chaque lame. L'unité peut être entièrement alimentée à partir de l'alimentation A ou B. En cas de défaillance de l'une ou l'autre des alimentations, l'unité continue de fonctionner, car elle tire de l'alimentation de l'autre alimentation.
Cisco recommande que, pour une redondance complète et une fiabilité maximale, les alimentations électriques soient connectées à des sources d'alimentation indépendantes. Chacun doit avoir la capacité de fournir la pleine charge électrique de l'unité et chaque étagère qui contient le même nombre de redresseurs.
Cette image montre l'étagère d'alimentation CC de la gamme MSE 8000 :

Voici deux problèmes courants que vous pourriez rencontrer :
- Contact perdu avec l'étagère d'alimentation - Lorsque vous naviguez jusqu'à Matériel > Alimentations, l'alimentation A affiche Contact perdu avec l'étagère d'alimentation. Cela signifie que le Supervisor MSE 8050 ne peut pas communiquer avec l'étagère d'alimentation.
- 10/Alimentation externe hors limites SET : cela signifie que les tensions d'entrée du châssis ne sont pas conformes aux spécifications. Vérifiez que l'alimentation et le courant appropriés sont fournis au châssis via le calcul de la puissance et les exigences actuelles d'un outil en ligne MSE 8000.
S'il n'y a pas d'incohérences rencontrées lors de la vérification de l'alimentation et de la mise à jour précédemment mentionnées, récupérez ces informations et contactez le support technique Cisco :
- Configuration du superviseur de la gamme MSE 8050
- Journal d'audit
- Journal des alarmes
- Journal des événements
- Capture d'écran de la page Alarm Status
- Nombre et modèle de lames dans le châssis
- État des alimentations
Configurer la surveillance de l'état de l'alimentation
Cisco vous recommande de configurer la surveillance de l'état de l'alimentation afin de fournir des commentaires fiables à l'administrateur vidéo concernant les erreurs, avertissements ou autres informations importantes affichées dans les journaux.
Afin d'activer la surveillance des tensions d'alimentation, ainsi que des étagères d'alimentation CA vers CC (si nécessaire), complétez les étapes de la page 61 de l'aide en ligne de Cisco TelePresence Supervisor 2.3 (format imprimable). Effacez les journaux une fois la configuration de l'état de l'alimentation terminée.
Vérifiez le câble de surveillance du module d'alimentation qui s'étend de l'arrière du module d'alimentation au châssis. Il s'agit d'un câble spécial qui est utilisé pour la surveillance des étagères d'alimentation. Prenez soin de vérifier le câble, car il peut être facilement confondu avec un câble de console DB9-RJ45 standard. Le câble de surveillance de l'étagère d'alimentation est étiqueté avec un autocollant indiquant Power Shelf Rear :

Deux paires de connecteurs sont situées à l'arrière du châssis de la gamme MSE 8000 : la paire à gauche est étiquetée Logement 10, et la paire à droite est étiquetée Logement 1. Assurez-vous que les câbles de surveillance sont connectés au logement 1, qui sont les connecteurs qui représentent le logement du superviseur de la gamme MSE 8050.
Si vous rencontrez des problèmes avec la configuration de la surveillance du module d'alimentation, procédez comme suit :
- Remplacez le câble de surveillance de l'étagère d'alimentation de l'étagère A par l'étagère B afin de déterminer si le problème suit le câble. Si le problème est lié au câble, contactez le support technique de Cisco.
- Remplacez les cartes NIC par les cartes Power Shelf A et Power Shelf B afin de déterminer si les cartes NIC sont la cause du problème. Si les alarmes reviennent et que le problème suit la carte réseau, contactez le support technique de Cisco.
Cette image montre la carte NIC du module d'alimentation :

Dépannage des redresseurs d'alimentation
Dans certains cas, vous pouvez rencontrer des problèmes avec l'un des redresseurs d'alimentation. Cette section décrit comment résoudre ces problèmes.
Voici une vue avant de l'étagère d'alimentation avec des redresseurs :

Voici la vue arrière de l'étagère d'alimentation :

Complétez ces étapes afin de résoudre un problème avec les redresseurs d'alimentation :
- Si une erreur apparaît sur le redresseur, réinsérez-la et attendez de voir si l'erreur apparaît toujours (les redresseurs sont enfichables à chaud).
- Si l'erreur apparaît après quelques minutes, placez le redresseur dans un autre emplacement de l'étagère d'alimentation A ou B afin de déterminer si le problème se situe avec le redresseur ou le logement de l'étagère d'alimentation.
- Si vous rencontrez toujours des problèmes, contactez le support technique Cisco et fournissez les informations suivantes :
- Image du redresseur en état d'alarme
- Numéro de série du redresseur (situé à gauche du côté droit du redresseur)
- Capture d'écran de la page Alimentations (Matériel > Alimentations)
- Capture d'écran de la page Health (Status > Health)
- Journal d'audit
- Journal des alarmes
- Journal des événements
Dépannage des problèmes liés à Cisco TelePresence ISDN GW
Les GW RNIS Cisco Telepresence assurent une intégration transparente entre les réseaux IP et RNIS, avec une transparence totale des fonctionnalités via RNIS. Cette section décrit comment dépanner les interfaces RNIS PRI et les tampons sur les DSP.
PRI couche 1 et couche 2 descendante
Utilisez cette section afin de dépanner les problèmes d'interface PRI sur l'GW RNIS. Le port PRI peut être vérifié avec le plug-in de bouclage afin de déterminer s'il est défectueux :
- La couche 1 (L1) indique la couche physique, ou connectivité PRI.
- La couche 2 (L2) est utilisée pour la signalisation.
Vous pouvez utiliser un câble de bouclage afin de déterminer l'état L1 du port PRI sur la passerelle RNIS GW. Connectez Pin1 à Pin4 et Pin2 à Pin5 afin de créer le câble de bouclage.

Branchez le câble de bouclage sur le port 1, puis vérifiez l'état L1. Si l'état L1 sur le port 1 apparaît Up, il est probable que le problème est causé par les câbles utilisés. Vous pouvez utiliser le câble de bouclage plus bas sur la ligne afin d'isoler le problème.
Si l'état L1 sur le port 1 apparaît Down avec le câble de bouclage, activez le port 2 pour PRI sur RNIS GW. Testez le port 2 avec le câble de bouclage. Si le problème persiste avec un port spécifique, il est possible qu'il y ait une défaillance du port PRI. Contactez le support technique de Cisco.
Erreurs Ping Pong et temporisations DSP
Il existe deux tampons sur un DSP appelés Ping et Pong. Chaque tampon traite dix millisecondes de données (une trame RNIS) à la fois. L'intention est de traiter un tampon pendant que vous lisez le suivant. Si ces deux mémoires tampon ne sont pas synchronisées, elles sont échangées pour tenter de se synchroniser.
Voici un exemple tiré du journal des événements Cisco Telepresence ISDN GW, où les tampons ne sont pas synchronisés et tentent de se corriger :
14031 2012/02/29 13:03:05.143 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14032 2012/02/29 13:03:05.399 dspapi Error DSP(05):
"Ping Pong buffer out of sync 1, 11111111"
14033 2012/02/29 13:03:05.399 dspapi Info DSP(05):
"Attempt to correct Ping Pong buffer sync"
14034 2012/02/29 13:03:05.400 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14035 2012/02/29 13:03:05.856 dspapi Error DSP(05):
"Ping Pong buffer out of sync 1, 11111111"
14036 2012/02/29 13:03:05.856 dspapi Info DSP(05):
"Attempt to correct Ping Pong buffer sync"
14037 2012/02/29 13:03:05.862 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14064 2012/02/29 13:03:21.626 dspapi Info DSP(04):
"receive from local primary dsp timeout"
14065 2012/02/29 13:03:21.626 dspapi Info DSP(03):
"receive from local primary dsp timeout"
14066 2012/02/29 13:03:21.638 dspapi Info DSP(15):
"receive from peer primary dsp timeout (rx)"
Voici quelques questions à prendre en compte :
- Pourquoi ne sont-ils pas synchronisés ?
- Est-il possible que des trames non valides, une horloge RNIS défectueuse ou une PRI non fiable causent le problème ?
Voici une liste d'informations à collecter :
- Combien de PRI sont connectés à cette passerelle ?
- Tous les PRI proviennent-ils du même commutateur ou de commutateurs différents ?
- Si tous les PRI sont débranchés et que le système est redémarré, les erreurs continuent-elles ? Collectez un journal de console qui affiche ces erreurs.
- Si seulement PRI 1 est connecté, les erreurs retournent-elles ?
- Si seulement PRI 2 est connecté, les erreurs retournent-elles ? Répétez avec tous les PRI, un à la fois.
Si des PRI de différents commutateurs sont utilisés, les horloges PRI doivent être synchronisées (les PRI de la même compagnie de téléphone le sont normalement). Il est possible que le PRI d'un commutateur ait une horloge qui est complètement désynchronisée avec l'horloge du PRI de l'autre commutateur. Si un seul PRI est connecté et semble correct, alors connectez un PRI à partir d'un commutateur et un PRI à partir de l'autre, redémarrez le système, et voyez si les erreurs retournent. Enregistrez vos tests et votre comportement pour fournir au support technique Cisco si nécessaire.
Informations connexes