Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuration des opérations distantes SNMP

Présentation des opérations à distance SNMP

Une opération à distance SNMP est un processus sur le routeur qui peut être contrôlé à distance à l’aide de SNMP. Junos OS actuellement deux opérations distantes SNMP: le ping MIB traceroute MIB, définis dans le RFC 2925. En utilisant ces MBIT, un client SNMP dans le système de gestion réseau (NMS) peut:

  • Lancez une série d’opérations sur un routeur

  • Recevoir des notifications une fois les opérations terminées

  • Recueillir les résultats de chaque opération

Junos OS fournit également des fonctionnalités étendues à ces MBIT dans les extensions spécifiques Juniper Networks’entreprise jnxPingMIB et jnxTraceRouteMIB . Pour en savoir plus jnxPingMIB sur les jnxTraceRouteMIB pings et MIBtraceroute MIB.

Ce sujet aborde les sections suivantes:

Conditions d’exploitation à distance SNMP

Pour utiliser les opérations à distance SNMP, vous devez connaître les conventions SNMP. Vous devez également configurer les Junos OS pour permettre l’utilisation des M MIB d’opérations à distance.

Avant de démarrer le ping MIB, consultez Démarrer un test de ping.

Avant de démarrer la MIB Traceroute, consultez le site Starting a Traceroute Test.

Définition des vues SNMP

Toutes les MB d’opérations à distance Junos OS que les clients SNMP ont des droits de lecture-écriture. La configuration SNMP par défaut de Junos OS ne fournit pas aux clients une chaîne de communauté 7 privilèges de ce type.

Pour définir des privilèges d’écriture de lecture pour une chaîne de communautés SNMP, inclure les instructions suivantes au niveau [edit snmp] de la hiérarchie:

Exemple: Définition des vues SNMP

Pour créer une communauté nommée qui permet aux clients SNMP d’accéder en lecture et écriture aux MIB, MIB, Traceroute MIB et MIB, incluent les remote-community instructions suivantes au niveau de la jnxPingjnxTraceRoute[edit snmp] hiérarchie:

Pour plus d’informations sur cet énoncé, consultez la liste communityConfiguring SNMP Communities and Community (SNMP).

Pour plus d’informations sur l’énoncé, consultez viewconfiguring MIB Views, view (Communauté SNMP)et afficher (Configuring a MIB View).

Notification du piège de définition pour les opérations à distance

Outre la configuration des MIB à distance pour la notification de piège, vous devez également configurer Junos OS. Vous devez spécifier un hôte cible pour les traps d’opérations distantes.

Pour configurer la trap notification pour les opérations distantes SNMP, inclure les déclarations et les énoncés au niveau categoriestargets de la [edit snmp trap-group group-name] hiérarchie:

Exemple: Notification du piège de définition pour les opérations à distance

Indiquez 172.17.12.213 comme hôte cible tous les traps d’opération distants:

Pour plus d’informations sur les groupes de traps, consultez configuring SNMP Trap Groups.

Utilisation d’index de chaînes de longueur variable

Tous les objets tabulaires des opérations distantes MIB pris en charge par Junos OS sont indexés par deux variables de SnmpAdminString type. Pour plus SnmpAdminString d’informations, consultez la RFC 2571.

Junos OS les types de variable d’octet ne sont pas SnmpAdminString différents. Cependant, les index sont définis comme une longueur variable. Lorsqu’une chaîne de longueur variable est utilisée comme index, la longueur de la chaîne doit être incluse dans l’identifiant d’objet (OID).

Exemple: Définir des index de chaîne à longueur variable

Pour référence la variable d’une ligne à l’endroit et à l’endroit, utilisez l’identifiant d’objet suivant pingCtlTargetAddresspingCtlTablepingCtlOwnerIndexbobpingCtlTestNametest (OID):

Pour plus d’informations sur la définition du ping MIB, consultez le RFC 2925.

Activation de la journalisation

Le code d’erreur SNMP renvoyé en réponse aux requêtes SNMP ne peut fournir qu’une description générique du problème. Les descriptions d’erreur consignées dans le processus d’opérations à distance peuvent souvent fournir des informations plus détaillées sur le problème et vous aider à le résoudre plus rapidement. Cette journalisation n’est pas activée par défaut. Pour activer la journalisation, inclure flag general l’instruction au niveau [edit snmp traceoptions] de la hiérarchie:

Si le processus d’opérations à distance reçoit une demande de SNMP qu’il ne peut accueillir, l’erreur est consignée dans le /var/log/rmopd fichier. Pour surveiller ce fichier journal, il est temps d’émettre la commande en mode opérationnel du monitor start rmopd interface de ligne de commande (CLI).

Utilisation du ping MIB pour les équipements de surveillance à distance s’exécutant Junos OS

Un test ping est utilisé pour déterminer si les paquets envoyés depuis l’hôte local atteignent l’hôte désigné et sont renvoyés. Si l’hôte désigné est atteint, le test ping fournit le temps d’aller-retour approximatif pour les paquets. Les résultats des tests Ping sont stockés dans pingResultsTable et pingProbeHistoryTable .

