Exemple de surveillance des demandes d'enregistrement

Dernière mise à jour : Mar 19, 2025 |
Informations sur le prologue
Métadonnées
Mots-clés :
Cet exemple montre comment vous utiliseriez la commande list trace ras ip-address x.x.x.x pour surveiller les demandes d'inscription d'un serveur central surviable et la réponse associée du serveur principal.
  1. Exécutez la commande display survivable-processor à partir du serveur principal et notez les adresses IP du serveur principal et des serveurs centraux survivables.
    INFORMATIONS SUPPLÉMENTAIRES :
    Illustration Dépannage - afficher un exemple de processeur survivable
  2. À partir du serveur principal survivable à surveiller, utilisez l'interface de gestion du système et l'écran Configuration du serveur pour afficher la page Configurer ESS et prenez note de l'adresse IP configurée comme adresse principale du serveur principal.
  3. À partir du serveur principal, entrez la commande list trace ras ip-address x.x.x.x pour l'adresse IP à monitorer.
    INFORMATIONS SUPPLÉMENTAIRES :
    Dans cet exemple, l'adresse IP du serveur central surviable (135.9.78.143) a été saisie.
    Le premier échange de messages provient du serveur central surviable qui envoie une demande d'inscription (RRQ) au serveur principal. Le serveur principal répond avec une confirmation d'inscription (RCF). Le serveur principal et le serveur surviable poursuivent une conversation au cours de laquelle le serveur surviable envoie un message de maintien en vie (KARRQ) et le serveur principal le confirme (RCF).
    Illustration Dépannage - exemple de commande ras de traçage de liste - serveur principal
  4. Mettez le serveur central survivable en marche et exécutez la commande Trace. Utilisez l'adresse IP obtenue à partir de la page Configurer ESS avec la commande list trace ras.
    INFORMATIONS SUPPLÉMENTAIRES :
    Le même échange de messages ESS/principal a lieu. De ce point de vue, le serveur central survivable envoie une demande d'inscription (qui apparaît sous forme de messages KARRQ au serveur principal) et le serveur principal répond par des messages de confirmation d'inscription (RCF).
    Illustration Dépannage - exemple de commande ras de traçage de liste - ESS
  5. Supposons que le serveur de base survivable n'est pas administré correctement sur le serveur principal.
    INFORMATIONS SUPPLÉMENTAIRES :
    Dans cet exemple, le serveur principal survivable est configuré pour avoir l'ID de serveur 98 à l'aide de la configuration réseau sur la page Configuration du serveur. Cependant, le serveur central survivable a également l'ID de serveur 97 administré sur le serveur principal à l'aide de la commande SAT change survivable-processor.
    À partir du serveur principal, les données présentées dans la figure suivante s'affichent à l'aide de la commande list trace ras.
    Illustration Dépannage - mauvaise administration - perspective du serveur principal
    Notez que sur le serveur principal, un événement de refus se produit lorsque le serveur de cœur surviable tente de s'enregistrer. Les événements de refus sont affichés à l'aide de la commande display events. En résumé, les événements de refus associés au serveur central surviable sont :
    • 3600 : IP RRJ-ESS et non admin : Le serveur de base surviable qui tente de s'inscrire ne correspond à aucun des serveurs de base surviables administrés dans les traductions.
    • 3601 : IP RRJ-ESS obj not init : Le bit de fonctionnalité FEAT_ESS n'est pas activé dans le fichier de licence.
    • 3602 : IP RRJ-ESS bad SID envoyé : Le serveur de cœur surviable a envoyé un SID qui ne correspond pas à celui du serveur principal. Le SID est défini par le fichier de licence.
      À l'aide de la commande list trace ras sur le serveur central survivable, le serveur affiche les données comme indiqué dans la figure suivante.
      Illustration Dépannage - mauvaise administration - perspective ESS
      Notez que le serveur central surviable envoie une demande d'inscription (RRQ) mais ne reçoit qu'un rejet d'inscription (RRJ) du serveur principal.