Configurer les opérations à distance SNMP

Avant de commencer un test ping, configurez une vue MIB ping. Cela autorise les requêtes SNMP Set sur pingMIB. Pour plus d’informations, reportez-vous à la section Configurer les vues MIB.

À partir de Junos OS version 17.2X75-D100, vous devez configurer RPM avant de lancer un ping ICMP. Configurez RPM à l’aide de la edit services rpm commande.

Pour démarrer un test ping, créez une ligne dans pingCtlTable et définissez-la pingCtlAdminStatus sur enabled. Les informations minimales qui doivent être spécifiées avant le réglage pingCtlAdminStatus sur enabled sont les suivantes :

• pingCtlOwnerIndexSnmpAdminString

• pingCtlTestNameSnmpAdminString

• pingCtlTargetAddressInetAddress

• pingCtlTargetAddressTypeInetAddressType

• pingCtlRowStatusRowStatus

Pour toutes les autres valeurs, les valeurs par défaut sont choisies, sauf indication contraire. pingCtlOwnerIndex et pingCtlTestName sont utilisés comme index, de sorte que leurs valeurs sont spécifiées dans le cadre de l’identificateur d’objet (OID). Pour créer une ligne, définissez pingCtlRowStatus sur ou createAndGo sur createAndWait une ligne qui n’existe pas déjà. La valeur for activepingCtlRowStatus indique que toutes les informations nécessaires ont été fournies et que le test peut commencer ; pingCtlAdminStatus elle peut être définie sur enabled. Une requête SNMP Set définie pingCtlRowStatus sur active échoue si les informations nécessaires dans la ligne ne sont pas spécifiées ou sont incohérentes.

Pour plus d’informations sur la configuration d’une vue, reportez-vous à la section Définition des vues SNMP.

Lisez les sections suivantes pour savoir comment classer les variables.

Vous pouvez utiliser plusieurs PDU de requête (plusieurs PDU, avec un ou plusieurs Set varbinds chacun) et définir les variables suivantes dans cet ordre pour démarrer le test :

• pingCtlRowStatus À createAndWait

• Toutes les variables de test appropriées

• pingCtlRowStatus À active

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

• pingCtlAdminStatus À enabled

Vous pouvez utiliser une seule Set PDU de requête (une PDU, avec plusieurs varbinds) pour définir les variables suivantes afin de démarrer le test :

• pingCtlRowStatus À createAndGo

• Toutes les variables de test appropriées

• pingCtlAdminStatus À enabled

Pendant que le test est en cours d’exécution, pingResultsEntry garde une trace de l’état du test. La valeur de pingResultsOperStatus est pendant que le test est enabled en cours d’exécution et disabled lorsqu’il s’est arrêté.

La valeur de pingCtlAdminStatus reste jusqu’à enabled ce que vous la définissiez sur disabled. Ainsi, pour obtenir le statut du test, vous devez examiner pingResultsOperStatus.

La pingCtlFrequency variable peut être utilisée pour planifier plusieurs 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 pingCtlFrequency test est redémarré comme si vous aviez réglé pingCtlAdminStatus sur enabled. Si vous intervenez à tout moment entre des tests répétés (vous définissez pingCtlAdminStatus sur ou pingCtlRowStatus sur disablednotInService), la fonction de répétition est désactivée jusqu’à ce qu’un autre test soit démarré et se termine normalement. La valeur 0 pour pingCtlFrequency indique que cette fonction de répétition n’est pas active.

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

• pingResultsIpTgtAddr est défini sur null-string.

• pingResultsIpTgtAddrType est défini sur unknown.

pingResultsIpTgtAddr et pingResultsIpTgtAddrType ne sont pas définies tant qu’elles n’ont pingCtlTargetAddress pas été résolues en une adresse numérique. Pour récupérer ces valeurs, interrogez pingResultsIpTgtAddrType toute valeur autre qu’après unknown avoir défini pingCtlAdminStatus avec succès la valeur .enabled

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

Au fur et à mesure que le test s’exécute, toutes les secondes, les pingCtlTimeOut événements suivants se produisent :

• pingProbeHistoryStatuscar l’in pingProbeHistoryTable correspondant pingProbeHistoryEntry est défini sur requestTimedOut.

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

• Une tentative est faite pour envoyer la sonde suivante.

  REMARQUE :

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

Pour chaque sonde, vous pouvez recevoir l’un des résultats suivants :

• L’hôte cible accuse réception de la sonde avec une réponse.

• La sonde expire ; Il n’y a pas de réponse de l’hôte cible accusant réception de la sonde.