RFC 2925 fait référence à la description détaillée du ping MIB et fournit la définition du ping MIB MIB ASN.1.

Lancer un test ping

Utilisez ce sujet pour lancer un test ping ICMP. Il existe deux façons de démarrer un test ping: à l’aide de plusieurs unités de données de protocole set (PDU) ou à l’aide d’un PDU de ensemble unique.

Avant de commencer

Avant de commencer un test ping, configurez une vue d’MIB ping. Cela permet d’autoriser les requêtes SNMP Set sur pingMIB . Pour plus d’informations, consultez configuring MIB Views.

À partir Junos OS version 17.2X75-D100, vous devez configurer lapm avant de lancer un ping ICMP. Configurez lapm en utilisant la edit services rpm commande.

Lancer un test ping

Pour commencer un test de ping, créez une ligne pingCtlTable et pingCtlAdminStatus définissez sur enabled . Les informations minimales qui doivent être spécifiées avant de les pingCtlAdminStatus définir enabled sont les à:

  • pingCtlOwnerIndexSnmpAdminString

  • pingCtlTestNameSnmpAdminString

  • pingCtlTargetAddressInetAddress

  • pingCtlTargetAddressTypeInetAddressType

  • pingCtlRowStatusRowStatus

Pour toutes les autres valeurs, les valeurs par défaut sont choisies, sauf indication contraire. et sont utilisées comme index, de sorte que leurs valeurs sont spécifiées dans pingCtlOwnerIndex le cadre de pingCtlTestName l’identifiant d’objet (OID). Pour créer une ligne, définissez ou fixez une ligne qui pingCtlRowStatuscreateAndWaitcreateAndGo n’existe pas déjà. Une valeur de l’indique que toutes les informations nécessaires ont été fournies et que le test peut active commencer ; peut être définie sur pingCtlRowStatuspingCtlAdminStatusenabled . Une requête SNMP qui définit l’échec si les informations requises dans la ligne ne sont pas spécifiées ou SetpingCtlRowStatusactive incohérentes.

Pour plus d’informations sur la configuration d’une vue, consultez Setting SNMP Views.

Consultez les sections suivantes pour savoir comment commander les variables.

Utilisation de plusieurs PDUS

Vous pouvez utiliser plusieurs PUS de demande (plusieurs PDUS, avec une ou plusieurs varbinds chacun) et définir les variables suivantes dans l’ordre de démarrer Set le test:

  • pingCtlRowStatus à createAndWait

  • Toutes les variables de test appropriées

  • pingCtlRowStatus à active

    Junos OS vérifie maintenant que toutes les informations nécessaires à l’exécuter d’un test ont été spécifiées.

  • pingCtlAdminStatus à enabled

Utilisation d’un PDU unique

Vous pouvez utiliser un PDU de demande unique (un PDU, avec plusieurs varbinds) pour définir les variables suivantes pour Set commencer le test:

  • pingCtlRowStatus à createAndGo

  • Toutes les variables de test appropriées

  • pingCtlAdminStatus à enabled

Surveillance d’un test ping en cours d’exécution

Une fois l’ensemble de la requête définie, les données suivantes sont réalisées avant que l’accusé de réception de la demande de SNMP ne soit renvoyé pingCtlAdminStatusenabled au Set client:

  • pingResultsEntry est créé s’il n’existe pas déjà.

  • pingResultsOperStatus les transitions vers enabled .

Pour plus d’informations, consultez les sections suivantes:

pingResultsTable

Lorsque le test est en cours d’exécution, pingResultsEntry il permet de suivre l’état du test. La valeur est pingResultsOperStatus de l’exécution et de l’arrêt du enableddisabled test.

La valeur reste pingCtlAdminStatus la même enabled jusqu’à ce que vous la définissez sur disabled . Ainsi, pour obtenir l’état du test, vous devez examiner pingResultsOperStatus .

La pingCtlFrequency variable peut être utilisée pour programmer de nombreux tests pour un pingCtlEntry . Une fois qu’un test se termine normalement (vous n’avez pas arrêté le test) et que le nombre de secondes s’est écoulé, le test est re-lancé comme si vous pingCtlFrequencypingCtlAdminStatus l’aviez déjà mis en enabled place. Si vous intervenez à tout moment entre les tests répétées (que vous définissez ou que vous définissez), la fonctionnalité répétée est désactivée jusqu’à ce qu’un autre test soit lancé et se termine pingCtlAdminStatusdisabledpingCtlRowStatusnotInService normalement. Une valeur de 0 pour indique pingCtlFrequency que cette fonctionnalité répétée n’est pas active.

pingResultsIpTgtAddr et sont définies sur la valeur de l’adresse de destination résolue pingResultsIpTgtAddrType lorsque la valeur de est pingCtlTargetAddressTypedns . Lorsqu’un test commence avec succès et pingResultsOperStatus passe enabled à:

  • pingResultsIpTgtAddr est définie sur null-string .

  • pingResultsIpTgtAddrType est définie sur unknown .

pingResultsIpTgtAddr et pingResultsIpTgtAddrType ne sont pas définies tant que pingCtlTargetAddress l’adresse numérique n’a pas été résolu. Pour récupérer ces valeurs, pingResultsIpTgtAddrType recherchez toute autre valeur qu’après unknown avoir réussi à définir pingCtlAdminStatus . enabled

