Le matériel de la TelePresence MCU dépannent le guide
Contenu
Introduction
Ce document décrit les procédures utilisées afin de dépanner les Produits multipoints de l'unité de contrôle de TelePresence Cisco (MCU). Le document est écrit pour des administrateurs du système de système vidéo et pour les Partenaires de Cisco dont les clients sont des administrateurs du système de système vidéo.
La gamme MCU des Produits sont des Produits de système de conférence multimédia de leader. Ils sont les systèmes intégrés complexes, avec le matériel conçu par Cisco afin de donner la meilleure représentation. Ce document est destiné pour faciliter la résolution de n'importe quelle situation qui pourrait sont provoqué par par une défaillance matérielle d'un produit de Cisco MCU. Un retour à l'autorisation de fabrication (RMA) doit être donné par un ingénieur de support technique de Cisco, qui vérifie que le produit vraiment a manqué par une plage des tests, dépendant sur le composant suspecté. Ce guide vise à accélérer ce processus avec la vue dans ces tests.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Cisco TelePresence MCU série MSE
- Gamme 5300 de la TelePresence Cisco MCU
- Cisco TelePresence MCU série 4500
- Cisco TelePresence MCU série 4200
- Gamme de la passerelle RNIS Cisco TelePresence (gw)
Composants utilisés
Les informations dans ce document sont basées sur la gamme de l'engine de services de médias de la TelePresence Cisco MCU (MSE).
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.
Produits connexes
Ce document peut également être utilisé avec les versions de matériel et de logiciel suivantes :
- Serveur Cisco TelePresence 7010
- Gamme 5300 de la TelePresence Cisco MCU
- Cisco TelePresence MCU série 4500
- Cisco TelePresence MCU série 4200
- Gamme de passerelle RNIS Cisco TelePresence
Liste de contrôle du Cisco TelePresence MCU série MSE RMA
Cette section décrit certains des contrôles plus fondamentaux qui sont utilisés afin de confirmer que votre lame de gamme MCU MSE est opérationnelle, et ne souffrent pas d'une défaillance matérielle. Le comportement MCU devrait être documenté en tant que ces contrôles sont terminés.
Terminez-vous un contrôle rapide sur le MCU
Cette section fournit une liste de contrôle que vous pouvez employer afin de dépanner la configuration de base d'un MCU par son interface web. Ceci est terminé avec des vérifications H.323 des configurations, de la réception automatique, de l'utilisation de permis de port, et des appels en boucle.
Vérifiez que la lame peut faire un appel vidéo. Si l'interface web MCU peut être accédée à, et un appel peut être fait, il est fondamentalement fonctionnel. Procédez comme suit :
- Ouvrez un navigateur Web et naviguez vers l'adresse IP MCU. La page d'accueil doit afficher immédiatement.
- Cliquez sur le lien d'état afin de vérifier la version logicielle qui fonctionne actuellement sur le MCU.
- Si vous pouvez accéder à l'interface web, terminez-vous ces étapes :
- Naviguez vers des configurations > H.323, et placez le contrôleur d'accès H.323 que l'utilisation a désactivé. Cette étape est essentielle parce que quelques garde-portes empêchent les appels directement d'un MCU à une adresse IP.
- Naviguez vers des configurations > des conférences > des paramètres avancés, et assurez-vous que des appels entrant aux conférences inconnues ou aux réceptions automatiques est placés pour transférer la réception automatique.
- Créez une nouvelle conférence, et ajoutez H.323 un participant avec une adresse IP de 127.0.0.1. Ceci fait composer le MCU de nouveau à sa propre réception automatique (aa). Les affichages de l'écran aa dans l'aperçu d'aperçu, et les deux codecs audios et vidéos sont négociés dans chaque direction.
Voici un exemple de l'écran MCU MSE 8510 quand le MCU peut avec succès s'appeler :
Si ceci fonctionne, et un participant connecté est vu (semblable à l'image précédente), il y a très probablement un garde-porte, un réseau, ou un problème d'interopérabilité de point final. Composez un vrai point final, et le dépannez de là avec le journal d'événements et le log d'Initiation Protocol H323/Session (SIP). Si la connexion échoue toujours immédiatement, mais les travaux d'interface web, continuez cette procédure. - Afin de vérifier que les permis de port sont assignés au MCU, allez à la section Gestion de permis de port de la lame de superviseur. Voici une image qui affiche l'allocation de permis de port de la lame du superviseur MSE 8050 :
Dans l'image, le bloc vide sous l'emplacement 4 prouve qu'il y a une lame dans cet emplacement sans des permis de port alloués à lui. Cette lame ne peut pas faire des appels, ainsi le test de bouclage décrit dans le C d'étape aurait manqué sur cette lame. Les blocs de bleu sous les emplacements 2, 3, 5, et 7 prouvent que ces emplacements ont une pleine allocation des permis de port. Si un emplacement affiche un symbole d'avertissement, alors il n'y a aucune lame dans l'emplacement. Un bloc moitié-bleu indique que la lame a quelques permis de port alloués à elle, mais pas qu'elle est à la capacité totale. Une lame comme ceci ne peut pas connecter son nombre de ports annoncé par total jusqu'à ce qu'elle ait plus de permis alloués à elle.
- Assignez les permis de port s'il n'y en a aucun assigné à la lame (ce processus est décrit dans l'aide en ligne). Si aucune clé n'est présente pour des permis de port, contactez votre gestionnaire de comptes.
- Naviguez vers des configurations > H.323, et placez le contrôleur d'accès H.323 que l'utilisation a désactivé. Cette étape est essentielle parce que quelques garde-portes empêchent les appels directement d'un MCU à une adresse IP.
Vérifiez la connexion réseau MCU
Employez cette section afin de dépanner des questions avec des tentatives de se connecter à l'interface web MCU d'un navigateur, basé sur la vérification de la connexion réseau et de la configuration réseau.
Vous pourriez rencontrer une de ces questions quand vous tentez de se connecter à l'interface web MCU d'un navigateur :
- Un problème avec le réseau entre le PC et le MCU
- Un problème avec le MCU lui-même (network interface card (NIC), matériel, ou configuration)
Terminez-vous ces étapes afin de dépanner la question :
- Tentative de cingler l'adresse IP du MCU.
Si le MCU répond aux pings, mais l'interface web est en baisse, le MCU pourrait pour démarrer entièrement, ou il pourrait être verrouillé dans un cycle de réinitialisation. Si c'est le cas, mettez en référence les contrôles physiques sur la section de lame de ce document. Si le MCU ne répond pas aux pings, continuez cette procédure. - Naviguez vers l'interface web de la lame du superviseur MSE 8050 du châssis qui contient la lame MCU MSE 8510. Si l'interface utilisateur de lame de superviseur ne peut pas être atteinte, alors contactez vos administrateurs de réseau local afin d'étudier un problème de réseau possible. Si l'interface utilisateur de lame de superviseur peut être atteinte, et le superviseur et le MCU ne sont pas sur différents réseaux, alors il est probable que le problème soit avec la lame ou ses paramètres IP.
- De l'interface utilisateur de lame de superviseur, naviguez vers le matériel, et cliquez sur le lien de nombre d'emplacement de la lame MCU MSE 8510. Puis, cliquez sur l'onglet du port A.
- Vérifiez le port MCU une configuration IP, et le confirmez qu'aucun autre hôte sur le réseau n'est assigné la même adresse IP. Les adresses IP en double sont étonnant un problème courant. S'il y a lieu, consultez l'administrateur réseau afin de vérifier ces configurations.
- Vérifiez le port par section d'état d'Ethernets. Si l'état de lien n'est pas en hausse, vérifiez que le câble de réseau est connecté au commutateur. Il pourrait y a un problème avec le câble ou le port de commutateur.
- Si le MCU est maintenant accessible sur le réseau, répétez la première étape de cette procédure. Si les configurations d'IP address sont correctes et l'état de lien d'Ethernets est en hausse, mais la lame ne peut toujours pas être entré en contact n'importe où en fonction du réseau, mettez en référence le contrôle la lame de gamme 8510 MCU MSE par la section de superviseur de ce document.
Vérifiez la lame de gamme 8510 MCU MSE par le superviseur
Terminez-vous ces étapes afin de vérifier l'état de lame et de conférence MCU, des santés et des états sur la disponibilité, la version de logiciel, la température, et la tension :
- Cliquez sur le matériel, et cliquez sur le nombre d'emplacement de la lame qui a la question. La page récapitulative fournit des informations au sujet de :
- L'état de lame, avec l'adresse IP, la disponibilité, le numéro de série, et la version de logiciel
- Les santés de lame, avec la batterie des températures, de tension, et d'horloge temps réel (RTC)
- L'état signalé pour des conférences actives, nombre de participants, audio/ports vidéos en service, et coulant des visualiseurs
Cette image affiche la section de santés de lame :
- Si aucun état de tension (en cours ou plus mauvais) ne semble CORRECT, alors assurez-vous qu'assez de redresseurs sont installés dans les modules d'alimentation qui actionnent le châssis. En outre, contrôle que la source d'alimentation répond aux besoins actuels du châssis, comme détaillé dans l'alimentation et les besoins actuels calculateurs pour un article MSE 8000 Cisco.
- Si la disposition de bloc d'alimentation n'affiche pas CORRECT, entrez en contact avec le support technique de Cisco.
- Si l'un des d'autres états actuels dans la section de santés de lame n'affichent pas comme CORRECT, entrez en contact avec le support technique de Cisco.
- Si tous les états actuels affichent CORRECT, mais un ou plusieurs du plus mauvais état vu n'affiche pas CORRECT, obtenez le journal d'événements et alarmez les logs du superviseur, et entrez en contact avec le support technique de Cisco.
- Vérifiez la disponibilité. Si la disponibilité est inopinément courte (moins de 30 minutes), et il n'y a aucune raison connue (si elle alimentation-n'était pas faite un cycle ou la lame n'a pas réinséré, par exemple), alors la lame pourrait avoir récemment redémarré. La cause de la réinitialisation pourrait être une erreur de logiciel ou un problème matériel. Ceci dépend de si c'est une réinitialisation une fois, ou cyclique.
Terminez-vous ces étapes afin de déterminer ceci :
- Attente 30 minutes.
- Régénérez la page.
- Vérifiez la disponibilité de nouveau.
Si vous pouvez déterminer à partir de la disponibilité régénérée que la lame a ultérieurement redémarré de nouveau, mettez en référence la section de crash de ce document. - Attente 30 minutes.
- Si la lame ne la redémarre pas après que vous vérifiiez la page d'état, et semble fonctionnelle à chaque autre égard (par la vérification des paramètres réseau et des permis de port), alors il est possible que la lame ne pourrait avoir amorcé sans aucune de ses ressources en processeur de signaux numériques (DSP) disponibles.
Terminez-vous ces étapes afin de vérifier ceci :
- Vérifiez la section signalée d'état à la page récapitulative de lame de l'interface utilisateur de superviseur :
- La lame affiche le nombre total de ressources vidéo qu'il a avec succès amorcées et a autorisées. Ceci doit être égal au nombre de permis de port qui sont assignés à la lame, jusqu'à un maximum de 20 quand la lame est en mode de la haute définition (HD) /HD+, ou de 80 quand la lame est en mode de la définition standard (écart-type). Si ce ne sont pas égaux, alors entrez en contact avec le support technique de Cisco avec le comportement documenté, les versions, et le log diagnostique.
- Vérifiez la section signalée d'état à la page récapitulative de lame de l'interface utilisateur de superviseur :
Contrôles physiques sur la lame
Cette section décrit les étapes qui sont utilisées afin d'exécuter les contrôles physiques sur la lame, basée sur la traduction d'éclairage LED et le mouvement de la lame à un emplacement différent.
Si vous ne pouvez pas déterminer que la lame a un problème de matériel après que vous vous terminiez les étapes décrites dans les sections précédentes, vérifiez physiquement le châssis de gamme 8000 MSE. Terminez-vous ces étapes afin d'exécuter le contrôle physique :
- Assurez-vous que l'heure suffisante indiquée pour que la lame démarre après que vous mettiez sous tension au commencement le châssis (ou installez la lame dans un châssis qui est est déjà actionné). Ceci prend approximativement 20 minutes.
- Observez et notez la couleur des éclairages LED qui sont illuminés sur l'avant de la lame. Les importants éclairages LED sont :
- Alimentation (bleue) - Cette lumière se trouve juste au-dessus de l'onglet en plastique inférieur, et est illuminée dès que l'alimentation sera appliquée à la lame.
- État (vert) - Cette lumière est illuminée quand la lame est avec succès amorcée.
- Alarme (rouge) - Cette lumière lluminated quand la lame amorce ou est dans un état où elle ne peut pas démarrer.
- Le lien du port Ethernet A (vert trois) - la lumière indique l'activité, le duplex, et la vitesse. En date de la version 4.4, les 8510 seulement connexions de supports mettent en communication en fonction A ; Les ports B, le C, et le D ne sont pas pris en charge.
- Alimentation (bleue) - Cette lumière se trouve juste au-dessus de l'onglet en plastique inférieur, et est illuminée dès que l'alimentation sera appliquée à la lame.
- Terminez-vous ces étapes si vous rencontrez des problèmes quand vous observez les éclairages LED :
- Si aucune des lumières n'est illuminée, vérifiez que le reste du châssis a l'alimentation à lui, et que la lame est correctement insérée dans l'emplacement.
- Si les lumières n'illuminent toujours pas, déplacez la lame à un emplacement différent dans le châssis. De préférence, échangez-le avec un emplacement qui a une lame fonctionnante connue.
- Si la lame toujours ne met pas sous tension, entrez en contact avec le support technique de Cisco.
- Si le voyant d'alimentation bleu est illuminé, et aucune des autres lumières n'est, entrez en contact avec le support technique de Cisco. Si les restes rouges de témoin d'alarme illuminés pendant plus long que 30 minutes, mettent en référence la section de crash de ce document.
- Si le voyant d'alimentation bleu et le voyant d'état vert sont illuminés, mais la lumière verte du port A n'est pas, un RMA n'est pas nécessaire. Ceci indique un problème avec la connexion au port de commutateur. Utilisez un nouveaux câble/port de commutateur/commutateur, et vérifiez la configuration du port Ethernet A de lame de l'onglet de matériel de supervision. On le recommande fortement que les deux côtés du lien soient placés pour la négociation automatique.
- Si aucune des lumières n'est illuminée, vérifiez que le reste du châssis a l'alimentation à lui, et que la lame est correctement insérée dans l'emplacement.
Portée MCU sur l'interface web
La TelePresence Cisco MCU peut être accédée à par l'intermédiaire d'une session de console par le câble de console qui est fourni avec l'unité. Si le système n'est pas accessible par l'intermédiaire de l'interface web, et ne répond pas aux requêtes pings, vous pouvez ouvrir une session de console à l'unité afin de la dépanner avec des contrôles des services, de la configuration des ports, et de l'état activés.
Terminez-vous ces étapes afin d'atteindre le MCU si le système n'est pas ping-capable, ou vous ne pouvez pas naviguer vers l'interface web du système après qu'il soit assigné une adresse IP :
- Vérifiez qu'aucun témoin d'alarme rouge n'est illuminé sur l'avant de l'unité. Si l'unité est mise sous tension pendant plus de 20 minutes, et les restes rouges de témoin d'alarme sont illuminés, référez-vous à la section de crash de ce document.
- Si le voyant d'état vert est illuminé sur le périphérique, connectez votre PC au port de console par le câble fourni de console qui est arrivé avec l'unité.
- Afin de vérifier que la session de travail connectée est connectée réellement, appuyez sur la touche Enter plusieurs fois et la demande apparaît. La demande qui affiche des expositions votre périphérique (IPGW : >, ISDNGW : >, ou MCU : >, par exemple) :
- Afin de vérifier que des services du HTTP et/ou HTTPS sont activés, sélectionnez la commande show de service :
- Afin de vérifier l'état de lien sur le périphérique, sélectionnez la commande d'état :
- Si aucun lien n'apparaît sur le port A, tentez de connecter votre câble Ethernet pour mettre en communication B afin de voir si les changements d'état de lien :
- Si le port B peut détecter le lien mais mettre en communication A n'est pas, alors terminez-vous ces étapes afin de vérifier la configuration IP mettent en communication en fonction A de nouveau :
- Si le port A semble n'avoir aucune question, alors tentez une procédure de reset_config afin d'apporter l'unité de nouveau aux paramétrages d'usine.
- Une fois que le procédé de réinitialisation aux paramètres d'usine est complet, modifiez une adresse IP statique sur le port.
- Si vous éprouvez toujours des questions, redémarrez le système de la console, et collectez la sortie du démarrage dans un fichier texte par le client terminal qui est utilisé :
Les lames de gamme 8510 MCU MSE et des lames de la gamme 8710 MCU MSE affichent les deux interfaces d'Ethernets comme vfx0 et vfx1. les systèmes Étagère-montables (gamme 4500 et gamme 4200 MCU, gamme 3500 IPGW, et gamme 3241 RNIS gw) affichent leurs interfaces d'Ethernets comme bge0 et bge1.
- Si le port A semble n'avoir aucune question, alors tentez une procédure de reset_config afin d'apporter l'unité de nouveau aux paramétrages d'usine.
- Sur des lames de gammes 8510 et 8710 MCU MSE, vérifiez que les adresses MAC sont assignées, et qu'il n'y a aucun problème avec vfx0 et ou vfx1.
- Sur les unités étagère-montables, vous pourriez voir la sortie illustrée dans la prochaine image, avec bge0, qui est indicatif d'une panne du network interface card (NIC) sur le périphérique. Ceci prouve que la couche physique n'est pas détectée. Si ceci est vu, entrez en contact avec le support technique de Cisco.
- Si aucun lien n'apparaît après que vous permutiez le port, vérifiez la connexion réseau. Dans le meilleur des cas, la sortie devrait apparaître comme illustrée dans la prochaine image, avec toutes les informations IP affichées. Ceci indique que les paramètres IP sur l'unité sont configurés correctement.
- Changez l'adresse IP sur l'unité afin de découvrir une question avec réglé des adresses IP sur le réseau.
- Déplacez le câble Ethernet à un port de commutateur distinct afin d'éliminer toutes les questions de port de commutateur.
- Si une question de port de commutateur est éliminée, connectez un ordinateur portable directement à l'unité par un câble croisé, et configurez l'ordinateur portable avec le mêmes masque de sous-réseau, passerelle par défaut, et adresse IP qui est contenue dans ce sous-réseau.
- Une fois que l'adresse IP est configurée sur l'ordinateur portable, envoyez un ping de l'ordinateur portable à l'unité. Tentative d'atteindre l'interface web de l'unité de l'ordinateur portable. En outre, tentative d'envoyer un ping de la session de console d'unité à l'adresse IP d'ordinateur portable par l'intermédiaire de la commande ping. S'il y a d'accès de Connectivité et de Web, il indique une question de connexion réseau. Sinon, alors il est possible qu'une broche de port Ethernet soit endommagée, et vous devriez entrer en contact avec le support technique de Cisco.
Crash
Un crash sur un produit de la TelePresence Cisco MCU peut sont provoqué par par un manque de démarrer complètement, un cycle continu de réinitialisation, ou un incident qui se produit avec une conférence continue.
Si le témoin d'alarme rouge sur les restes d'unité illuminés pendant plus de 20 minutes, vous ne peut pas naviguer vers l'interface web d'unité, ou vous ne pouvez pas faire des appels vidéos, alors il est probable que l'unité n'ait pas démarré entièrement ou qu'elle est coincée dans un cycle de réinitialisation. Si c'est le cas, terminez-vous ces étapes afin de dépanner la question :
- Débranchez le pôle d'alimentation d'unité. Si c'est une lame, retirez-la du châssis.
- Attendez cinq minutes, et mettez sous tension l'unité.
- Si l'unité ne démarre pas normalement, collectez un log de console, qui affiche l'unité qui tente de démarrer. C'est le meilleur outil de diagnostic pour cette situation. Mettez en référence se connecter au port de console sur un article de Cisco d'unité de Codian saisi par Cisco pour des informations sur la façon obtenir un log de console.
- Mettez hors tension l'unité, et puis mettez sous tension l'unité.
- Attendez jusqu'à ce qu'ou la sortie arrête complètement, ou l'unité a redémarré trois ou quatre fois. Entrez en contact avec le support technique de Cisco, et fournissez le log de console.
Dépannez le module de ventilation de gamme 8000 MSE, actionnez les redresseurs, et actionnez le module
Tous le module de ventilation, les redresseurs d'alimentation, et d'alimentation les modules sont surveillés par la lame de gamme 8050 du superviseur MSE. Vous pouvez dépanner n'importe quelle panne ou sortir connexe à ces derniers par l'interface web de superviseur. Cette section décrit les étapes utilisées afin de dépanner un thermoventilateur, actionner le module, ou actionner la panne de redresseur par la vérification des logs et de l'état.
Voici une image qui affiche le plein châssis de gamme 8000 MSE :
Note dans l'image précédente :
- Le stimulant et les modules de ventilation inférieurs
- Les lames insérées
- Le plan rapproché d'une lame individuelle
- Les montages sur bâti
Dépannez une panne de ventilation de gamme 8000 MSE
Employez cette section afin de dépanner des pannes de ventilation sur un châssis de gamme 8000 MSE par des vérifications de l'état d'alarme et l'événement ouvre une session la lame de gamme 8050 du superviseur MSE.
Voici un extrait d'un journal d'événements qui affiche des questions avec le module 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
Quand vous voyez des erreurs de ce type, terminez-vous ces étapes afin de recueillir les logs requis :
- Afin de télécharger le fichier texte de logs d'alarme, naviguez vers les alarmes > le log > le téléchargement d'alarmes comme texte. Observez que la date la plus récente cette ceci a été enregistré.
- Dans le téléchargement de commande le fichier texte de journal d'événements, naviguent vers les logs > le journal d'événements > le téléchargement comme texte.
- Naviguez vers des alarmes > l'état d'alarmes, et prenez une copie d'écran de la page d'état d'alarme.
- Retirez le module de ventilation supérieur, et le vérifiez que tous les thermoventilateurs fonctionnent correctement.
- Retirez le module de ventilation inférieur, et le vérifiez que tous les thermoventilateurs fonctionnent correctement.
- Afin d'effacer les alarmes historiques du superviseur, naviguez vers des alarmes > l'état d'alarmes > les alarmes historiques claires.
- Afin d'effacer les alarmes connectez-vous, naviguez vers les alarmes > le log > le clear log d'alarmes.
- Surveillez, et voyez si les alarmes retournent.
- Si la question retourne, permutez le magasin supérieur avec le magasin inférieur, et déterminez si la question suit le module de ventilation. Si la question renvoie et suit le module de ventilation, entrez en contact avec le support technique de Cisco avec les logs que vous avez collectés.
Questions de module d'alimentation
Dans le châssis de gamme 8000 MSE, il y a deux entrées d'alimentation CC d'indépendant que vous pouvez ou connecter directement à deux approvisionnements d'alimentation CC, ou à deux modules de Valere qui convertissent le courant alternatif en C.C. Le châssis de gamme 8000 MSE peut être actionné avec un ou deux modules d'alimentation - A et B. Ces alimentation de flux indépendamment à chaque module de ventilation et lame. L'unité peut être à la force pleine de l'approvisionnement A ou fournir le B. au cas où l'un ou l'autre des blocs d'alimentation échouerait, l'unité continue à fonctionner, parce qu'elle tire l'alimentation de l'autre approvisionnement.
Cisco recommande que, pour la pleine Redondance et la fiabilité maximum, les flux d'alimentation doivent être connectés aux sources d'alimentation indépendantes. Chacun doit avoir la capacité de fournir le plein chargement électrique de l'unité et de chaque module qui contient le même nombre de redresseurs.
Cette image affiche le module d'alimentation CC de gamme 8000 MSE :
Voici deux questions communes de module d'alimentation que vous pourriez rencontrer :
- Contact perdu avec le module d'alimentation - Quand vous naviguez vers le matériel > les blocs d'alimentation, fournissez un contact perdu par expositions avec le module d'alimentation. Ceci signifie que la gamme 8050 du superviseur MSE ne peut pas communiquer avec le module d'alimentation.
- approvisionnement 10/External hors de la plage RÉGLÉE - Ceci signifie que les tensions d'entrée au châssis sont hors de spécification. Vérifiez que l'alimentation et le courant corrects est fournie au châssis par l'intermédiaire de l'alimentation et des besoins actuels calculateurs pour un outil en ligne MSE 8000.
S'il n'y a aucune anomalie produite quand vous exécutez l'alimentation et la vérification de courant précédemment mentionnées, récupérez ce support technique de Cisco de l'information et de contact :
- Configuration de superviseur de gamme 8050 MSE
- Journal d'audit
- Log d'alarme
- Journal d'événements
- Tir d'écran de page d'état d'alarme
- Numérotez et modèle des lames dans le châssis
- Statut des blocs d'alimentation
Configurez la surveillance d'état de l'alimentation
Cisco recommande que vous fassiez configurer la surveillance d'état de l'alimentation afin de fournir le feedback fiable à l'administrateur visuel quant à toutes les erreurs, à avertissements, ou à d'autres informations importantes vues dans les logs.
Afin d'activer la surveillance des tensions de bloc d'alimentation, aussi bien que les modules de l'alimentation Courant-à-C.C (s'il y a lieu), terminez-vous les étapes à la page 61 de l'aide en ligne du superviseur 2.3 de TelePresence Cisco (format imprimable). Effacez les logs après que la configuration d'état de l'alimentation soit complète.
Vérifiez le câble de surveillance de module d'alimentation qui se prolonge de derrière du module d'alimentation jusqu'au châssis. C'est un câble spécial qui est utilisé pour la surveillance de module d'alimentation. Faites attention quand vous vérifiez le câble, car il peut être facilement confondu avec un câble de console du militaire de carrière DB9-RJ45. Le câble de surveillance de module d'alimentation est étiqueté avec un autocollant qui indique l'arrière de module d'alimentation :
Il y a deux paires de connecteurs situés au dos du châssis de gamme 8000 MSE : la paire du côté gauche est étiquetée l'emplacement 10, et la paire du côté droit est étiquetée l'emplacement 1. Assurez-vous que les câbles de surveillance sont connectés pour rainer 1, qui sont les connecteurs qui représentent l'emplacement de superviseur de gamme 8050 MSE.
Si vous rencontrez n'importe quelles questions avec la configuration de surveillance de module d'alimentation, terminez-vous ces étapes :
- Permutez le câble de surveillance de module d'alimentation du module A au module B afin de déterminer si la question suit le câble. Si le problème suit le câble, entrez en contact avec le support technique de Cisco.
- Permutez les cartes NIC autour du module A d'alimentation et actionnez le module B afin de déterminer si les cartes NIC sont la cause de la question. Si les alarmes retournent, et la question suit la carte NIC, entrez en contact avec le support technique de Cisco.
Cette image affiche la carte NIC de module d'alimentation :
Dépannez les redresseurs d'alimentation
Dans certains cas, vous pourriez rencontrer des questions avec un des redresseurs d'alimentation. Cette section décrit comment dépanner ces questions.
Voici une vue avant du module d'alimentation avec des redresseurs :
Voici la vue arrière du module d'alimentation :
Terminez-vous ces étapes afin de résoudre un problème avec des redresseurs d'alimentation :
- Si une erreur apparaît sur le redresseur, réinsérez-le et attendez de voir si l'erreur apparaît toujours (les redresseurs sont chaud-enfichables).
- Si l'erreur apparaît toujours après quelques minutes, posez le redresseur dans un emplacement différent du module A ou B d'alimentation afin de déterminer si la question est avec le redresseur ou l'emplacement de module d'alimentation.
- Si vous éprouvez toujours des questions, entrez en contact avec le support technique de Cisco et fournissez ces informations :
- Image du redresseur dans l'état d'alarme
- Numéro de série du redresseur (situé sur l'un ou l'autre le gauche du côté droit du redresseur)
- Tir d'écran de la page de blocs d'alimentation (matériel > blocs d'alimentation)
- Tir d'écran de la page de santés (état > santés)
- Journal d'audit
- Log d'alarme
- Journal d'événements
Dépannez les questions de la TelePresence Cisco le RNIS gw
La TelePresence Cisco le RNIS GWs fournissent à l'intégration parfaite entre les réseaux IP et RNIS la transparence complète de caractéristique par l'intermédiaire du RNIS. Cette section décrit comment dépanner des interfaces et des mémoires tampons de PRI RNIS sur des DSP.
Couche 1 PRI et couche 2 vers le bas
Employez cette section afin de dépanner des questions d'interface PRI sur le RNIS gw. Le port PRI peut être vérifié avec le connecteur 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 pour le port PRI sur le RNIS gw. Connectez Pin1 à Pin4, et Pin2 à Pin5 afin de créer le câble de bouclage.
Branchez le câble de bouclage au port 1, et vérifiez l'état L1. Si l'état L1 sur le port 1 apparaît, il est probable que la question soit provoqué par par les câbles qui sont utilisés. Vous pouvez utiliser le câble de bouclage plus loin en bas de la ligne afin d'isoler le problème.
Si l'état L1 sur le port 1 apparaît vers le bas avec le câble de bouclage, activez le port 2 pour le PRI sur le RNIS gw. Port 2 de test avec le câble de bouclage aussi bien. Si le problème demeure avec un port spécifique, il est possible qu'il y ait une défaillance de port PRI. Contactez le support technique de Cisco.
Erreurs de ping-pong et délais d'attente DSP
Il y a deux mémoires tampons sur un DSP qui désigné sous le nom du ping et cocotent. Chaque mémoire tampon traite dix millisecondes de données (une trame RNIS) à la fois. L'intention est de traiter une mémoire tampon tandis que vous lisez le prochain. Si ces deux mémoires tampons tombent hors du sync les uns avec les autres, elles permutent afin d'essayer de revenir dans le sync.
Voici un exemple du journal d'événements de la TelePresence Cisco le RNIS gw, où les mémoires tampons tombent hors du sync 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 à considérer :
- Pourquoi tombent-ils hors du sync ?
- Est-il possible que des trames non valides, une horloge défectueuse RNIS, ou une cause peu fiable PRI la question ?
Voici une liste des informations à recueillir :
- Combien PRIs sont-ils connectés à ce gw ?
- Tout les PRIs du même commutateur ou sont-ils de différents Commutateurs ?
- Si tout les PRIs sont débranchés et le système est redémarré, les erreurs continuent-elles ? Collectez un log 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étition avec tout le PRIs, un par un.
Si PRIs de différents Commutateurs sont utilisés, les horloges PRI doivent être dans le sync (PRIs de la même compagnie de téléphone sont normalement). Il est possible que le PRI d'un commutateur ait une horloge qui est complètement hors de sync avec l'horloge du PRI sur l'autre commutateur. Si seulement un PRI est connecté et semble correct, alors connectez un PRI d'un commutateur et un PRI de l'autre, redémarrez le système, et voyez si les erreurs retournent. Enregistrez vos tests et comportement pour fournir au support technique de Cisco si nécessaire.
Informations connexes
CommentairesLaissez-nous vous aider
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)