• La sonde n’a pas pu être envoyée.

Chaque résultat de sonde est enregistré au format pingProbeHistoryTable. Pour plus d’informations sur , reportez-vous à pingProbeHistoryTablela section pingProbeHistoryTable.

Lorsqu’une réponse est reçue de l’hôte cible accusant réception de la sonde en cours :

• pingResultsProbeResponses augmente de 1.

• Les variables suivantes sont mises à jour :

  • pingResultsMinRtt—Temps minimum d’aller-retour

  • pingResultsMaxRtt—Temps d’aller-retour maximal

  • pingResultsAverageRtt—Temps moyen aller-retour

  • pingResultsRttSumOfSquares—Somme des carrés des temps d’aller-retour

  • pingResultsLastGoodProbe—Horodatage de la dernière réponse

    REMARQUE :

    Seules les sondes qui génèrent une réponse de l’hôte cible contribuent au calcul des variables de temps d’aller-retour (RTT).

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

Une entrée dans pingProbeHistoryTable (pingProbeHistoryEntry) représente un résultat de sonde et est indexée par trois variables :

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

• La troisième variable, , pingProbeHistoryIndexest un compteur permettant d’identifier de manière unique chaque résultat de sonde.

Le nombre maximum d’entrées pingProbeHistoryTable créées pour un test donné est limité par pingCtlMaxRows. Si pingCtlMaxRows est défini sur 0, aucune entrée n’est pingProbeHistoryTable créée pour ce test.

Chaque fois qu’un résultat de sonde est déterminé, un est créé et ajouté à . du nouveau pingProbeHistoryEntry est supérieur de 1 au dernier pingProbeHistoryEntry ajouté à pingProbeHistoryTablepingProbeHistoryTablepour ce test. est pingProbeHistoryEntry défini sur 1 s’il s’agit de la première entrée de la table. pingProbeHistoryIndexpingProbeHistoryIndex Le même test peut être exécuté plusieurs fois, de sorte que cet indice ne cesse de croître.

Si pingProbeHistoryIndex le dernier pingProbeHistoryEntry ajout est 0xFFFFFFFF, le suivant pingProbeHistoryEntry ajouté est pingProbeHistoryIndex défini sur 1.

Les éléments suivants sont enregistrés pour chaque résultat de sonde :

• pingProbeHistoryResponse—Temps de vie (TTL)

• pingProbeHistoryStatus—Que s’est-il passé et pourquoi ?

• pingProbeHistoryLastRC: valeur du code de retour (RC) du paquet ICMP

• pingProbeHistoryTime: horodatage lorsque le résultat de la sonde a été déterminé

Lorsqu’une sonde ne peut pas être envoyée, pingProbeHistoryResponse prend la valeur 0. Lorsqu’une sonde expire, pingProbeHistoryResponse correspond à la différence entre le moment où l’on a découvert que la sonde avait expiré et l’heure à laquelle la sonde a été envoyée.

Pour qu’une interruption soit générée, le bit approprié doit pingCtlTrapGeneration être défini. Vous devez également configurer un groupe d’interruptions pour recevoir des opérations à distance. Une interruption est générée dans les conditions suivantes :

• Une pingProbeFailed interruption est générée chaque fois qu’un pingCtlTrapProbeFailureFilter nombre de sondes consécutives échouent pendant le test.

• Une pingTestFailed interruption est générée lorsque le test est terminé et qu’au moins pingCtlTrapTestFailureFilter un certain nombre de sondes échouent.

• Une pingTestCompleted interruption est générée à la fin du test et moins de pingCtlTrapTestFailureFilter sondes échouent.

  REMARQUE :

  Une sonde est considérée comme une défaillance lorsque pingProbeHistoryStatus le résultat de la sonde est autre chose que responseReceived.

Pour plus d’informations sur la configuration d’un groupe d’interruptions pour recevoir des opérations à distance, reportez-vous à la section Configuration des groupes d’interruptions SNMP et exemple : Définition d’une notification d’interruption pour les opérations à distance.

Vous pouvez utiliser plusieurs PDU de requête (plusieurs PDU, avec un ou plusieurs Set varbinds chacun) et définir les variables suivantes dans cet ordre pour démarrer le test :

• traceRouteCtlRowStatus pour créeretattendre

• Toutes les variables de test appropriées

• traceRouteCtlRowStatus À active

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

• traceRouteCtlAdminStatus À enabled

Vous pouvez utiliser une seule Set PDU de requête (une PDU, avec plusieurs varbinds) pour définir les variables suivantes afin de démarrer le test :

• traceRouteCtlRowStatus À createAndGo