Au début d’un test, est initialisé à 1 et la première analyse est envoyée. Augmente de 1 à chaque fois qu’une sonde pingResultsSentProbespingResultsSentProbes est envoyée.

Au cours du test, toutes les pingCtlTimeOut secondes, les étapes suivantes se produisent:

  • pingProbeHistoryStatus l’correspondant pingProbeHistoryEntry dans est définie sur pingProbeHistoryTablerequestTimedOut .

  • Un pingProbeFailed piège est créé, si nécessaire.

  • Une tentative est faite pour envoyer la sonde suivante.

    Remarque :

    Il n’existe pas plus d’une sonde en cours pour chaque test.

Pour chaque enquête, vous pouvez recevoir l’un des résultats suivants:

  • L’hôte cible reconnaît l’sonde par une réponse.

  • L’sonde est times out; il n’y a aucune réponse de la part de l’hôte cible reconnaissant l’enquête.

  • L’enquête n’a pas pu être envoyée.

Chaque résultat de chaque enquête est enregistré dans pingProbeHistoryTable . Pour plus d’informations pingProbeHistoryTable sur , consultez pingProbeHistoryTable .

Lorsqu’une réponse est reçue de l’hôte cible, reconnaissant l’enquête actuelle:

  • pingResultsProbeResponses augmente de 1.

  • Les variables suivantes sont mises à jour:

    • pingResultsMinRtt—Temps d’aller-retour minimum

    • pingResultsMaxRtt—Temps d’aller-retour maximal

    • pingResultsAverageRtt— Temps moyen d’aller-retour

    • pingResultsRttSumOfSquares—Somme de places d’aller-retour

    • pingResultsLastGoodProbe— Tamp. de la dernière réponse

      Remarque :

      Seules les sondes qui entraînent une réponse de l’hôte cible contribuent au calcul des variables RTT (Round-Trip Time).

Lorsqu’une réponse à la dernière sonde est reçue ou que la dernière a été testée, le test est terminé.

pingProbeHistoryTable

Une entrée dans ( ) représente un résultat d’enquête et pingProbeHistoryTablepingProbeHistoryEntry est indexée par trois variables:

  • Les deux premières variables, et , sont les mêmes utilisées pour pingCtlOwnerIndex , qui identifie le pingCtlTestNamepingCtlTable test.

  • La troisième variable, qui va à pingProbeHistoryIndex l’encontre de l’identification unique de chaque résultat de la sonde.

Le nombre maximal pingProbeHistoryTable d’entrées créées pour un test donné est limité par pingCtlMaxRows . Si pingCtlMaxRows l’objectif est de 0, aucune pingProbeHistoryTable entrée n’est créée pour ce test.

Chaque fois qu’une analyse est déterminée, une valeur ajoutée est créée et ajoutée à . du nouveau est supérieure à la dernière ajoutée à ce test. est définie sur 1 si c’est la première entrée dans le pingProbeHistoryEntrypingProbeHistoryTablepingProbeHistoryIndexpingProbeHistoryEntrypingProbeHistoryEntrypingProbeHistoryTablepingProbeHistoryIndex tableau. Il est possible d’exécuter le même test plusieurs fois, de sorte que cet index ne cesse de croître.

Si pingProbeHistoryIndex les derniers pingProbeHistoryEntry ajouts sont ajoutés 0xFFFFFFFF, l’ajout pingProbeHistoryEntry suivant est donné sur pingProbeHistoryIndex 1.

Les données suivantes sont enregistrées pour chaque résultat de la sonde:

  • pingProbeHistoryResponse— Heure de vie (TTL)

  • pingProbeHistoryStatus— Ce qui s’est passé et pourquoi

  • pingProbeHistoryLastRC—Valeur du code de retour (RC) du paquet ICMP

  • pingProbeHistoryTime—Ampamp lorsque le résultat de la sonde a été déterminé

Lorsqu’une sonde n’est pas envoyée, pingProbeHistoryResponse elle est définie sur 0. Lors de l’heure d’attente d’une sonde, elle est définie sur la différence entre la durée d’attente de l’sonde et l’heure pingProbeHistoryResponse d’envoi de cette dernière.

Générer des pièges

Pour créer un piège, il convient de définir la pingCtlTrapGeneration bonne bit. Vous devez également configurer un groupe de traps pour recevoir des opérations à distance. Un piège est généré dans les conditions suivantes:

  • Un piège est généré chaque fois que pingProbeFailedpingCtlTrapProbeFailureFilter plusieurs sondes consécutives échouent pendant le test.

  • Un piège est généré lorsque le test est terminé pingTestFailed et qu’au moins un nombre pingCtlTrapTestFailureFilter de sondes échoue.

  • Un piège est généré lorsque le test est terminé et que les sondes sont pingTestCompleted moins nombreuses que les pingCtlTrapTestFailureFilter sondes à échouer.

    Remarque :

    Une sonde est considérée comme une défaillance lorsque le résultat de la sonde pingProbeHistoryStatus n’est rien en responseReceived plus.

