Voix et communications unifiées : Commutateur logiciel Cisco PGW 2200

Collecte de données HSI pour les demandes de service de support technique

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Quand vous ouvrez une demande de service avec le support technique de Cisco, quelques informations préliminaires sont exigées mieux pour identifier et qualifier la question. Certaines de ces informations sont toujours exigées ; d'autres conditions requises de l'information dépendent de la nature de la question. Si vous attendez de collecter ces informations jusqu'après que vous avez ouvert une demande de service et un ingénieur demande elle, alors il est inévitable qu'il y aura un retard dans la résolution.

Ainsi, l'objectif principal de ce document est d'identifier les informations préliminaires exigées, basées sur le type de question, de sorte qu'il puisse fournir à l'ingénieur immédiatement. L'objectif secondaire de ce document est de te fournir des directives générales pour suivre quand vous collectez des informations pour le support technique de Cisco, pour éviter le test et le souvenir répétitifs des données identiques.

Ce document est destiné pour des clients de Cisco cela des solutions de signalisation de Voix de support basées sur le système et le Cisco PGW 2200 d'interface de signalisation de Cisco H.323 (LA SIENNE) (autrefois appelés Sc 2200 et VSC 3000, ou contrôleur de téléphonie de Cisco, ou le contrôleur de passerelle de medias).

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

Composants utilisés

Les informations dans ce document sont basées sur H.323 l'interface de signalisation (version 2.x ou ultérieures) et le contrôleur de passerelle de medias PGW (version 9).

Conventions

Les commandes qui sont affichées dans ce document pourraient sembler préfixées par une de ces demandes, qui donnent une indication de l'environnement d'application dans lequel la commande doit être exécutée :

Demande Environnement
% Demande de csh-shell UNIX. C'est la demande par défaut de l'interface de ligne de commande (CLI) pour le compte du mgcusr UNIX après procédure de connexion.
#~# Demande niveau de la racine de shell UNIX. C'est la demande CLI de par défaut pour l'utilisateur de base. Émettez la commande du su UNIX d'y arriver.
mml> Demande homme-machine d'application du langage (MML). Émettez la commande de mml de la demande de csh-shell d'y arriver.

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

L'information requise standard

Pour toutes les questions liées son, ces informations standard devraient toujours être fournies immédiatement au support technique de Cisco :

  1. Description du problème
  2. Les informations générales
  3. SES informations système
  4. SA configuration en cours

Les informations de particularité de problème

Selon la nature du problème, les informations complémentaires pourraient être nécessaires. Ce document considère ces derniers des types de problème :

Questions liées à l'appel

Ces informations devraient être fournies, si le problème implique un appel par LE SIEN :

  1. L'information requise standard
  2. SON suivi de fureteur UNIX
  3. SON suivi d'application

Puisque LE SIEN dialogue étroitement avec le PGW, ces informations doivent être aussi bien collectées sur le PGW :

  1. Suivi du fouineur PGW Cisco (PTC-MT)
  2. Les informations système PGW
  3. Configuration en cours PGW
  4. Suivi d'appel PGW (MDL)

Si LE SIEN parle à un point final de logiciel de Cisco IOSÝ H.323, ces informations devraient être collectées :

  1. H.323 les informations système de point final
  2. H.323 le point final mettent au point la sortie de commande

Remarque: Les suivis demandés et met au point devraient être recueillis simultanément et pour un et la même chose appelez ! Ceci simplifie la corrélation des événements entre différents composants. Le manque de faire ainsi pourrait résulter en nouvelle, en double demande de renseignements de l'ingénieur de Soutien technique et mènera inévitablement à un retard dans la résolution.

SON vidage de mémoire d'application

Ces informations doivent être fournies, si la SON application a souffert un vidage de mémoire :

  1. L'information requise standard
  2. SON fichier image mémoire
  3. sortie de commande de pstack et de pmap

Préparation des connexions de fichier

Quand vous disposez des fichiers pour être soumis à une demande de service ou à un ingénieur de Soutien technique, vous devriez essayer de compresser (et paquet) les fichiers à l'avance.

Pour simplifier cette tâche, créez un sous-répertoire provisoire dans lequel pour copier les fichiers appropriés. Par exemple, émettez la commande de /var/tmp/ciscotac de mkdir de faire un sous-répertoire provisoire appelé le ciscotac. Puis, employez une de ces méthodes pour compresser les fichiers :

  • Tous les fichiers compressés ensemble :

    % cd /var/tmp/ciscotac
    
    % tar cf - . | compress > ../files4tac.tar.Z
    
    !--- This method creates one archive file in the parent directory
    !--- (so that tar fdoes not archive its own archive) that contains
    !--- all of the files from /var/tmp/ciscotac.
    !--- If you have gzip installed, you may replace compress with gzip.
    
    
  • Chaque fichier compressé individuellement :

    % cd /var/tmp/ciscotac
    
    % compress *
    
    !--- If you issue compress (or gzip) by itself, it compresses and
    !--- replace each file individually, instead of creating a single
    !--- archive file. This is useful if the previous method would result
    !--- in an archive file that is too large to upload.
    !--- For core dump files, always use this method.
    
    