• Toutes les variables de test appropriées

• traceRouteCtlAdminStatus à activé

Pendant l’exécution du test, ce traceRouteResultsTable effectue le suivi de l’état du test. La valeur de traceRouteResultsOperStatus est activée pendant l’exécution du test et désactivée lorsqu’il s’arrête.

La valeur de traceRouteCtlAdminStatus reste activée jusqu’à ce que vous la définissiez sur désactivé. Par conséquent, pour obtenir l’état du test, vous devez examiner traceRouteResultsOperStatus.

La variable traceRouteCtlFrequency peut être utilisée pour planifier de nombreux tests pour une traceRouteCtlEntry. Une fois qu’un test se termine normalement (vous n’avez pas arrêté le test) et que le nombre de secondes traceRouteCtlFrequency s’est écoulé, le test est redémarré comme si vous aviez défini traceRouteCtlAdminStatus sur enabled. Si vous intervenez à tout moment entre des tests répétés (vous définissez traceRouteCtlAdminStatus sur disabled ou traceRouteCtlRowStatus sur notInService), la fonctionnalité de répétition est désactivée jusqu’à ce qu’un autre test soit démarré et se termine normalement. La valeur 0 pour traceRouteCtlFrequency indique que cette entité de répétition n’est pas active.

traceRouteResultsIpTgtAddr et traceRouteResultsIpTgtAddrType sont définis sur la valeur de l’adresse de destination résolue lorsque la valeur de traceRouteCtlTargetAddressType est dns. Lorsqu’un test démarre correctement et que traceRouteResultsOperStatus passe à activé :

• traceRouteResultsIpTgtAddr est défini sur null-string.

• traceRouteResultsIpTgtAddrType est défini sur unknown.

traceRouteResultsIpTgtAddr et traceRouteResultsIpTgtAddrType ne sont pas définis tant que traceRouteCtlTargetAddress ne peut pas être résolu en adresse numérique. Pour récupérer ces valeurs, interrogez traceRouteResultsIpTgtAddrType pour toute valeur autre que unknown après avoir défini traceRouteCtlAdminStatus sur enabled.

Au début d’un test, traceRouteResultsCurHopCount est initialisé à traceRouteCtlInitialTtl et traceRouteResultsCurProbeCount est initialisé à 1. Chaque fois qu’un résultat de sonde est déterminé, traceRouteResultsCurProbeCount augmente de 1. Pendant l’exécution du test, la valeur de traceRouteResultsCurProbeCount reflète la sonde en attente actuelle pour laquelle les résultats n’ont pas encore été déterminés.

Le nombre de sondes traceRouteCtlProbesPerHop est envoyé pour chaque valeur de durée de vie (TTL). Lorsque le résultat de la dernière sonde pour le saut actuel est déterminé, à condition que le saut actuel ne soit pas le saut de destination, traceRouteResultsCurHopCount augmente de 1 et traceRouteResultsCurProbeCount est réinitialisé à 1.

Au début d’un test, s’il s’agit de la première fois que ce test est exécuté pour ce traceRouteCtlEntry, traceRouteResultsTestAttempts et traceRouteResultsTestSuccesses sont initialisés à 0.

À la fin de chaque exécution de test, traceRouteResultsOperStatus passe à désactivé et traceRouteResultsTestAttempts augmente de 1. Si le test a réussi à déterminer le chemin d’accès complet à la cible, traceRouteResultsTestSuccesses augmente de 1 et traceRouteResultsLastGoodPath est défini sur l’heure actuelle.

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

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

• La troisième variable, traceRouteProbeHistoryIndex, est un compteur, commençant à partir de 1 et s’encapsulant à FFFFFFFF. Le nombre maximal d’entrées est limité par traceRouteCtlMaxRows.

• La quatrième variable, traceRouteProbeHistoryHopIndex, indique à quel saut cette sonde est destinée (la durée de vie réelle ou la valeur TTL). Ainsi, le premier nombre d’entrées traceRouteCtlProbesPerHop créé au démarrage d’un test a la valeur traceRouteCtlInitialTtl pour traceRouteProbeHistoryHopIndex.

• La cinquième variable, traceRouteProbeHistoryProbeIndex, est la sonde du saut actuel. Il est compris entre 1 et traceRouteCtlProbesPerHop.

Pendant qu’un test est en cours d’exécution, dès qu’un résultat de sonde est déterminé, la sonde suivante est envoyée. Un maximum de secondes traceRouteCtlTimeOut s’écoule avant qu’une sonde ne soit marquée avec l’état requestTimedOut et que la sonde suivante ne soit envoyée. Il n’y a jamais plus d’une sonde en suspens par test de traceroute. Tout résultat de sonde qui revient après l’expiration d’une sonde est ignoré.