Pour savoir comment configurer un groupe de traps pour recevoir des opérations à distance, consultez configuring SNMP Trap Groups et Exemple: Définition de trap notification pour les opérations distantes .

Collecte des résultats des tests Ping

Vous pouvez l’une ou l’autre sonder pour savoir si le test est terminé ou demander à ce qu’un piège soit envoyé une fois le pingResultsOperStatus test terminé. Pour plus d’informations pingResultsOperStatus sur , consultez le pingResultsTable. Pour plus d’informations sur les MIB de ping, consultez « Generating Traps».

Les statistiques sont ensuite calculées et stockées pingResultsTable dans les données suivantes:

  • pingResultsMinRtt—Temps d’aller-retour minimum

  • pingResultsMaxRtt—Temps d’aller-retour maximal

  • pingResultsAverageRtt— Temps moyen d’aller-retour

  • pingResultsProbeResponses— Nombre de réponses reçues

  • pingResultsSentProbes— Nombre de tentatives d’envoi de sondes

  • pingResultsRttSumOfSquares—Somme de places d’aller-retour

  • pingResultsLastGoodProbe— Tamp. de la dernière réponse

Vous pouvez également consulter pour obtenir des informations pingProbeHistoryTable plus détaillées sur chaque analyse. L’index utilisé pour commencer à 1, passe à 0xFFFFFFFF, et termine pingProbeHistoryTable encore par 1.

Par exemple, si l’examen présente un nombre de 15 et 5, une fois le premier test terminé, il contient des analyses de ce genre dans pingCtlProbeCountpingCtlMaxRowspingProbeHistoryTableTableau 1 .

Tableau 1 : Résultats dans pingProbeHistoryTable: Après le premier test ping

pingProbeHistoryIndex

Résultat de la sonde

11

Résultat de la 11e sonde d’exécuter 1

12

Résultat de la 12e sonde d’exécuter 1

13

Résultat de la 13e sonde d’exécuter 1

14

Résultat de la 14e sonde d’exécuter 1

15

Résultat de la 15e sonde d’exécuter 1

À l’issue de la première analyse du deuxième exécution de ce test, des sondes de ce même genre sont pingProbeHistoryTable contenues dans Tableau 2 .

Tableau 2 : Résultats dans pingProbeHistoryTable: Après la première analyse du deuxième test

pingProbeHistoryIndex

Résultat de la sonde

12

Résultat de la 12e sonde d’exécuter 1

13

Résultat de la 13e sonde d’exécuter 1

14

Résultat de la 14e sonde d’exécuter 1

15

Résultat de la 15e sonde d’exécuter 1

16

Résultat de la 1re sonde d’exécuter 2

Une fois le deuxième test terminé, il contient des analyses de ce genre pingProbeHistoryTable dans Tableau 3 .

Tableau 3 : Résultats dans pingProbeHistoryTable: Après le deuxième test ping

pingProbeHistoryIndex

Résultat de la sonde

26

Résultat de la 11e sonde d’exécuter 2

27

Résultat de la 12e sonde d’exécuter 2

28

Résultat de la 13e sonde d’exécuter 2

29

Résultat de la 14e sonde d’exécuter 2

30

Résultat de la 15e sonde d’exécuter 2

Les entrées d’historique peuvent être supprimées de MIB de deux manières:

  • D’autres entrées d’historique pour un test donné sont ajoutées et le nombre d’entrées d’historique pingCtlMaxRows dépasse. Les entrées les plus anciennes sont supprimées pour faire place aux nouvelles.

  • Vous supprimez l’ensemble du test par la pingCtlRowStatus définition sur destroy .

Arrêt d’un test ping

Pour arrêter un test actif, pingCtlAdminStatus définissez . disabled Pour arrêter le test et le supprimer, ainsi que tous les objets du pingCtlEntrypingResultsEntrypingHistoryEntry MIB, pingCtlRowStatus définissez sur destroy .

Interpréter les variables ping

Cette section clarifie les plages des variables suivantes qui ne sont pas expressément spécifiées dans le ping MIB:

  • pingCtlDataSize—La valeur de cette variable représente la taille totale de la charge utile (en octets) du paquet de la sonde sortante. Cette charge utile inclut le délai d’attente (8 octets) utilisé pour l’heure de l’sonde. Cette approche est cohérente avec la définition de pingCtlDataSize (valeur maximale de 65 507) et l’application ping standard.

    Si la valeur de la valeur se trouve entre 0 et 8 inclusivement, elle est ignorée et la charge utile est pingCtlDataSize de 8 octets (leamp). Le ping MIB part du principe que toutes les sondes sont timed; la charge utile doit toujours inclure le délai d’attente.

    Par exemple, si vous souhaitez ajouter une charge utile de 4 octets supplémentaires au paquet, vous devez le pingCtlDataSize définir sur 12.

  • pingCtlDataFill—Les 8 premiers octets du segment de données du paquet sont pour l’ampampille. Après cela, le pingCtlDataFill motif est utilisé dans l’insélation. Le schéma par défaut pingCtlDataFill (lorsqu’il n’est pas spécifié) est (00, 01, 02, 03 ... FF, 00, 01, 02, 03 ... FF, ...).

  • pingCtlMaxRows—La valeur maximale est de 255.

  • pingMaxConcurrentRequests—La valeur maximale est de 500.

  • pingCtlTrapProbeFailureFilter et pingCtlTrapTestFailureFilter —Une valeur de 0 pour ou n’est pas bien définie par le ping pingCtlTrapProbeFailureFilterpingCtlTrapTestFailureFilter MIB. Si pingCtlTrapProbeFailureFilter l’objectif est de 0, aucun piège n’est créé pour le pingProbeFailed test. Si pingCtlTrapTestFailureFilter l’objectif est de 0, aucun piège n’est créé pour le pingTestFailed test.

