Introduction
Ce document décrit les procédures utilisées afin de dépanner les produits Cisco TelePresence Multipoint Control Unit (MCU). Ce document est destiné aux administrateurs système vidéo et aux partenaires Cisco dont les clients sont des administrateurs système vidéo.
La gamme de produits MCU est un produit de conférence multimédia leader sur le marché. Il s'agit de systèmes intégrés complexes, avec du matériel conçu par Cisco afin de fournir les meilleures performances. Ce document vise à 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 accordée par un ingénieur d'assistance technique Cisco, qui vérifie que le produit a réellement échoué lors d'une série de tests, en fonction du composant suspecté. Ce guide vise à accélérer ce processus en fournissant des informations sur ces tests.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Gamme Cisco TelePresence MCU MSE
- Cisco TelePresence MCU, série 5300
- Cisco TelePresence MCU, série 4500
- Cisco TelePresence MCU, série 4200
- Passerelle RNIS Cisco TelePresence (GW)
Composants utilisés
Les informations contenues dans 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 Cisco TelePresence MCU MSE Series
Cette section décrit quelques-unes des vérifications de base qui sont utilisées afin de confirmer que votre serveur lame MCU MSE Series est opérationnel et ne souffre pas d'une défaillance matérielle. Le comportement de l'unité MCU doit être documenté à mesure que ces vérifications sont effectuées.
Effectuer une vérification rapide du MCU
Cette section fournit une liste de contrôle que vous pouvez utiliser afin de dépanner la configuration de base d'un MCU via son interface Web. Ceci est complété par des vérifications des paramètres H.323, du standard automatique, de l'utilisation de la licence de port et des appels de bouclage.
Vérifiez que le serveur 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 du processeur MCU. La page d'accueil doit s'afficher immédiatement.
Remarque : si la page Web est inaccessible, reportez-vous à la section Vérifier la connectivité réseau du processeur 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.
Remarque : si une version antérieure à la version 4.3 est actuellement utilisée, il est recommandé de consulter les notes de version les plus récentes et d'envisager une mise à niveau.
- Si vous pouvez accéder à l'interface Web, procédez comme suit :
- Accédez à Settings > H.323, et définissez H.323 gatekeeper usage sur Disabled. 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 Appels entrants vers des conférences inconnues ou des standardistes est défini sur Standard automatique.
- Créez une nouvelle conférence et ajoutez un participant H.323 avec l'adresse IP 127.0.0.1. Le processeur MCU se reconnecte alors à son propre système de 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 lorsque le MCU peut s'appeler lui-même :
Si cela fonctionne et qu'un participant connecté apparaît (comme dans l'image précédente), il y a très probablement un problème d'interopérabilité entre le portier, le réseau ou le point d'extrémité. Composez un numéro de terminal réel et effectuez le dépannage à partir de là avec le journal des événements et le journal H323/SIP (Session Initiation Protocol). 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 Port License management 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 carte dans ce logement sans aucune licence de port qui lui est attribuée. Ce serveur lame ne peut pas passer d'appels. Par conséquent, le test de bouclage décrit à l'étape 3 aurait échoué sur ce serveur 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 logement affiche un symbole d'avertissement, cela signifie qu'il n'y a pas de lame dans le logement. Un bloc demi-bleu indique que des licences de port sont attribuées à la lame, mais pas qu'elle est à pleine capacité. Un serveur lame comme celui-ci ne peut pas connecter le nombre total de ports annoncés tant qu'il ne dispose pas de licences supplémentaires.
- Attribuez des licences de port si aucune n'est attribuée à la lame (cette procédure est décrite dans l'aide en ligne). Si aucune clé n'est présente pour les licences de port, contactez votre gestionnaire de compte.
Remarque : si l'appel échoue, même si le serveur lame dispose de licences de port suffisantes, reportez-vous à la section Atteindre les MCU sur l'interface Web de ce document. Si l'interface Web devient indisponible au cours de ce test et que le contact avec la lame est perdu, la lame a peut-être redémarré ; récupérez le journal de diagnostic de la lame et contactez le support technique Cisco.
Vérifier la connectivité réseau du MCU
Utilisez cette section afin de résoudre les problèmes liés aux tentatives de connexion à l'interface Web du processeur MCU à partir d'un navigateur, sur la base de la vérification de la connectivité et de la configuration réseau.
Vous pouvez rencontrer l'un des problèmes suivants lorsque vous tentez de vous connecter à l'interface Web du processeur MCU à partir d'un navigateur :
- Un problème de réseau entre le PC et l'unité MCU
- Problème avec le processeur MCU lui-même (carte réseau, matériel ou configuration)
Complétez ces étapes afin de dépanner le problème :
- Essayez d'envoyer une requête ping à l'adresse IP du MCU.
Remarque : 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, il est possible qu'elle n'ait pas pu démarrer complètement ou qu'elle soit verrouillée dans un cycle de redémarrage. Si tel est le cas, reportez-vous à la section Contrôles physiques sur 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 carte Supervisor MSE 8050 du châssis qui contient la carte MCU MSE 8510. Si l'interface utilisateur de la carte Supervisor Blade n'est pas accessible, contactez vos administrateurs réseau locaux afin d'étudier un éventuel problème réseau. Si l'interface utilisateur de la carte Supervisor est accessible et que le Supervisor et le MCU ne sont pas sur des réseaux différents, il est probable que le problème provient de la carte ou de ses paramètres IP.
- Dans l'interface utilisateur de la carte Supervisor, accédez à Hardware, et cliquez sur le lien du numéro de logement de la carte MCU MSE 8510. Cliquez ensuite sur l'onglet Port A.
- Vérifiez la configuration IP du port MCU A, et vérifiez qu'aucun autre hôte sur le réseau ne se voit attribuer la même adresse IP. 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.
- Consultez la section État Ethernet du port A. Si l'état de la liaison n'est pas up, vérifiez que le câble réseau est connecté au commutateur. Un problème peut survenir au niveau du câble ou du port du commutateur.
- Si l'unité MCU est désormais 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 endroit du réseau, reportez-vous à la section Vérification de la lame MCU MSE 8510 via le superviseur de ce document.
Vérifiez le serveur lame MCU MSE 8510 via le superviseur
Complétez ces étapes afin de vérifier l'état de la carte MCU et de la conférence, l'état et les rapports sur la disponibilité, la version du logiciel, la température et la tension :
- Cliquez sur Hardware, 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 :
- L'état de la lame, avec l'adresse IP, la disponibilité, le numéro de série et la version du logiciel
- L'état de la lame, avec les températures, la tension et la batterie RTC (Real-Time Clock)
- L'état Signalé pour les conférences actives, le nombre de participants, les ports audio/vidéo en cours d'utilisation et les visionneuses en continu
Cette image présente la section d'intégrité de la lame :
- Si l'état de la tension (actuelle ou pire) n'apparaît pas OK, vérifiez que suffisamment 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 l'article Calculating power and current requirements for an MSE 8000 de Cisco.
- Si l'option Alimentation ne s'affiche pas OK, contactez le support technique de Cisco.
- Si l'un des autres états actuels de la section État de la lame 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 observés n'indiquent pas OK, obtenez le journal des événements et les journaux des alarmes auprès du superviseur, et contactez le support technique de Cisco.
- Vérifiez la disponibilité. Si le temps de disponibilité est étonnamment court (moins de 30 minutes) et qu'il n'y a aucune raison connue (s'il n'a pas été mis hors tension ou si la lame n'a pas été réinstallée, par exemple), la lame a peut-être 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 ponctuel ou cyclique.
Complétez ces étapes afin de déterminer ceci :
- Attendez 30 minutes.
- Actualisez la page.
- Vérifiez à nouveau la disponibilité.
Si vous pouvez déterminer à partir de la durée de disponibilité actualisée que la carte a redémarré ultérieurement, reportez-vous à la section Crashes de ce document.
- Si la carte ne redémarre pas après avoir vérifié la page d'état et qu'elle semble fonctionnelle à tous les autres égards (par la vérification des paramètres réseau et des licences de port), il est possible qu'elle ait démarré sans aucune de ses ressources DSP (Digital Signal Processor) disponibles.
Complétez ces étapes afin de vérifier ceci :
- Vérifiez la section État signalé sur la page résumé de la lame à partir de l'interface utilisateur de Supervisor :
- La lame affiche le nombre total de ressources vidéo qu'elle a démarrées et dont la licence a été délivrée. Ce nombre doit être égal 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 de 80 lorsque la lame est en mode Définition standard (SD). Si ces valeurs ne sont pas identiques, contactez l'assistance technique de Cisco pour obtenir des informations sur le comportement, les versions et le journal de diagnostic.
Contrôles physiques sur la lame
Cette section décrit les étapes à suivre pour effectuer des contrôles physiques sur la lame, en fonction de l'interprétation de la lumière LED et du déplacement de la lame vers un autre emplacement.
Si vous ne parvenez pas à déterminer si 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 vous disposez d'un délai suffisant pour le démarrage de la lame après la mise sous tension initiale du châssis (ou installez la lame dans un châssis déjà sous tension). Cela prend environ 20 minutes.
- Observez et notez la couleur des voyants qui s'allument à l'avant de la lame. Les principaux voyants sont les suivants :
- Alimentation (bleu) : ce voyant est situé juste au-dessus de la languette en plastique inférieure et s'allume dès que la lame est alimentée.
- Status (vert) (Etat) : ce voyant s'allume lorsque la carte est correctement amorcée.
- Alarme (rouge) : ce voyant s'allume lorsque la lame démarre ou lorsqu'elle ne peut pas démarrer.
- Liaison Ethernet Port A (trois en vert) : le voyant indique l'activité, le mode bidirectionnel 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 MSE 8510 démarrées avec succès, et une qui démarre toujours ou ne peut pas démarrer avec succès :
- Effectuez ces étapes si vous rencontrez des problèmes lorsque vous observez les voyants :
- 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 logement du châssis. De préférence, interchangez-le avec une fente présentant une lame de travail connue.
- Si le serveur lame ne se met toujours pas sous tension, contactez le support technique Cisco.
- Si le voyant d'alimentation bleu est allumé et qu'aucun autre voyant ne l'est, contactez le support technique Cisco. Si le voyant d'alarme rouge reste allumé pendant plus de 30 minutes, reportez-vous à la section Crashes de ce document.
- Si le voyant bleu Power et le voyant vert Status sont allumés, mais que le voyant vert Port A ne l'est pas, une RMA n'est pas nécessaire. Cela indique un problème de connexion au port de commutation. Utilisez un nouveau câble/port de commutateur/commutateur et vérifiez la configuration du port Ethernet A de la lame dans l'onglet Matériel du superviseur. Il est fortement recommandé que les deux côtés de la liaison soient définis pour la négociation automatique.
Remarque : lors du dépannage, il est important d'obtenir un journal série et un journal de diagnostic. Ces informations 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 sur l'unité afin de le dépanner avec des vérifications des services activés, de la configuration des ports et de l'état.
Effectuez ces étapes afin d'atteindre le MCU si le système ne peut pas envoyer de requête ping, ou si vous ne pouvez pas naviguer vers l'interface Web du système après qu'une adresse IP lui a été attribuée :
- Vérifiez qu'aucun voyant d'alarme rouge ne s'allume à 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 d'état vert s'allume sur le périphérique, connectez votre PC au port de console par le biais du câble de console fourni avec l'unité.
Remarque : 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 réellement connectée, appuyez sur la touche Entrée plusieurs fois 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 capable de détecter la liaison mais que le port A ne l'est pas, alors complétez ces étapes afin de vérifier la configuration IP sur le port A à nouveau :
- Si le port A semble n'avoir aucun problème, alors essayez une procédure reset_config afin de ramener l'unité aux paramètres d'usine par défaut.
Remarque : consultez l'article Cisco Réinitialisation d'un mot de passe et restauration des paramètres d'usine d'une unité pour plus d'informations sur cette procédure.
- Une fois le processus de réinitialisation d'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 le résultat du démarrage dans un fichier texte via le client terminal utilisé :
Les serveurs lames MCU MSE 8510 et MCU MSE 8710 présentent les deux interfaces Ethernet sous la forme vfx0 et vfx1. Les systèmes montables en rack (gammes MCU 4500 et 4200, IPGW 3500 et ISDN GW 3241) présentent leurs interfaces Ethernet sous la forme bge0 et bge1.
- Sur les serveurs lames 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, qui indique une défaillance de la carte d'interface réseau (NIC) sur le périphérique. Cela indique que la couche physique n’est pas détectée. Si tel est le cas, contactez l'assistance technique Cisco.
- Si aucune liaison n'apparaît après l'échange du port, vérifiez la connectivité réseau. Idéalement, le résultat devrait 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.
Remarque : les informations d'adresse IP sont masquées dans l'image pour des raisons de sécurité.
- Modifiez l'adresse IP sur 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 vers un port de commutateur séparé afin d'éliminer tout problème de port de commutateur.
- Si un problème de port de commutateur est éliminé, 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. Essayez également d'envoyer une requête ping de la session de console de l'unité à l'adresse IP de l'ordinateur portable via la commande ping. S'il y a connectivité et 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.
Crashes
Une panne sur un produit Cisco Telepresence MCU 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 d'alarme rouge de l'unité reste allumé pendant plus de 20 minutes, que vous ne pouvez pas accéder à 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. Si tel est le cas, procédez comme suit afin de résoudre le problème :
- Débranchez le cordon d'alimentation de l'unité. S'il s'agit d'une lame, retirez-la du châssis.
- Attendez cinq minutes, puis 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. Consultez l'article Connexion au port de console d'une unité Codian acquise par Cisco pour obtenir des informations sur l'obtention d'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, des redresseurs d'alimentation et de l'étagère d'alimentation de la gamme MSE 8000
L'unité de ventilation, les redresseurs d'alimentation et les étagères d'alimentation sont tous surveillés par l'intermédiaire de la lame de la gamme Supervisor MSE 8050. Vous pouvez dépanner toute défaillance ou tout problème lié à ceux-ci via l'interface Web de Supervisor. Cette section décrit les étapes à suivre pour dépanner un ventilateur, une étagère d'alimentation ou un redresseur d'alimentation en cas de panne, grâce à la vérification des journaux et de l'état.
Voici une image qui montre le châssis complet de la gamme MSE 8000 :
Remarque dans l'image précédente :
- Les plateaux de ventilation supérieur et inférieur
- Les lames insérées
- Gros plan d'une lame individuelle
- Montage sur bâti
Remarque : pour plus d'informations sur l'installation du châssis de la gamme MSE 8000, reportez-vous au guide de mise en route 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 d'événements sur la lame de la gamme Supervisor MSE 8050.
Voici un extrait d'un journal d'événements qui montre les problèmes avec l'unité de ventilation supérieure :
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 telles que 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, naviguez vers Alarms > Alarms Log > Download as Text. Observez la date la plus récente de consignation.
- Pour télécharger le fichier texte du journal des événements, accédez à Journaux > Journal des événements > Télécharger en tant que texte.
- Accédez à Alarms > Alarms Status, et prenez une capture d'écran de la page Alarm Status.
- Retirez l'unité de ventilation supérieure 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.
- Afin d'effacer les alarmes historiques du superviseur, naviguez à Alarmes > État des alarmes > Effacer les alarmes historiques.
- Afin d'effacer le journal des alarmes, naviguez à Alarmes > Journal des alarmes > Effacer le journal.
- Surveillez et vérifiez si les alarmes reviennent.
- Si le problème réapparaît, remplacez le plateau supérieur par le plateau inférieur et déterminez si le problème provient du plateau de ventilation. Si le problème se reproduit et suit l'unité de ventilation, contactez le support technique Cisco en vous munissant des journaux que vous avez collectés.
Problèmes de tablette électrique
Dans le châssis de la gamme MSE 8000, il existe deux entrées d'alimentation CC indépendantes que vous pouvez connecter 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 un ou deux modules d'alimentation, A et B. Ils alimentent chaque unité de ventilation et chaque lame indépendamment. L'unité peut être entièrement alimentée à partir de l'alimentation A ou de l'alimentation B. En cas de défaillance de l'une des alimentations, l'unité continue à fonctionner, car elle est alimentée par l'autre alimentation.
Cisco recommande que, pour une redondance complète et une fiabilité maximale, les alimentations soient connectées à des sources d'alimentation indépendantes. Chaque module doit être en mesure de fournir la pleine charge électrique de l'unité et chaque module doit contenir le même nombre de redresseurs.
Cette image présente l'étagère d'alimentation CC de la gamme MSE 8000 :
Voici deux problèmes courants liés au module d'alimentation que vous pouvez rencontrer :
Si vous ne rencontrez aucune différence lors de la vérification de l'alimentation et du courant mentionnée précédemment, récupérez ces informations et contactez l'assistance technique Cisco :
- Configuration des superviseurs 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 modules d'alimentation
Configurer la surveillance de l'alimentation
Cisco recommande de configurer la surveillance de l'état de l'alimentation afin de fournir des commentaires fiables à l'administrateur vidéo concernant les erreurs, les avertissements ou d'autres informations importantes affichées dans les journaux.
Afin de permettre la surveillance des tensions d'alimentation, ainsi que des étagères d'alimentation CA vers CC (si nécessaire), suivez 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 de l'étagère d'alimentation qui relie l'arrière de l'étagère d'alimentation au châssis. Il s'agit d'un câble spécial utilisé pour la surveillance des étagères d'alimentation. Prenez soin de vérifier le câble, car il peut facilement être 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 qui indique Power Shelf Rear:
Deux paires de connecteurs sont situées à l'arrière du châssis de la gamme MSE 8000 : la paire de gauche est étiquetée Slot 10 et la paire de droite est étiquetée Slot 1. Assurez-vous que les câbles de surveillance sont connectés au logement 1, qui sont les connecteurs qui représentent le logement de superviseur de la gamme MSE 8050.
Si vous rencontrez des problèmes avec la configuration de la surveillance de l'étagère 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 provient du câble. Si le problème provient du câble, contactez le support technique Cisco.
- Échangez les cartes NIC de l'étagère d'alimentation A et de l'étagère d'alimentation B afin de déterminer si les cartes NIC sont la cause du problème. Si les alarmes reviennent et que le problème provient de la carte réseau, contactez le support technique Cisco.
L'image suivante illustre la carte NIC de l'étagère d'alimentation :
Dépannage des redresseurs d'alimentation
Dans certains cas, vous pouvez rencontrer des problèmes avec l'un des redresseurs de puissance. Cette section décrit comment résoudre ces problèmes.
Voici une vue de face de l'étagère d'alimentation avec des redresseurs :
Voici la vue arrière du module d'alimentation :
Complétez ces étapes afin de résoudre un problème avec les redresseurs de puissance :
- Si une erreur apparaît sur le redresseur, réinstallez-le et attendez de voir si l'erreur apparaît toujours (les redresseurs sont enfichables à chaud).
- Si l'erreur apparaît toujours après quelques minutes, installez le redresseur dans un autre logement de l'étagère d'alimentation A ou B afin de déterminer si le problème est lié au redresseur ou au logement de l'étagère d'alimentation.
- Si vous rencontrez toujours des problèmes, contactez l'assistance technique Cisco et fournissez les informations suivantes :
- Image du redresseur à l'état d'alarme
- Numéro de série du redresseur (situé à gauche ou à droite du redresseur)
- Capture d'écran de la page Blocs d'alimentation (Matériel > Blocs d'alimentation)
- 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 passerelles Cisco Telepresence ISDN GW 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 processeurs DSP.
Couche 1 et couche 2 PRI désactivées
Utilisez cette section afin de dépanner les problèmes d'interface PRI sur la passerelle RNIS. Le port PRI peut être vérifié avec la fiche de bouclage afin de déterminer s'il est défectueux :
- La couche 1 (L1) indique la couche physique ou la 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. 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, et vérifiez l'état de 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 qui sont utilisés. Vous pouvez utiliser le câble de bouclage plus loin dans 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 ISDN GW. Testez également 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 délais d'attente DSP
Il existe deux mémoires tampon sur un DSP appelées Ping et Pong. Chaque tampon traite dix millisecondes de données (une trame RNIS) à la fois. L'intention est de traiter une mémoire tampon pendant que vous lisez la suivante. Si ces deux mémoires tampon ne sont pas synchronisées, elles sont échangées pour tenter de se resynchroniser.
Voici un exemple 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 un PRI non fiable soient à l'origine du 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 se poursuivent-elles ? Collectez un journal de console qui affiche ces erreurs.
- Si seul PRI 1 est connecté, les erreurs se reproduisent-elles ?
- Si seul PRI 2 est connecté, les erreurs se reproduisent-elles ? Répétez l'opération avec tous les PRI, un par un.
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 complètement désynchronisée de l'horloge du PRI de l'autre commutateur. Si un seul PRI est connecté et semble correct, connectez un PRI à partir d'un commutateur et un PRI à partir de l'autre, redémarrez le système et vérifiez si les erreurs se reproduisent. Enregistrez vos tests et votre comportement pour les transmettre à l'assistance technique Cisco si nécessaire.
Informations connexes