Chaque sonde peut :

• Résultat d’une réponse d’un hôte accusant réception de la sonde

• Délai d’attente sans réponse de l’hôte accusant réception de la sonde

• Échec de l’envoi

Chaque état de sonde est enregistré dans traceRouteProbeHistoryTable avec traceRouteProbeHistoryStatus défini en conséquence.

Les sondes qui génèrent une réponse d’un hôte enregistrent les données suivantes :

• traceRouteProbeHistoryResponse : temps d’aller-retour (RTT)

• traceRouteProbeHistoryHAddrType : type de HAddr (argument suivant)

• traceRouteProbeHistoryHAddr : adresse du saut

Toutes les sondes, qu’elles aient reçu ou non une réponse, ont les éléments suivants enregistrés :

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

• traceRouteProbeHistoryLastRC : valeur du code de retour (RC) du paquet ICMP

• traceRouteProbeHistoryTime : horodatage du résultat de la sonde

Lorsqu’une sonde ne peut pas être envoyée, traceRouteProbeHistoryResponse prend la valeur 0. Lorsqu’une sonde expire, traceRouteProbeHistoryResponse est défini sur la différence entre l’heure à laquelle la sonde a expiré et l’heure à laquelle la sonde a été envoyée.

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

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

• La troisième variable, traceRouteHopsHopIndex, indique le saut actuel, qui commence à 1 (et non traceRouteCtlInitialTtl).

Lorsqu’un test démarre, toutes les entrées de traceRouteHopsTable avec traceRouteCtlOwnerIndex et traceRouteCtlTestName sont supprimées. Les entrées de cette table ne sont créées que si traceRouteCtlCreateHopsEntries a la valeur true.

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. La valeur de traceRouteHopsHopIndex est augmentée de 1 pour cette nouvelle entrée.

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 de la traceRouteHopsEntry actuelle n’est pas définie, la valeur de traceRouteHopsIpTgtAddress est définie sur cette adresse IP. Si la valeur de traceRouteHopsIpTgtAddress de la traceRouteHopsEntry actuelle est identique à l’adresse IP, la valeur ne change pas. Si la valeur de traceRouteHopsIpTgtAddress de la traceRouteHopsEntry actuelle est différente de cette adresse IP, indiquant un changement de chemin, une nouvelle traceRouteHopsEntry est créée avec :

• Variable traceRouteHopsHopIndex augmentée de 1

• traceRouteHopsIpTgtAddress défini sur l’adresse IP

  REMARQUE :

  Une nouvelle entrée pour un test est ajoutée à traceRouteHopsTable chaque fois qu’une nouvelle valeur TTL est utilisée ou que le chemin d’accès change. Ainsi, le nombre d’entrées pour un test peut dépasser le nombre de valeurs TTL différentes utilisées.

Lorsqu’un résultat de sonde est déterminé, la valeur traceRouteHopsSentProbes de la traceRouteHopsEntry actuelle augmente de 1. Lorsqu’un résultat de sonde est déterminé et que la sonde atteint un hôte :

• La valeur traceRouteHopsProbeResponses de la traceRouteHopsEntry actuelle est augmentée de 1.

• Les variables suivantes sont mises à jour :

  • traceRouteResultsMinRtt—Temps d’aller-retour minimal

  • traceRouteResultsMaxRtt : durée d’aller-retour maximale

  • traceRouteResultsAverageRtt : temps d’aller-retour moyen

  • traceRouteResultsRttSumOfSquares : somme des carrés des temps d’aller-retour

  • traceRouteResultsLastGoodProbe : horodatage de la dernière réponse

    REMARQUE :

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

Pour générer une interruption, un bit approprié de traceRouteCtlTrapGeneration doit être défini. Vous devez également configurer un groupe d’interruptions pour recevoir des opérations à distance. Les interruptions sont générées dans les conditions suivantes :

• traceRouteHopsIpTgtAddress de la sonde actuelle est différente de la dernière sonde avec la même valeur TTL (traceRoutePathChange).

• Un chemin d’accès à la cible n’a pas pu être déterminé (traceRouteTestFailed).

Un chemin d’accès à la cible a été déterminé (traceRouteTestCompleted).

Pour plus d’informations sur la configuration d’un groupe d’interruptions pour recevoir des opérations à distance, reportez-vous aux sections Configuration des groupes d’interruptions SNMP et Présentation des opérations à distance SNMP.