Utilisation de la MIB Traceroute pour les équipements de surveillance à distance qui s’exécutent Junos OS

Un test de traceroute est approximative des paquets de chemins pris entre l’hôte local et l’hôte distant.

La RFC 2925 fait référence à la description détaillée de traceroute MIB et fournit la définition asN.1 MIB du Traceroute MIB.

Lancer un test de traceroute

Avant de commencer un test de traceroute, configurez une vue d’MIB Traceroute. Cela permet d’autoriser les requêtes SNMP Set sur tracerouteMIB . Pour commencer un test, créez une ligne et traceRouteCtlTabletraceRouteCtlAdminStatus définissez sur enabled . Vous devez spécifier au moins les paramètres suivants avant de traceRouteCtlAdminStatusenabled définir:

  • traceRouteCtlOwnerIndexSnmpAdminString

  • traceRouteCtlTestNameSnmpAdminString

  • traceRouteCtlTargetAddressInetAddress

  • traceRouteCtlRowStatusRowStatus

Pour toutes les autres valeurs, les valeurs par défaut sont choisies, sauf indication contraire. traceRouteCtlOwnerIndex et sont utilisés comme index, de sorte traceRouteCtlTestName que leurs valeurs sont spécifiées dans l’OID. Pour créer une ligne, définissez ou fixez une ligne qui traceRouteCtlRowStatuscreateAndWaitcreateAndGo n’existe pas déjà. Une valeur de l’indique que toutes les informations nécessaires ont été définies et que le test peut active commencer ; peut être définie sur traceRouteCtlRowStatustraceRouteCtlAdminStatusenabled . Une requête SNMP qui définit l’échec si les informations requises dans la ligne ne sont pas spécifiées ou SettraceRouteCtlRowStatusactive incohérentes. Pour plus d’informations sur la configuration d’une vue, consultez Setting SNMP Views.

Il existe deux façons de démarrer un test traceroute:

Utilisation de plusieurs PDUS

Vous pouvez utiliser plusieurs PUS de demande (plusieurs PDUS, avec une ou plusieurs varbinds chacun) et définir les variables suivantes dans l’ordre de démarrer Set le test:

  • traceRouteCtlRowStatus pour créerAndWait

  • Toutes les variables de test appropriées

  • traceRouteCtlRowStatus à active

    L Junos OS vérifie désormais que toutes les informations nécessaires à l’exécuter d’un test ont été spécifiées.

  • traceRouteCtlAdminStatus à enabled

Utilisation d’un PDU unique

Vous pouvez utiliser un PDU de demande unique (un PDU, avec plusieurs varbinds) pour définir les variables suivantes pour Set commencer le test:

  • traceRouteCtlRowStatus à createAndGo

  • Toutes les variables de test appropriées

  • traceRouteCtlAdminStatus à activer

Surveillance d’un test traceroute en cours d’exécution

Lorsque le traceRouteCtlAdminStatus est activé avec succès, les données suivantes sont réalisées avant que l’accusé de réception de la demande de set SNMP ne soit renvoyé au client:

  • traceRouteResultsEntry est créé si elle n’existe pas déjà.

  • traceRouteResultsOperStatus transitions vers activées.

Pour plus d’informations, consultez les sections suivantes:

traceRouteResultsTable

Alors que le test est en cours d’exécution, ce traceRouteResultsTable permet de suivre l’état de ce test. La valeur de traceRouteResultsOperStatus est activée lorsque le test est en cours d’exécution et désactivé lorsqu’il a été arrêté.

La valeur de traceRouteCtlAdminStatus reste activée jusqu’à sa désactivation. Pour obtenir l’état du test, vous devez donc examiner traceRouteResultsOperStatus.

La variable traceRouteCtlFrequency permet de programmer de nombreux tests pour une seule traceRouteCtlEntry. Après la fin normale d’un test (vous n’avez pas arrêté le test) et que le nombre de secondes de traceRouteCtlFrequency s’est arrêté, le test est re-lancé comme si vous avait activé traceRouteCtlAdminStatus. Si vous intervenez à tout moment entre des tests répétées (vous définissez traceRouteCtlAdminStatus pour désactiver ou suivreRouteCtlRowStatus sans inservice), la fonctionnalité répétée est désactivée jusqu’à ce qu’un autre test soit lancé et se termine normalement. Une valeur de 0 pour traceRouteCtlFrequency indique que cette fonctionnalité répétée n’est pas active.