Une fois que le fichier d'archivage ou les fichiers ont été fournis à l'ingénieur de Soutien technique, enlevez eux (et le répertoire provisoire) de votre système de fichiers.

Détails de l'information

Cette section fournit des particularités et des procédures détaillées au sujet des informations à recueillir.

Description du problème

Fournissez les détails pas à pas de cela les actions que l'utilisateur exécute quand la question se produit. Les informations détaillées devraient également inclure ces éléments :

  • Comportement prévu

  • Comportement observé détaillé

  • Si le problème implique un appel :

    • Appeler et numéro appelé, et tous autres nombres qui pourraient être impliqués dans le scénario d'appel

    • Direction d'appel (identifiez l'appel d'origine et de terminaison signalant des protocoles. Exemple : SS7 à H.323.)

  • Contenu copié et collé de tous messages d'erreur vus

  • La question est-elle reproductible ?

  • Quelle est la fréquence du problème ?

  • Le comportement change-il basé sur la direction, la version logicielle, les composants utilisés, ou toute autre chose d'appel ? En d'autres termes, est-elle la même fonctionnalité connue pour fonctionner correctement quand vous utilisez un ensemble différent de variables ?

Informations générales

Fournissez ces informations générales :

  • Matériel de produit et identification de version logicielle de tous les composants impliqués.

  • Topologie. Ceci peut être graphique ou écrit et devrait au moins inclure tous les composants impliqués dans le chemin d'appel et leurs adresses IP.

  • État de déploiement de réseau :

    • Est-ce que c'est une nouvelle installation ?

    • Est-ce que c'est un environnement de laboratoire (test) ?

    • Est-ce que c'est un réseau de production ? Si ainsi :

      • Quand la première occurrence avait-elle lieu du problème ?

      • Quels changements récents fait aux composants ont comportés ?

SES informations système

Collectez la sortie de ces commandes MML :

mml> rtrv-ne

mml> rtrv-ne-health

Émettez cette commande UNIX de voir le SON niveau de correctif :