traceRouteResultsIpTgtAddr et traceRouteResultsIpTgtAddrType sont placés sur la valeur de l’adresse de destination résolution lorsque la valeur de traceRouteCtlTargetAddressType est dns. Lorsqu’un test commence avec succès et traceRouteResultsOperStatus transitions pour:

  • traceRouteResultsIpTgtAddr est mis en null-string.

  • traceRouteResultsIpTgtAddrType est connu.

traceRouteResultsIpTgtAddr et traceRouteResultsIpTgtAddrType ne sont pas définies jusqu’à ce que traceRouteCtlTargetAddress puisse être résolu sur une adresse numérique. Pour récupérer ces valeurs, recherchez traceRouteResultsIpTgtAddrType pour toute valeur autre que inconnue, après avoir activé la traceRouteCtlAdminStatus.

Au début d’un test, traceRouteResultsCurHopCount est initialisé pour suivreRouteCtlInitialTtl et traceRouteResultsCurProbeCount est initialisé sur 1. Chaque fois qu’un résultat d’enquête est déterminé, traceRouteResultsCurProbeCount augmente de 1. Si le test est en cours d’exécution, la valeur de traceRouteResultsCurprobeCount reflète l’analyse en cours pour laquelle les résultats n’ont pas encore été déterminés.

Le traceRouteCtlProbesPerHop du nombre de sondes est envoyé pour chaque valeur de time-to-live (TTL). Lorsque le résultat de la dernière sonde du saut actuel est déterminé, à condition que le saut actuel ne soit pas le saut de destination, traceRouteRouteResultsCurHopCount augmente de 1 et traceRouteResultsCurbeCount réinitialise à 1.

Au début d’un test, si c’est la première fois que ce test est exécuté pour ce traceRouteCtlEntry, traceRouteResultsTestAttempts et traceRouteResultsTestSuccesses sont initialisées sur 0.

À la fin de chaque exécution de test, traceRouteResultsOperStatus transitions vers désactivés, et traceRouteResultsTestAttts augmente de 1. Si le test a réussi à déterminer le chemin complet vers la cible, traceRouteResultsTestSuccesses augmente de 1 et traceRouteResultsLastGoodPath est actuellement définie.

traceRouteProbeResultsTable

Chaque entrée de traceRouteProbeHistoryTable est indexée par cinq variables:

  • Les deux premières variables, traceRouteCtlOwnerIndex et traceRouteCtlTestName, sont les mêmes que pour le traceRouteCtlTable et pour identifier le test.

  • La troisième variable, traceRouteProbeHistoryIndex, est un compteur qui commence à 1 et s’érode chez FFFFFFFFFF. Le nombre maximum d’entrées est limité par traceRouteCtlMaxRows.

  • La quatrième variable, traceRouteProbeHistoryHopIndex, indique à quel saut se trouve cette sonde (valeur de l’heure de vie ou TTL). Ainsi, le premier traceRouteCtlProbesPerHop d’entrées créées lors du démarrage d’un test a une valeur de traceRouteCtlInitialTtl pour traceRouteProbeHistoryHopIndex.

  • La cinquième variable, traceRouteProbeHistoryProbeIndex, est l’sonde du saut actuel. Il va de 1 à traceRouteCtlProbesPerHop.

Lors de l’exécution d’un test, dès qu’un résultat de la sonde est déterminé, l’analyse suivante est envoyée. Un maximum de traceRouteCtlTimeS secondes s’écoulént avant qu’une sonde ne soit indiquée avec la requête d’étatTimedOut et que la sonde suivante soit envoyée. Il n’y a jamais plus d’une analyse par traceroute en cours. Tous les résultats de la sonde qui reviennent après l’insé t d’une sonde sont ignorés.

Chaque sonde peut:

  • Résultat: une réponse de l’hôte reconnaissant l’enquête

  • Délai d’absence sans réponse de la part d’un hôte reconnaissant l’intervention de l’équipe de reconnaissance

  • Non envoyé

L’état de chaque sonde est enregistré dans traceRouteProbeHistoryTable avec traceRouteProbeHistoryStatus ensemble en conséquence.

Les mesures qui entraînent une réponse d’un hôte enregistrent les données suivantes:

  • traceRouteProbeHistoryResponse— Temps d’aller-retour (RTT)

  • traceRouteProbeHistoryHAddrType: le type de HAddr (argument suivant)

  • traceRouteProbeHistoryHAddr: l’adresse du saut

Quelle que soit la réponse de l’enquête, toutes les sondes sont enregistrées:

  • traceRouteProbeHistoryStatus: ce qui s’est passé et pourquoi

  • traceRouteProbeHistoryLastRC— Valeur du code de retour (RC) du paquet ICMP

  • traceRouteProbeHistoryTime - Heure d’attente lorsque le résultat de l’enquête a été déterminé

Lorsqu’une sonde ne peut pas être envoyée, traceRouteProbeHistoryResponse est définie sur 0. Lors de l’heure d’attente de l’une d’entre elles, traceRouteProbeHistoryResponse est définie sur la différence entre la durée d’attente de l’sonde et l’heure d’envoi de la sonde.

traceRouteHopsTable

Les entrées dans traceRouteHopsTable sont indexées par trois variables:

  • Les deux premiers, traceRouteCtlOwnerIndex et traceRouteCtlTestName, sont les mêmes utilisés pour traceRouteCtlTable et identifient le test.

  • La troisième variable, traceRouteHopsHopsHopIndex, indique le saut actuel, qui commence à 1 (pas traceRouteCtlInitialTtl).

Lors du début d’un test, toutes les entrées de traceRouteHopsTable avec le traceRouteCtlOwnerIndex et traceRouteCtlTestName sont supprimés. Les participations à ce tableau ne sont créées que si traceRouteCtlCreateHopsEntries est définie comme vrai.

Une nouvelle traceRouteHopsEntry est créée chaque fois que le premier résultat de la sonde pour un TTL donné est déterminé. La nouvelle entrée est créée, que la première sonde atteigne ou non un hôte. TraceRouteHopsHopIndex a augmenté de 1 pour cette nouvelle entrée.

Remarque :

TraceRouteHopsEntry peut ne pas avoir de valeur pour traceRouteHopsIpTgtAddress s’il n’y a aucune réponse aux sondes qui ont la TTL en question.

Chaque fois qu’une sonde atteint un hôte, l’adresse IP de cet hôte est disponible dans le résultat de la sonde. Si la valeur de traceRouteHopsIpTgtAddress du traceRouteHopsEntry actuel n’est pas définie, alors la valeur de traceRouteHopsIpTgtAddress est définie sur cette adresse IP. Si la valeur de traceRouteHopsIpTgtAddress du traceHopsEntry actuel est la même que l’adresse IP, alors la valeur ne change pas. Si la valeur de traceRouteHopsIpTgtAddress du traceRouteHopsEntry actuel est différente de cette adresse IP, indiquant un changement de chemin, une nouvelle traceRouteHopsEntry est créée avec:

  • traceRouteHopsHopsHopIndex variable augmenté de 1

  • traceRouteHopsIpTgtAddress ensemble sur l’adresse IP

    Remarque :

    Une nouvelle entrée pour un test est ajoutée pour suivreRouteHopsTable chaque fois qu’une nouvelle valeur TTL est utilisée ou que le chemin change. Par conséquent, le nombre d’entrées à un test peut dépasser le nombre de valeurs TTL différentes utilisées.

Lorsqu’un résultat d’une enquête est déterminé, la valeur traceRouteHopsSentProbes de la trace ActuelleRouteHopsEntry augmente de 1. Lorsqu’une sonde est déterminée et qu’elle atteint un hôte:

  • TraceRouteHopsProbesponses du traceRouteHopsEntry actuel a augmenté de 1.

  • Les variables suivantes sont mises à jour:

    • traceRouteResultsMinRtt: temps d’aller-retour minimum

    • traceRouteResultsMaxRtt: temps d’aller-retour maximal

    • traceRouteResultsAverageRtt: temps moyen d’aller-retour

    • traceRouteResultsRttSumOfas: somme de places d’aller-retour

    • traceRouteResultsLastGoodProbe- Timestamp de la dernière réponse

      Remarque :

      Seules les sondes qui atteignent un hôte affectent les valeurs d’aller-retour.

Générer des pièges

Pour générer n’importe quel piège, il convient de définir la traceRouteCtlTrapGeneration. Vous devez également configurer un groupe de traps pour recevoir des opérations à distance. Les traps sont générés dans les conditions suivantes:

  • traceRouteHopsIpTgtAddress de l’enquête actuelle est différente de la dernière sonde et de la même valeur TTL (traceRoutePathChange).

  • Un chemin vers la cible n’a pas pu être déterminé (traceRouteTestFailed).

Un chemin vers la cible a été déterminé (traceRouteTestCompleted).

Pour plus d’informations sur la configuration d’un groupe de traps afin de recevoir des opérations à distance, consultez la présentation Configuring SNMP Trap Groups et SNMP Remote Operations Présentation.

Surveillance de la réussite du test Traceroute

Lorsqu’un test est terminé, traceRouteResultsOperStatus le processus passe à enableddisabled . Cette transition se produit dans les situations suivantes:

  • Le test se termine avec succès. Un résultat d’enquête indique que la destination est atteinte. Dans ce cas, le saut actuel est le dernier saut. Les autres mesures de ce saut sont envoyées. Lorsque le dernier résultat de la sonde est déterminé pour le saut actuel, le test se termine.

  • traceRouteCtlMaxTtl est dépassé. La destination n’est jamais atteinte. Le test se termine après le nombre de sondes avec la valeur TTL égale à traceRouteCtlMaxttl avoir été envoyée.

  • traceRouteCtlMaxFailures est dépassé. Le nombre d’enquêtes consécutives qui se terminent par un état requestTimedOuttraceRouteCtlMaxFailures dépasse.

  • Vous terminez le test. Vous traceRouteCtlAdminStatus définissez ou disabled supprimez la ligne par la traceRouteCtlRowStatus définition sur destroy .

  • Vous avez mal configuré le test de traceroute. Une valeur ou une variable dans ce message est incorrecte et ne permet pas l’envoi traceRouteCtlTable d’une seule sonde. En raison de la nature des données, cette erreur n’a pas pu être déterminée tant que le test n’a pas été lancé. c’est-à-dire traceRouteResultsOperStatus jusqu’à ce qu’après la transition vers enabled . Dans ce cas, une entrée est ajoutée avec le traceRouteProbeHistoryTable code d’erreur traceRouteProbeHistoryStatus approprié.