% ls /opt/GoldWing/currentPM/bin/*main*

SA configuration en cours

Ce fichier texte contient le SIEN configuration en cours :

/opt/GoldWing/currentPM/var/prov/active_config/session.dat

Alternativement, vous pouvez émettre la commande du rtrv-config MML de capturer la configuration en cours.

SON suivi de fureteur UNIX

Le fureteur est un outil d'analyseur de paquets qui est livré la norme empaquetée avec Solaris.

Comme racine, émettez cette commande avant que vous fassiez un appel d'essai :

snoop -d interface -o fail.snoop

!--- interface is the relevant interface name and fail.snoop is
!--- the file name of the trace file that you want to write.

Maintenant, faites l'appel d'essai. Vous devriez voir le compte de paquet monter. Presse Ctrl+C après que vous finissiez l'appel.

Soumettez le fichier fail.snoop à la demande de service ou à l'ingénieur de Soutien technique (voir les connexions de PreparingFile).

Conseil : Émettez /sbin/ifconfig - une commande si vous êtes incertain au sujet du nom d'interface.

SON suivi d'application

Suivez cette procédure pour capturer un suivi d'application à un fichier.

  1. Enable se connectant par l'intermédiaire de MML :

    mml> set-log:eisup:level=0xffff
    
    mml> set-log:callcontrol:level=0xffff
    
    mml> set-log:h323:level=0xffff
    
    mml> radlog::start
    
    mml> quit
    
  2. Videz le fichier de platform.log avant le test :

    % cd /opt/GoldWing/currentPM/var/log
    
    % log_erase
    
    !--- This command purges the platform.log file. Source the
    !--- /opt/GoldWing/currentPM/local/setup.gw.csh file, if this
    !--- command is not recognized.
    
    
  3. Faites l'appel d'essai.

  4. Une fois terminé, sauvegardez une copie du fichier de platform.log et désactivez se connecter :

    % cp platform.log fail.log
    
    mml> set-log:all:level=0x0000
    
    mml> radlog::stop
    
    mml> quit
    
  5. Soumettez le fichier de fail.log à la demande de service ou à l'ingénieur de Soutien technique (voyez préparer des connexions de fichier).

Suivi du fouineur PGW Cisco (PTC-MT)

Le fouineur de Cisco est un outil interne d'analyseur de paquets de Cisco. PTC-MT est la version commercialisée du fouineur.

Pour obtenir un suivi dans le format ASCII, émettez ces commandes sur le PGW :

# cd snooper_directory


# ./snooper int interface_x ss7 nosnts mgcp noauep eisup detail hex >
  fail_interface_x.snooper &

!--- This command must be issued on one line.
!--- Issue this command for every redundant interface (interface_x)
!--- in the PGW. fail_interface_x.snooper is the file name of the
!--- ASCII trace file that you want to write.

Alternativement, pour obtenir le suivi dans le format binaire, émettez ces commandes :

# cd snooper_directory


# ./snooper int interface_x file fail_interface_x.snooper & 

!--- Issue this command for every redundant interface (interface_x)
!--- in the PGW. fail_interface_x.snooper is the file name of the
!--- binary trace file that you want to write.

Une fois que vous avez capturé l'appel d'essai, n'oubliez pas de détruire les processus de fouineur.

Soumettez le fichier ou les fichiers fail_interface_x.snooper à la demande de service ou à l'ingénieur de Soutien technique (voir les connexions de PreparingFile).

Notes :

  • Assurez-vous que le fichier de seedfile.txt est correctement configuré !

  • Si vous avez choisi de collecter un suivi binaire, n'oubliez pas d'expédier le fichier de seedfile.txt aussi bien.

  • Si vous utilisez PTC-MT au lieu du fouineur, remplacez le fouineur dans les commandes précédentes par le ptcmt et remplacez les nosnts par le nomtm.

  • Si vous ne faites pas installer le fouineur ou le PTC-MT, utilisez l'outil de fureteur UNIX à la place.

Les informations système de Cisco PGW

Collectez la sortie de ces commandes MML :

mml> rtrv-ne

mml> rtrv-ne-health

Cette commande shell UNIX affiche les correctifs installés MGC :

% pkginfo -i | grep CSC

Configuration en cours PGW

Cette commande MML exporte la configuration en cours du PGW :

mml> prov-exp:all:dirname="directory-name"

Tous les fichiers qui résultent de cette commande sont enregistrés dans le répertoire de nom du répertoire de /opt/CiscoMGC/etc/cust_specific/.

Soumettez les fichiers à la demande de service ou à l'ingénieur de Soutien technique (voyez préparer des connexions de fichier).

Suivi d'appel PGW (MDL)

Le suivi d'appel de MDL devrait être exécuté aussi brièvement comme possible. Ceci maintient l'incidence possible sur la performance du système aussi basse comme possible ; et il limite également le nombre d'appels dans le suivi, autant que possible, à l'appel approprié seulement. Les plusieurs appels dans le suivi n'est pas desirable, car il le fait plus compliqué pour localiser l'appel approprié.

  1. Commencez le suivi d'appel :

    mml> sta-sc-trc:sig-path:confirm
    
    !--- sig-path is the call’s incoming signaling path.
    
    

    Remarque: Émettez le rtrv-DEST : toute la commande de déterminer le Sig-chemin.

  2. Faites l'appel d'essai.

  3. Arrêtez le suivi d'appel :

    mml> stp-sc-trc:all
    
    !--- Note the BTR file name that is displayed at this point.
    
    mml> quit
    
  4. Commencez le script de get_trc.sh :

    % cd /opt/CiscoMGC/var/trace
    
    % get_trc.sh filename.btr
    
    !--- filename.btr is the file name that was displayed when you
    !--- stopped the trace.
    
    
  5. Si les plusieurs appels sont présents dans le suivi, naviguez d'abord vers l'ID d'appel approprié en émettant le N, le P, ou les commandes d'id.

  6. Émettez la commande de C d'écrire un suivi de cet appel, dans le format ASCII, à un fichier TRC.

  7. Soumettez le fichier TRC à la demande de service ou à l'ingénieur de Soutien technique (voyez préparer des connexions de fichier).

Pour plus de détails au sujet de cette procédure, référez-vous à la partie traçage de la documentation PGW.

H.323 les informations système de point final

Du mode enable, collectez la sortie de ces commandes :

show version

show running-config

Si le périphérique est IOS de non-Cisco, essayez d'obtenir les informations semblables.

H.323 le point final mettent au point la sortie de commande

Si la charge du système le permet, collectez la sortie de la prochaine liste de commandes de débogage pour un appel défectueux.

Remarque: Avant que vous émettiez ces commandes de débogage, assurez-vous que vous faites activer les horodatages en millisecondes et la sequence-numbers dans la configuration :

service timestamps debug datetime msec

service timestamps log datetime msec

service sequence-numbers
debug cch323 session

debug cch323 h225

debug cch323 h245

debug h225 asn1

debug h225 asn1 errors

debug h225 events

debug h225 q931

debug h245 asn1

debug h245 asn1 errors

debug h245 events

Si le périphérique est IOS de non-Cisco, essayez d'obtenir semblable mettent au point les informations.

SON fichier image mémoire

Si la SON application tombe en panne, un vidage de mémoire est écrit à un fichier avec ce format de nom du fichier :

/opt/GoldWing/currentPM/bin/core_timestamp

!--- timestamp is in the form YYYYMMDDhhmmss.

Le fichier image mémoire ou les fichiers doit être compressé séparément avant que vous les soumettiez à la demande de service ou à l'ingénieur de Soutien technique (voyez préparer des connexions de fichier).

sortie de commande de pstack et de pmap

Émettez ces commandes UNIX pour le SON fichier image mémoire :

# cd /opt/GoldWing/currentPM/bin

# ls -l core_*

# pstack core_file > core_file.proc

# pmap core_file >> core_file.proc

!--- core_file is the core dump file name that you retrieved
!--- with the ls -l core_* command.

Soumettez le fichier core_file.proc à la demande de service ou à l'ingénieur de Soutien technique (voir les connexions de PreparingFile).

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 50921