Si traceRouteCtlTrapGeneration l’ensemble est correctement mis en place, le traceRouteTestFailed ou le piège est traceRouteTestCompleted généré.

Collecte des résultats des tests Traceroute

Vous pouvez soit songer à traceRouteResultsOperStatus pour savoir une fois le test terminé, soit demander à ce qu’un piège soit envoyé une fois le test terminé. Pour plus d’informations sur traceResultsOperStatus, consultez traceRouteResultsTable. Pour plus d’informations sur les pièges MIB traceroute, consultez la section « Generating Traps » (Suivi d’un test de traceroute en cours d’exécution).

Les statistiques sont ensuite calculées par saut, puis stockées dans traceRouteHopsTable. Ils incluent les étapes suivantes pour chaque saut:

  • traceRouteHopsIpTgtAddressType: type d’hôte d’adresse sur ce saut

  • traceRouteHopsIpTgtAddress: adresse de l’hôte à cet saut

  • traceRouteHopsMinRtt: temps d’aller-retour minimum

  • traceRouteHopsMaxRtt: temps d’aller-retour maximal

  • traceRouteHopsAverageRtt: temps moyen d’aller-retour

  • traceRouteHopsRttSumOfRouteSumOf Puis puisse dans la somme de carrés des trajets aller-retour

  • traceRouteHopsSentProbes: nombre de tentatives d’envoi de sondes

  • traceRouteHopsProbeResponses: nombre de réponses reçues

  • traceRouteHopsLastGoodProbe - Timestamp de la dernière réponse

Vous pouvez également consulter traceRouteProbeHistoryTable pour obtenir des informations plus détaillées sur chaque analyse. L’index utilisé pour traceRouteProbeHistoryTable démarre à 1, passe à 0xFFFFFFFF et s’termine par 1.

Par exemple, assumez les déclarations suivantes:

  • traceRouteCtlMaxRows est 10.

  • traceRouteCtlProbesPerHop est 5.

  • Il y a huit sauts vers la cible (la cible étant la huit).

  • Chaque sonde a envoyé les résultats en réponse à partir d’un hôte (le nombre de sondes envoyées n’est pas limité par les mesures traceRouteCtlMaxFailures).

Au cours de ce test, 40 sondes sont envoyées. À la fin du test, traceRouteProbeHistoryTable aurait un historique des analyses comme celles de Tableau 4 .

Tableau 4 : traceRouteProbeHistoryTable

HistoriquesIndex

HistoriqueHopIndex

HistoriqueProbeIndex

31

7

1

32

7

2

33

7

3

34

7

4

35

7

5

36

8

1

37

8

2

38

8

3

39

8

4

40

8

5

Arrêt d’un test de traceroute

Pour arrêter un test actif, traceRouteCtlAdminStatus définissez . disabled Pour arrêter un test et supprimer son , et les objets du traceRouteCtlEntrytraceRouteResultsEntrytraceRouteProbeHistoryEntrytraceRouteProbeHistoryEntry MIB, traceRouteCtlRowStatus définissez sur destroy .

Interpréter les variables Traceroute

Ce sujet contient des informations sur les plages de variables suivantes qui ne sont pas expressément spécifiées dans le rapport Traceroute MIB:

  • traceRouteCtlMaxRows—La valeur maximale traceRouteCtlMaxRows est de 2 550. Cela représente le TTL maximum (255) multiplié par le maximum pour traceRouteCtlProbesPerHop (10). Par conséquent, traceRouteProbeHistoryTable l’accommode un test complet à des valeurs maximales pour un traceRouteCtlEntry . En général, les valeurs maximales ne sont pas utilisées et sont capables de s’adapter à l’historique complet de traceRouteProbeHistoryTable nombreux tests pour les mêmes traceRouteCtlEntry .

  • traceRouteMaxConcurrentRequests—La valeur maximale est de 50. Si un test est en cours d’exécution, une analyse est en cours d’exécution. traceRouteMaxConcurrentRequests représente le nombre maximal de tests de traceroute dont traceRouteResultsOperStatus la valeur est de enabled . Toute tentative de démarrage d’un test avec des tests en cours d’exécution entraîne la création d’une sonde avec mise en œuvre, qui prendra traceRouteMaxConcurrentRequeststraceRouteProbeHistoryStatus fin maxConcurrentLimitReached immédiatement.

  • traceRouteCtlTable—Le nombre maximum d’entrées autorisées dans ce tableau est de 100. Toute tentative de création d’une 101e entrée entraîne un message pour BAD_VALUE SNMPv1 et un RESOURCE_UNAVAILABLE message pour SNMPv2.

Tableau de l'historique des versions
Version
Description
17.2X75-D100
À partir Junos OS version 17.2X75-D100, vous devez configurer lapm avant de lancer un ping ICMP.