Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

Konfigurieren von SNMP-Remotevorgängen

Überblick über SNMP-Remote-Vorgänge

Ein SNMP-Remote-Vorgang ist ein beliebiger Prozess auf dem Router, der über SNMP ferngesteuert werden kann. Junos OS bietet derzeit Unterstützung für zwei SNMP-Remote-Vorgänge: die Ping-MIB und die Traceroute-MIB, definiert in RFC 2925. Mithilfe dieser MIBs kann ein SNMP-Client im Netzwerkmanagementsystem (NMS):

  • Starten einer Reihe von Vorgängen auf einem Router

  • Benachrichtigung erhalten, wenn die Vorgänge abgeschlossen sind

  • Sammeln Sie die Ergebnisse der einzelnen Vorgänge

Junos OS bietet auch erweiterte Funktionen für diese MIBs in den unternehmensspezifischen Erweiterungen jnxPingMIB von Juniper Networks und jnxTraceRouteMIB. Weitere Informationen zu jnxPingMIB und jnxTraceRouteMIBfinden Sie unter PING MIB und Traceroute MIB.

In diesem Thema werden die folgenden Abschnitte behandelt:

Anforderungen für den SNMP-Remote-Betrieb

Um SNMP-Remotevorgänge verwenden zu können, sollten Sie mit SNMP-Konventionen vertraut sein. Außerdem müssen Sie das Junos-Betriebssystem so konfigurieren, dass die Verwendung der MIBs für den Remotebetrieb zulässig ist.

Bevor Sie die Ping-MIB starten, lesen Sie Starten eines Ping-Tests.

Bevor Sie die Traceroute MIB starten, lesen Sie den Abschnitt Starten eines Traceroute-Tests.

Festlegen von SNMP-Ansichten

Für alle Remote-Betriebs-MIBs, die von Junos OS unterstützt werden, müssen die SNMP-Clients über Lese-/Schreibberechtigungen verfügen. Die standardmäßige SNMP-Konfiguration von Junos OS stellt Clients mit einer Community-Zeichenfolge keine solchen Berechtigungen zur Verfügung.

Um Lese-/Schreibrechte für eine SNMP-Community-Zeichenfolge festzulegen, fügen Sie die folgenden Anweisungen auf Hierarchieebene [edit snmp] ein:

Beispiel: Festlegen von SNMP-Ansichten

Um eine Community mit dem Namen remote-community zu erstellen, die SNMP-Clients Lese- und Schreibzugriff auf die Ping-MIB, jnxPing MIB, Traceroute-MIB und jnxTraceRoute MIB gewährt, fügen Sie die folgenden Anweisungen auf Hierarchieebene [edit snmp] ein:

Weitere Informationen zu dieser community Anweisung finden Sie unter Konfigurieren von SNMP-Communities und community (SNMP).

Weitere Informationen zur view Anweisung finden Sie unter Konfigurieren von MIB-Ansichten, Ansicht (SNMP-Community)und Ansicht (Konfigurieren einer MIB-Ansicht).

Festlegen der Trap-Benachrichtigung für Remote-Vorgänge

Sie müssen nicht nur die MIB für Remotevorgänge für die Trap-Benachrichtigung konfigurieren, sondern auch das Junos-Betriebssystem. Sie müssen einen Zielhost für Traps für Remotevorgänge angeben.

Um die Trap-Benachrichtigung für SNMP-Remotevorgänge zu konfigurieren, fügen Sie die categories und-Anweisungen targets auf Hierarchieebene [edit snmp trap-group group-name] ein:

Beispiel: Festlegen der Trap-Benachrichtigung für Remote-Vorgänge

Geben Sie als Zielhost für alle Remote-Operation-Traps an 172.17.12.213 :

Weitere Informationen zu Überfüllungsgruppen finden Sie unter Konfigurieren von SNMP-Trap-Gruppen.

Verwenden von Zeichenfolgenindizes variabler Länge

Alle tabellarischen Objekte in den von Junos OS unterstützten MIBs für Remotevorgänge werden durch zwei Variablen vom Typ SnmpAdminString. Weitere Informationen zu finden Sie unter SnmpAdminStringRFC 2571.

Junos OS behandelt SnmpAdminString sich nicht anders als der Oktett-String-Variablentyp. Die Indizes sind jedoch als variable Länge definiert. Wenn eine Zeichenfolge variabler Länge als Index verwendet wird, muss die Länge der Zeichenfolge als Teil des Objektbezeichners (OID) enthalten sein.

Beispiel: Festlegen von Zeichenfolgenindizes variabler Länge

Um auf die Variable pingCtlTargetAddress einer Zeile in pingCtlTable where pingCtlOwnerIndex is bob und pingCtlTestName is testzu verweisen, verwenden Sie den folgenden Objektbezeichner (OID):

Weitere Informationen zur Definition der Ping-MIB finden Sie unter RFC 2925.

Protokollierung aktivieren

Der SNMP-Fehlercode, der als Antwort auf SNMP-Anforderungen zurückgegeben wird, kann nur eine allgemeine Beschreibung des Problems liefern. Die vom Remote-Betriebsprozess protokollierten Fehlerbeschreibungen können oft detailliertere Informationen über das Problem liefern und Ihnen helfen, das Problem schneller zu lösen. Diese Protokollierung ist standardmäßig nicht aktiviert. Um die Protokollierung zu aktivieren, fügen Sie die flag general Anweisung auf Hierarchieebene [edit snmp traceoptions] ein:

Wenn der Remote-Betriebsprozess eine SNMP-Anforderung empfängt, die er nicht verarbeiten kann, wird der Fehler in der /var/log/rmopd Datei protokolliert. Um diese Protokolldatei zu überwachen, geben Sie den monitor start rmopd Befehl im Betriebsmodus der Befehlszeilenschnittstelle (CLI) ein.

Verwenden der Ping MIB für Remoteüberwachungsgeräte mit Junos OS

Ein Ping-Test wird verwendet, um zu bestimmen, ob Pakete, die vom lokalen Host gesendet werden, den angegebenen Host erreichen und zurückgegeben werden. Wenn der angegebene Host erreicht werden kann, liefert der Ping-Test die ungefähre Roundtrip-Zeit für die Pakete. Ping-Testergebnisse werden in pingResultsTable und pingProbeHistoryTablegespeichert.

RFC 2925 ist die maßgebliche Beschreibung der Ping-MIB im Detail und enthält die ASN.1-MIB-Definition der Ping-MIB.

Starten Sie einen Ping-Test

Verwenden Sie dieses Thema, um einen ICMP-Ping-Test zu starten. Es gibt zwei Möglichkeiten, einen Ping-Test zu starten: mit mehreren Set Protocol Data Units (PDUs) oder mit einer einzelnen Set PDU.

Vorbereitungen

Bevor Sie einen Ping-Test starten, konfigurieren Sie eine Ping-MIB-Ansicht. Dies ermöglicht SNMP-Anforderungen Set für pingMIB. Weitere Informationen finden Sie unter Konfigurieren von MIB-Ansichten.

Ab Junos OS Version 17.2X75-D100 müssen Sie RPM konfigurieren, bevor Sie einen ICMP-Ping starten. Konfigurieren Sie RPM mit dem edit services rpm Befehl.

Starten Sie einen Ping-Test

Um einen Ping-Test zu starten, erstellen Sie eine Zeile in pingCtlTable und legen Sie pingCtlAdminStatus sie auf enabled. Die Mindestinformationen, die vor der Einstellung pingCtlAdminStatus angegeben enabled werden müssen, sind:

  • pingCtlOwnerIndexSnmpAdminString

  • pingCtlTestNameSnmpAdminString

  • pingCtlTargetAddressInetAddress

  • pingCtlTargetAddressTypeInetAddressType

  • pingCtlRowStatusRowStatus

Für alle anderen Werte werden Standardwerte ausgewählt, sofern nicht anders angegeben. pingCtlOwnerIndex und pingCtlTestName als Index verwendet werden, werden ihre Werte als Teil des Objektbezeichners (OID) angegeben. Um eine Zeile zu erstellen, legen Sie sie auf createAndWait oder createAndGo auf eine Zeile festpingCtlRowStatus , die noch nicht vorhanden ist. Der Wert for activepingCtlRowStatus zeigt an, dass alle erforderlichen Informationen angegeben wurden und der Test beginnen kann; pingCtlAdminStatus kann auf enabledgesetzt werden. Eine SNMP-Anforderung Set , die auf active festgelegt pingCtlRowStatusist, schlägt fehl, wenn die erforderlichen Informationen in der Zeile nicht angegeben oder inkonsistent sind.

Weitere Informationen zum Konfigurieren einer Ansicht finden Sie unter Festlegen von SNMP-Ansichten.

Lesen Sie die folgenden Abschnitte, um zu erfahren, wie Sie die Variablen anordnen.

Verwenden Sie mehrere PDUs

Sie können mehrere Set Anforderungs-PDUs (mehrere PDUs mit jeweils einem oder mehreren varbinds) verwenden und die folgenden Variablen in dieser Reihenfolge festlegen, um den Test zu starten:

  • pingCtlRowStatus An createAndWait

  • Alle geeigneten Testvariablen

  • pingCtlRowStatus An active

    Junos OS überprüft nun, ob alle erforderlichen Informationen zum Ausführen eines Tests angegeben wurden.

  • pingCtlAdminStatus An enabled

Verwenden einer einzelnen PDU

Sie können eine PDU mit einer einzelnen Set Anforderung (eine PDU mit mehreren varbinds) verwenden, um die folgenden Variablen zum Starten des Tests festzulegen:

  • pingCtlRowStatus An createAndGo

  • Alle geeigneten Testvariablen

  • pingCtlAdminStatus An enabled

Überwachen eines laufenden Ping-Tests

Wenn pingCtlAdminStatus erfolgreich auf enabledgesetzt ist, wird Folgendes ausgeführt, bevor die Bestätigung der SNMP-Anforderung Set an den Client zurückgesendet wird:

  • pingResultsEntry erstellt wird, wenn es noch nicht vorhanden ist.

  • pingResultsOperStatus Übergänge zu enabled.

Weitere Informationen finden Sie in den folgenden Abschnitten:

pingResultsTable

Während der Test ausgeführt wird, pingResultsEntry wird der Status des Tests nachverfolgt. Der Wert von pingResultsOperStatus ist, enabled während der Test ausgeführt wird und disabled wenn er beendet wurde.

Der Wert von pingCtlAdminStatus bleibt bestehen enabled , bis Sie ihn auf festlegen. disabled Um den Status des Tests zu erhalten, müssen Sie daher . pingResultsOperStatus

Die Variable pingCtlFrequency kann verwendet werden, um viele Tests für eine pingCtlEntry. Nachdem ein Test normal beendet wurde (Sie haben den Test nicht gestoppt) und die pingCtlFrequency Anzahl der Sekunden verstrichen ist, wird der Test erneut gestartet, als ob Sie auf eingestellt hätten pingCtlAdminStatusenabled. Wenn Sie zu einem beliebigen Zeitpunkt zwischen wiederholten Tests eingreifen (Sie stellen pingCtlAdminStatus auf disabled oder pingCtlRowStatus auf notInService), wird die Wiederholungsfunktion deaktiviert, bis ein anderer Test gestartet wird und normal endet. Der Wert 0 für pingCtlFrequency gibt an, dass diese Wiederholungsfunktion nicht aktiv ist.

pingResultsIpTgtAddr und pingResultsIpTgtAddrType werden auf den Wert der aufgelösten Zieladresse gesetzt, wenn der Wert von pingCtlTargetAddressType ist dns. Wenn ein Test erfolgreich gestartet wurde und pingResultsOperStatus zu Folgendem enabledübergeht:

  • pingResultsIpTgtAddr auf gesetzt null-stringist.

  • pingResultsIpTgtAddrType auf gesetzt unknownist.

pingResultsIpTgtAddr und pingResultsIpTgtAddrType werden erst gesetzt, wenn pingCtlTargetAddress sie in eine numerische Adresse aufgelöst werden können. Um diese Werte abzurufen, fragen pingResultsIpTgtAddrType Sie einen anderen Wert ab als unknown nach dem erfolgreichen Festlegen pingCtlAdminStatus auf enabled.

Zu Beginn eines Tests wird der Wert auf 1 initialisiert, und der erste Test wird gesendet. erhöht sich jedes Mal, pingResultsSentProbes wenn ein Test gesendet wird, pingResultsSentProbes um 1.

Während der Test ausgeführt wird, geschieht jede pingCtlTimeOut Sekunde Folgendes:

  • pingProbeHistoryStatus für das entsprechende pingProbeHistoryEntry in pingProbeHistoryTable wird auf gesetzt requestTimedOut.

  • Bei Bedarf wird ein pingProbeFailed Trap generiert.

  • Es wird versucht, die nächste Sonde zu senden.

    HINWEIS:

    Für jeden Test ist nicht mehr als eine ausstehende Sonde vorhanden.

Für jede Sonde können Sie eines der folgenden Ergebnisse erhalten:

  • Der Zielhost quittiert die Sondierung mit einer Antwort.

  • Bei der Sondierung tritt eine Zeitüberschreitung auf. Es gibt keine Antwort vom Zielhost, der den Test bestätigt.

  • Die Sonde konnte nicht gesendet werden.

Jedes Sondierungsergebnis wird in pingProbeHistoryTableaufgezeichnet. Weitere Informationen zu pingProbeHistoryTable, siehe pingProbeHistoryTable.

Wenn eine Antwort vom Zielhost eingeht, die die aktuelle Sondierung bestätigt:

  • pingResultsProbeResponses Erhöht sich um 1.

  • Die folgenden Variablen werden aktualisiert:

    • pingResultsMinRtt—Minimale Hin- und Rücklaufzeit

    • pingResultsMaxRtt—Maximale Round-Trip-Zeit

    • pingResultsAverageRtt—Durchschnittliche Hin- und Rücklaufzeit

    • pingResultsRttSumOfSquares—Summe der Quadrate der Umlaufzeiten

    • pingResultsLastGoodProbe—Zeitstempel der letzten Antwort

      HINWEIS:

      Nur Sonden, die zu einer Antwort des Zielhosts führen, tragen zur Berechnung der RTT-Variablen (Round-Trip Time) bei.

Wenn eine Antwort auf den letzten Test empfangen wird oder bei dem letzten Test ein Timeout aufgetreten ist, ist der Test abgeschlossen.

pingProbeHistoryTable

Ein Eintrag in pingProbeHistoryTable (pingProbeHistoryEntry) stellt ein Testergebnis dar und wird durch drei Variablen indiziert:

  • Die ersten beiden Variablen, und pingCtlTestName, sind die gleichen, pingCtlOwnerIndexdie für pingCtlTableverwendet werden, die den Test identifiziert.

  • Die dritte Variable, pingProbeHistoryIndex, ist ein Zähler zur eindeutigen Identifizierung jedes Sondierungsergebnisses.

Die maximale Anzahl der Einträge, die pingProbeHistoryTable für einen bestimmten Test erstellt werden, ist begrenzt durch pingCtlMaxRows. Wenn pingCtlMaxRows der Wert auf 0 gesetzt ist, werden keine pingProbeHistoryTable Einträge für diesen Test erstellt.

Jedes Mal, wenn ein Sondierungsergebnis ermittelt wird, wird a pingProbeHistoryEntry erstellt und zu pingProbeHistoryTableaddiert. pingProbeHistoryIndex des neuen pingProbeHistoryEntry ist 1 größer als der zuletzt pingProbeHistoryEntry für diesen Test hinzugefügte Wert pingProbeHistoryTable . pingProbeHistoryIndex wird auf 1 gesetzt, wenn dies der erste Eintrag in der Tabelle ist. Derselbe Test kann mehrmals ausgeführt werden, sodass dieser Index ständig wächst.

Wenn pingProbeHistoryIndex der zuletzt pingProbeHistoryEntry hinzugefügte Wert 0xFFFFFFFF ist, wurde pingProbeHistoryIndex der nächste pingProbeHistoryEntryhinzugefügte Wert auf 1 gesetzt.

Für jedes Sondierungsergebnis wird Folgendes aufgezeichnet:

  • pingProbeHistoryResponse—Zeit zu leben (TTL)

  • pingProbeHistoryStatus—Was geschah und warum?

  • pingProbeHistoryLastRC—Rückgabecode-Wert (RC) des ICMP-Pakets

  • pingProbeHistoryTime– Zeitstempel, wann das Sondierungsergebnis ermittelt wurde

Wenn ein Test nicht gesendet werden kann, pingProbeHistoryResponse wird auf 0 gesetzt. Wenn bei einem Test ein Timeout auftritt, wird auf die Differenz zwischen dem Zeitpunkt, zu dem das Timeout für den Test erkannt wurde, und dem Zeitpunkt, pingProbeHistoryResponse zu dem der Test gesendet wurde, festgelegt.

Fallen generieren

Damit ein Trap generiert werden kann, muss das entsprechende Bit von pingCtlTrapGeneration gesetzt werden. Außerdem müssen Sie eine Trap-Gruppe konfigurieren, um Remotevorgänge zu empfangen. Ein Trap wird unter den folgenden Bedingungen generiert:

  • Ein pingProbeFailed Trap wird jedes Mal generiert, wenn pingCtlTrapProbeFailureFilter mehrere aufeinanderfolgende Sonden während des Tests fehlschlagen.

  • Ein pingTestFailed Trap wird generiert, wenn der Test abgeschlossen ist und mindestens pingCtlTrapTestFailureFilter eine bestimmte Anzahl von Sonden fehlschlägt.

  • Ein pingTestCompleted Trap wird generiert, wenn der Test abgeschlossen ist und weniger als pingCtlTrapTestFailureFilter Sonden fehlschlagen.

    HINWEIS:

    Eine Sonde wird als fehlgeschlagen betrachtet, wenn pingProbeHistoryStatus das Testergebnis etwas anderes als responseReceivedist.

Informationen zum Konfigurieren einer Trap-Gruppe für den Empfang von Remote-Vorgängen finden Sie unter Konfigurieren von SNMP-Trap-Gruppen und Beispiel: Festlegen der Trap-Benachrichtigung für Remote-Vorgänge.

Sammeln Sie Ping-Testergebnisse

Sie können entweder eine Abfrage pingResultsOperStatus durchführen, um herauszufinden, wann der Test abgeschlossen ist, oder anfordern, dass ein Trap gesendet wird, wenn der Test abgeschlossen ist. Weitere Informationen zu pingResultsOperStatusfinden Sie unter pingResultsTable. Weitere Informationen zu Ping-MIB-Traps finden Sie unter Generieren von Traps.

Die Statistiken, die berechnet und dann gespeichert werden pingResultsTable , umfassen:

  • pingResultsMinRtt—Minimale Hin- und Rücklaufzeit

  • pingResultsMaxRtt—Maximale Round-Trip-Zeit

  • pingResultsAverageRtt—Durchschnittliche Hin- und Rücklaufzeit

  • pingResultsProbeResponses—Anzahl der eingegangenen Antworten

  • pingResultsSentProbes—Anzahl der Versuche, Sondierungen zu senden

  • pingResultsRttSumOfSquares—Summe der Quadrate der Umlaufzeiten

  • pingResultsLastGoodProbe—Zeitstempel der letzten Antwort

Sie können auch konsultieren, um detailliertere Informationen zu den einzelnen Sonden zu erhalten pingProbeHistoryTable . Der Index, der für pingProbeHistoryTable verwendet wird, beginnt bei 1, geht auf 0xFFFFFFFF und wird wieder auf 1 umbrochen.

Wenn pingCtlProbeCount z. B. 15 und pingCtlMaxRows 5 ist, enthält nach Abschluss der ersten Ausführung dieses Tests pingProbeHistoryTable Sonden wie die in Tabelle 1.

Tabelle 1: Ergebnisse in pingProbeHistoryTable: Nach dem ersten Ping-Test

pingProbeHistoryIndex

Ergebnis der Sondierung

11

Ergebnis der 11. Sondierung aus Durchlauf 1

12

Ergebnis der 12. Sondierung aus Lauf 1

13

Ergebnis der 13. Sondierung aus Durchlauf 1

14

Ergebnis der 14. Sondierung aus Lauf 1

15

Ergebnis der 15. Sondierung aus Durchlauf 1

Nach Abschluss der ersten Sonde des zweiten Durchlaufs dieses Tests pingProbeHistoryTable werden Sonden wie die in Tabelle 2enthalten.

Tabelle 2: Ergebnisse in pingProbeHistoryTable: Nach der ersten Sonde der zweiten Prüfung

pingProbeHistoryIndex

Ergebnis der Sondierung

12

Ergebnis der 12. Sondierung aus Lauf 1

13

Ergebnis der 13. Sondierung aus Durchlauf 1

14

Ergebnis der 14. Sondierung aus Lauf 1

15

Ergebnis der 15. Sondierung aus Durchlauf 1

16

Ergebnis der 1. Sondierung aus Lauf 2

Nach Abschluss des zweiten Durchlaufs dieses Tests pingProbeHistoryTable enthält Sonden wie die in Tabelle 3.

Tabelle 3: Ergebnisse in pingProbeHistoryTable: Nach dem zweiten Ping-Test

pingProbeHistoryIndex

Ergebnis der Sondierung

26

Ergebnis der 11. Sondierung aus Lauf 2

27

Ergebnis der 12. Sondierung aus Lauf 2

28

Ergebnis der 13. Sondierung aus Lauf 2

29

Ergebnis der 14. Sondierung aus Lauf 2

30

Ergebnis der 15. Sondierung aus Lauf 2

Verlaufseinträge können auf zwei Arten aus der MIB gelöscht werden:

  • Es werden weitere Verlaufseinträge für einen bestimmten Test hinzugefügt, und die Anzahl der Verlaufseinträge überschreitet pingCtlMaxRows. Die ältesten Verlaufseinträge werden gelöscht, um Platz für die neuen Einträge zu schaffen.

  • Sie löschen den gesamten Test, indem pingCtlRowStatus Sie auf destroy.

Stoppen eines Ping-Tests

Um einen aktiven Test zu beenden, legen Sie pingCtlAdminStatus auf disabled. Um den Test zu beenden und seine pingCtlEntry, pingResultsEntry, und alle pingHistoryEntry Objekte aus der MIB zu entfernen, legen Sie pingCtlRowStatus auf destroy.

Interpretieren von Ping-Variablen

In diesem Abschnitt werden die Bereiche für die folgenden Variablen erläutert, die nicht explizit in der Ping-MIB angegeben sind:

  • pingCtlDataSize—Der Wert dieser Variablen stellt die Gesamtgröße der Nutzlast (in Byte) eines ausgehenden Sondenpakets dar. Diese Nutzlast enthält den Zeitstempel (8 Byte), der zum Timing des Tests verwendet wird. Dies stimmt mit der Definition von pingCtlDataSize (Maximalwert von 65.507) und der Standard-Ping-Anwendung überein.

    Wenn der Wert von pingCtlDataSize zwischen 0 und 8 liegt, wird er ignoriert und die Nutzlast beträgt 8 Byte (der Zeitstempel). Die Ping-MIB geht davon aus, dass alle Sonden zeitlich begrenzt sind, sodass die Nutzlast immer den Zeitstempel enthalten muss.

    Wenn Sie dem Paket beispielsweise zusätzliche 4 Byte Nutzlast hinzufügen möchten, müssen Sie den Wert auf 12 setzen pingCtlDataSize .

  • pingCtlDataFill—Die ersten 8 Bytes des Datensegments des Pakets sind für den Zeitstempel vorgesehen. Danach wird das Muster in der pingCtlDataFill Wiederholung verwendet. Das Standardmuster (wenn pingCtlDataFill nicht angegeben) ist (00, 01, 02, 03 ... FF, 00, 01, 02, 03 ... FF, ...).

  • pingCtlMaxRows– Der Maximalwert ist 255.

  • pingMaxConcurrentRequests– Der Maximalwert ist 500.

  • pingCtlTrapProbeFailureFilter and pingCtlTrapTestFailureFilter—Ein Wert von 0 für pingCtlTrapProbeFailureFilter oder pingCtlTrapTestFailureFilter ist durch die Ping-MIB nicht genau definiert. Wenn pingCtlTrapProbeFailureFilter der Wert 0 ist, pingProbeFailed werden unter keinen Umständen Traps für den Test generiert. Wenn pingCtlTrapTestFailureFilter der Wert 0 ist, pingTestFailed werden unter keinen Umständen Traps für den Test generiert.

Verwenden der Traceroute MIB für Remoteüberwachungsgeräte mit Junos OS

Ein Traceroute-Test nähert den Pfad an, den Pakete vom lokalen Host zum Remote-Host nehmen.

RFC 2925 ist die maßgebliche Beschreibung der Traceroute MIB im Detail und enthält die ASN.1 MIB-Definition der Traceroute MIB.

Starten eines Traceroute-Tests

Bevor Sie einen Traceroute-Test starten, konfigurieren Sie eine Traceroute-MIB-Ansicht. Dies ermöglicht SNMP-Anforderungen Set für tracerouteMIB. Um einen Test zu starten, erstellen Sie eine Zeile in traceRouteCtlTable und legen Sie traceRouteCtlAdminStatus sie auf enabled. Sie müssen mindestens Folgendes angeben, bevor Sie Folgendes festlegen traceRouteCtlAdminStatus : enabled

  • traceRouteCtlOwnerIndexSnmpAdminString

  • traceRouteCtlTestNameSnmpAdminString

  • traceRouteCtlTargetAddressInetAddress

  • traceRouteCtlRowStatusRowStatus

Für alle anderen Werte werden Standardwerte ausgewählt, sofern nicht anders angegeben. traceRouteCtlOwnerIndex und traceRouteCtlTestName als Index verwendet werden, werden ihre Werte als Teil der OID angegeben. Um eine Zeile zu erstellen, legen Sie sie auf createAndWait oder createAndGo auf eine Zeile festtraceRouteCtlRowStatus , die noch nicht vorhanden ist. Der Wert for activetraceRouteCtlRowStatus zeigt an, dass alle erforderlichen Informationen angegeben wurden und der Test beginnen kann; traceRouteCtlAdminStatus kann auf enabledgesetzt werden. Eine SNMP-Anforderung Set , die auf active festgelegt traceRouteCtlRowStatusist, schlägt fehl, wenn die erforderlichen Informationen in der Zeile nicht angegeben oder inkonsistent sind. Weitere Informationen zum Konfigurieren einer Ansicht finden Sie unter Festlegen von SNMP-Ansichten.

Es gibt zwei Möglichkeiten, einen Traceroute-Test zu starten:

Verwenden Sie mehrere PDUs

Sie können mehrere Set Anforderungs-PDUs (mehrere PDUs mit jeweils einem oder mehreren varbinds) verwenden und die folgenden Variablen in dieser Reihenfolge festlegen, um den Test zu starten:

  • traceRouteCtlRowStatus zu createAndWait

  • Alle geeigneten Testvariablen

  • traceRouteCtlRowStatus An active

    Das Junos-Betriebssystem überprüft nun, ob alle erforderlichen Informationen zum Ausführen eines Tests angegeben wurden.

  • traceRouteCtlAdminStatus An enabled

Verwenden einer einzelnen PDU

Sie können eine PDU mit einer einzelnen Set Anforderung (eine PDU mit mehreren varbinds) verwenden, um die folgenden Variablen zum Starten des Tests festzulegen:

  • traceRouteCtlRowStatus An createAndGo

  • Alle geeigneten Testvariablen

  • traceRouteCtlAdminStatus bis aktiviert

Überwachen eines laufenden Traceroute-Tests

Wenn traceRouteCtlAdminStatus erfolgreich auf enabled gesetzt wurde, wird Folgendes ausgeführt, bevor die Bestätigung der SNMP-Set-Anforderung an den Client zurückgesendet wird:

  • traceRouteResultsEntry wird erstellt, wenn es noch nicht vorhanden ist.

  • traceRouteResultsOperStatus wechselt zu aktiviert.

Weitere Informationen finden Sie in den folgenden Abschnitten:

traceRouteResultsTable

Während der Test ausgeführt wird, verfolgt diese traceRouteResultsTable den Status des Tests nach. Der Wert von traceRouteResultsOperStatus wird aktiviert, während der Test ausgeführt wird, und deaktiviert, wenn er beendet wurde.

Der Wert von traceRouteCtlAdminStatus bleibt aktiviert, bis Sie ihn auf disabled setzen. Um den Status des Tests abzurufen, müssen Sie daher traceRouteResultsOperStatus untersuchen.

Die traceRouteCtlFrequency-Variable kann verwendet werden, um viele Tests für einen traceRouteCtlEntry zu planen. Nachdem ein Test normal beendet wurde (Sie haben den Test nicht beendet) und traceRouteCtlFrequency die Anzahl der Sekunden verstrichen ist, wird der Test erneut gestartet, als ob Sie traceRouteCtlAdminStatus auf enabled gesetzt hätten. Wenn Sie zu einem beliebigen Zeitpunkt zwischen wiederholten Tests eingreifen (Sie legen traceRouteCtlAdminStatus auf disabled oder traceRouteCtlRowStatus auf notInService fest), wird die Wiederholungsfunktion deaktiviert, bis ein anderer Test gestartet wird und normal beendet wird. Der Wert 0 für traceRouteCtlFrequency gibt an, dass diese Wiederholungsfunktion nicht aktiv ist.

traceRouteResultsIpTgtAddr und traceRouteResultsIpTgtAddrType werden auf den Wert der aufgelösten Zieladresse festgelegt, wenn der Wert von traceRouteCtlTargetAddressType dns ist. Wenn ein Test erfolgreich gestartet wurde und traceRouteResultsOperStatus in "enabled" übergeht, geschieht Folgendes:

  • traceRouteResultsIpTgtAddr ist auf null-string festgelegt.

  • traceRouteResultsIpTgtAddrType ist auf unknown festgelegt.

traceRouteResultsIpTgtAddr und traceRouteResultsIpTgtAddrType werden erst festgelegt, wenn traceRouteCtlTargetAddress in eine numerische Adresse aufgelöst werden kann. Um diese Werte abzurufen, fragen Sie traceRouteResultsIpTgtAddrType nach einem anderen Wert als unbekannt ab, nachdem Sie traceRouteCtlAdminStatus erfolgreich auf enabled gesetzt haben.

Zu Beginn eines Tests wird traceRouteResultsCurHopCount mit traceRouteCtlInitialTtl und traceRouteResultsCurProbeCount mit 1 initialisiert. Jedes Mal, wenn ein Testergebnis ermittelt wird, erhöht sich traceRouteResultsCurProbeCount um 1. Während der Test ausgeführt wird, gibt der Wert von traceRouteResultsCurProbeCount den aktuell ausstehenden Test an, für den noch keine Ergebnisse ermittelt wurden.

Die traceRouteCtlProbesPerHop-Anzahl der Tests wird für jeden TTL-Wert (Time-to-Live) gesendet. Wenn das Ergebnis des letzten Tests für den aktuellen Hop ermittelt wird, wird traceRouteResultsCurHopCount um 1 erhöht, und traceRouteResultsCurProbeCount wird auf 1 zurückgesetzt, vorausgesetzt, dass der aktuelle Hop nicht der Zielhop ist.

Wenn dieser Test zu Beginn eines Tests zum ersten Mal ausgeführt wird, werden traceRouteCtlEntry, traceRouteResultsTestAttempts und traceRouteResultsTestSuccesses mit 0 initialisiert.

Am Ende jeder Testausführung wechselt traceRouteResultsOperStatus in disabled, und traceRouteResultsTestAttempts erhöht sich um 1. Wenn der Test beim Ermitteln des vollständigen Pfads zum Ziel erfolgreich war, wird traceRouteResultsTestSuccesses um 1 erhöht, und traceRouteResultsLastGoodPath wird auf die aktuelle Uhrzeit festgelegt.

traceRouteProbeResultsTable

Jeder Eintrag in traceRouteProbeHistoryTable wird durch fünf Variablen indiziert:

  • Die ersten beiden Variablen, traceRouteCtlOwnerIndex und traceRouteCtlTestName, sind die gleichen, die für traceRouteCtlTable und zum Identifizieren des Tests verwendet werden.

  • Die dritte Variable, traceRouteProbeHistoryIndex, ist ein Zähler, der bei 1 beginnt und bei FFFFFFFF umgebrochen wird. Die maximale Anzahl von Einträgen wird durch traceRouteCtlMaxRows begrenzt.

  • Die vierte Variable, traceRouteProbeHistoryHopIndex, gibt an, für welchen Hop dieser Test bestimmt ist (die tatsächliche Gültigkeitsdauer oder der TTL-Wert). Daher hat die erste traceRouteCtlProbesPerHop-Anzahl von Einträgen, die beim Start eines Tests erstellt werden, den Wert traceRouteCtlInitialTtl für traceRouteProbeHistoryHopIndex.

  • Die fünfte Variable, traceRouteProbeHistoryProbeIndex, ist der Test für den aktuellen Hop. Er reicht von 1 bis traceRouteCtlProbesPerHop.

Während ein Test läuft, wird die nächste Sonde gesendet, sobald ein Sondenergebnis ermittelt wurde. Es vergehen maximal traceRouteCtlTimeOut-Sekunden, bevor ein Test mit dem Status requestTimedOut markiert wird und der nächste Test gesendet wird. Es gibt nie mehr als eine ausstehende Sonde pro Traceroute-Test. Alle Testergebnisse, die nach einem Timeout für einen Test zurückgegeben werden, werden ignoriert.

Jede Sonde kann:

  • Ergebnis einer Antwort eines Hosts, der die Sonde bestätigt

  • Zeitüberschreitung ohne Antwort eines Hosts, der den Test bestätigt

  • Fehler beim Senden

Jeder Teststatus wird in traceRouteProbeHistoryTable aufgezeichnet, wobei traceRouteProbeHistoryStatus entsprechend festgelegt ist.

Sonden, die zu einer Antwort von einem Host führen, zeichnen die folgenden Daten auf:

  • traceRouteProbeHistoryResponse – Round-Trip-Zeit (RTT)

  • traceRouteProbeHistoryHAddrType – Der Typ von HAddr (nächstes Argument)

  • traceRouteProbeHistoryHAddr: Die Adresse des Hops

Für alle Sondierungen, unabhängig davon, ob eine Antwort für die Sondierung empfangen wird, wird Folgendes aufgezeichnet:

  • traceRouteProbeHistoryStatus: Was ist passiert und warum?

  • traceRouteProbeHistoryLastRC – Rückgabecodewert (RC) des ICMP-Pakets

  • traceRouteProbeHistoryTime: Zeitstempel, zu dem das Testergebnis ermittelt wurde

Wenn kein Test gesendet werden kann, wird traceRouteProbeHistoryResponse auf 0 festgelegt. Wenn bei einem Test ein Timeout auftritt, wird traceRouteProbeHistoryResponse auf die Differenz zwischen dem Zeitpunkt, zu dem das Timeout für den Test erkannt wurde, und dem Zeitpunkt, zu dem der Test gesendet wurde, festgelegt.

traceRouteHopsTable

Einträge in traceRouteHopsTable werden durch drei Variablen indiziert:

  • Die ersten beiden, traceRouteCtlOwnerIndex und traceRouteCtlTestName, sind die gleichen, die für traceRouteCtlTable verwendet werden und den Test identifizieren.

  • Die dritte Variable, traceRouteHopsHopIndex, gibt den aktuellen Hop an, der bei 1 beginnt (nicht traceRouteCtlInitialTtl).

Wenn ein Test gestartet wird, werden alle Einträge in traceRouteHopsTable mit dem angegebenen traceRouteCtlOwnerIndex und traceRouteCtlTestName gelöscht. Einträge in dieser Tabelle werden nur erstellt, wenn traceRouteCtlCreateHopsEntries auf true gesetzt ist.

Jedes Mal, wenn das erste Testergebnis für eine bestimmte TTL ermittelt wird, wird ein neuer traceRouteHopsEntry erstellt. Der neue Eintrag wird unabhängig davon erstellt, ob die erste Sondierung einen Host erreicht oder nicht. Der Wert von traceRouteHopsHopIndex wird für diesen neuen Eintrag um 1 erhöht.

HINWEIS:

Jedem traceRouteHopsEntry kann ein Wert für traceRouteHopsIpTgtAddress fehlen, wenn keine Antworten auf die Tests mit der angegebenen TTL vorhanden sind.

Jedes Mal, wenn ein Test einen Host erreicht, ist die IP-Adresse dieses Hosts im Testergebnis verfügbar. Wenn der Wert von traceRouteHopsIpTgtAddress des aktuellen traceRouteHopsEntry nicht festgelegt ist, wird der Wert von traceRouteHopsIpTgtAddress auf diese IP-Adresse festgelegt. Wenn der Wert von traceRouteHopsIpTgtAddress des aktuellen traceRouteHopsEntry mit der IP-Adresse übereinstimmt, ändert sich der Wert nicht. Wenn sich der Wert von traceRouteHopsIpTgtAddress des aktuellen traceRouteHopsEntry von dieser IP-Adresse unterscheidet, was auf eine Pfadänderung hinweist, wird ein neuer traceRouteHopsEntry erstellt mit:

  • traceRouteHopsHopIndex-Variable um 1 erhöht

  • traceRouteHopsIpTgtAddress auf die IP-Adresse festgelegt

    HINWEIS:

    Jedes Mal, wenn ein neuer TTL-Wert verwendet wird oder sich der Pfad ändert, wird traceRouteHopsTable ein neuer Eintrag für einen Test hinzugefügt. Daher kann die Anzahl der Einträge für einen Test die Anzahl der verschiedenen verwendeten TTL-Werte überschreiten.

Wenn ein Testergebnis ermittelt wird, erhöht sich der Wert traceRouteHopsSentProbes des aktuellen traceRouteHopsEntry um 1. Wenn ein Sondierungsergebnis ermittelt wird und die Sondierung einen Host erreicht, geschieht Folgendes:

  • Der Wert traceRouteHopsProbeResponses des aktuellen traceRouteHopsEntry wird um 1 erhöht.

  • Die folgenden Variablen werden aktualisiert:

    • traceRouteResultsMinRtt – Minimale Roundtrip-Zeit

    • traceRouteResultsMaxRtt – Maximale Roundtrip-Zeit

    • traceRouteResultsAverageRtt: Durchschnittliche Roundtrip-Zeit

    • traceRouteResultsRttSumOfSquares: Summe der Quadrate der Umlaufzeiten

    • traceRouteResultsLastGoodProbe: Zeitstempel der letzten Antwort

      HINWEIS:

      Nur Sonden, die einen Host erreichen, wirken sich auf die Werte für die Umlaufzeit aus.

Fallen generieren

Um einen Trap zu generieren, muss ein entsprechendes Bit von traceRouteCtlTrapGeneration festgelegt werden. Außerdem müssen Sie eine Trap-Gruppe konfigurieren, um Remotevorgänge zu empfangen. Überfüllungen werden unter den folgenden Bedingungen generiert:

  • traceRouteHopsIpTgtAddress des aktuellen Tests unterscheidet sich von dem letzten Test mit demselben TTL-Wert (traceRoutePathChange).

  • Ein Pfad zum Ziel konnte nicht ermittelt werden (traceRouteTestFailed).

Es wurde ein Pfad zum Ziel ermittelt (traceRouteTestCompleted).

Informationen zum Konfigurieren einer Trap-Gruppe für den Empfang von Remote-Vorgängen finden Sie unter Konfigurieren von SNMP-Trap-Gruppen und Übersicht über SNMP-Remote-Vorgänge.

Überwachen des Abschlusses des Traceroute-Tests

Wenn ein Test abgeschlossen ist, traceRouteResultsOperStatus wechselt er von enabled zu . disabled Dieser Übergang tritt in den folgenden Situationen auf:

  • Der Test wird erfolgreich beendet. Ein Testergebnis zeigt an, dass das Ziel erreicht wurde. In diesem Fall ist der aktuelle Hop der letzte Hop. Die restlichen Sonden für diesen Hop werden gesendet. Wenn das letzte Testergebnis für den aktuellen Hop ermittelt wurde, endet der Test.

  • traceRouteCtlMaxTtl Schwellenwert überschritten wird. Das Ziel wird nie erreicht. Der Test endet, nachdem die Anzahl der Sonden mit einem TTL-Wert gesendet wurde. traceRouteCtlMaxttl

  • traceRouteCtlMaxFailures Schwellenwert überschritten wird. Die Anzahl der aufeinanderfolgenden Tests, die mit dem Status requestTimedOut enden, überschreitet traceRouteCtlMaxFailures.

  • Sie beenden den Test. Sie setzen traceRouteCtlAdminStatusdisabled oder löschen die Zeile, indem traceRouteCtlRowStatus Sie auf destroysetzen.

  • Sie haben den Traceroute-Test falsch konfiguriert. Ein Wert oder eine Variable, den Sie angegeben traceRouteCtlTable haben, ist falsch und lässt das Senden eines einzelnen Tests nicht zu. Aufgrund der Art der Daten konnte dieser Fehler erst beim Start des Tests festgestellt werden. Das heißt, bis nach dem traceRouteResultsOperStatus Übergang zu enabled. In diesem Fall wird ein Eintrag mit traceRouteProbeHistoryTabletraceRouteProbeHistoryStatus dem entsprechenden Fehlercode hinzugefügt.

Wenn traceRouteCtlTrapGeneration richtig eingestellt ist, wird entweder der oder traceRouteTestCompleted -traceRouteTestFailedTrap generiert.

Sammeln von Traceroute-Testergebnissen

Sie können entweder traceRouteResultsOperStatus abfragen, um herauszufinden, wann der Test abgeschlossen ist, oder anfordern, dass ein Trap gesendet wird, wenn der Test abgeschlossen ist. Weitere Informationen zu traceResultsOperStatus finden Sie unter traceRouteResultsTable. Weitere Informationen zu Traceroute-MIB-Traps finden Sie im Abschnitt Generieren von Traps unter Überwachen eines laufenden Traceroute-Tests.

Statistiken werden pro Hop berechnet und dann in traceRouteHopsTable gespeichert. Dazu gehören die folgenden Punkte für jeden Hop:

  • traceRouteHopsIpTgtAddressType: Adresstyp des Hosts an diesem Hop

  • traceRouteHopsIpTgtAddress: Adresse des Hosts an diesem Hop

  • traceRouteHopsMinRtt: Minimale Round-Trip-Zeit

  • traceRouteHopsMaxRtt: Maximale Round-Trip-Zeit

  • traceRouteHopsAverageRtt: Durchschnittliche Roundtrip-Zeit

  • traceRouteHopsRttSumOfSquares: Summe der Quadrate von Round-Trip-Zeiten

  • traceRouteHopsSentProbes: Anzahl der Versuche, Sonden zu senden

  • traceRouteHopsProbeResponses: Anzahl der empfangenen Antworten

  • traceRouteHopsLastGoodProbe – Zeitstempel der letzten Antwort

Sie können auch traceRouteProbeHistoryTable konsultieren, um ausführlichere Informationen zu den einzelnen Tests zu erhalten. Der für traceRouteProbeHistoryTable verwendete Index beginnt bei 1, wechselt zu 0xFFFFFFFF und wird wieder auf 1 umgebrochen.

Nehmen Sie zum Beispiel Folgendes an:

  • traceRouteCtlMaxRows ist 10.

  • traceRouteCtlProbesPerHop ist 5.

  • Es sind acht Sprünge zum Ziel (das Ziel ist Nummer acht).

  • Jeder gesendete Test führt zu einer Antwort von einem Host (die Anzahl der gesendeten Tests ist nicht durch traceRouteCtlMaxFailures begrenzt).

Bei diesem Test werden 40 Sonden gesendet. Am Ende des Tests würde traceRouteProbeHistoryTable einen Verlauf von Tests wie in . Tabelle 4

Tabelle 4: traceRouteProbeHistoryTable

HistoryIndex (englisch)

HistoryHopIndex

HistoryProbeIndex

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

Beenden eines Traceroute-Tests

Um einen aktiven Test zu beenden, legen Sie traceRouteCtlAdminStatus auf disabled. Um einen Test zu stoppen und seine , traceRouteResultsEntry, traceRouteProbeHistoryEntryund traceRouteProbeHistoryEntry Objekte traceRouteCtlEntryaus der MIB zu entfernen, legen Sie traceRouteCtlRowStatus auf destroy.

Interpretieren von Traceroute-Variablen

Dieses Thema enthält Informationen zu den Bereichen für die folgenden Variablen, die nicht explizit in der Traceroute-MIB angegeben sind:

  • traceRouteCtlMaxRows—Der Maximalwert für traceRouteCtlMaxRows ist 2550. Dies stellt die maximale TTL (255) multipliziert mit der maximalen TTL für traceRouteCtlProbesPerHop (10) dar. Daher bietet die traceRouteProbeHistoryTable Aufnahme eines vollständigen Tests bei den Maximalwerten für einen traceRouteCtlEntry. In der Regel werden die Maximalwerte nicht verwendet und die traceRouteProbeHistoryTable ist in der Lage, die vollständige Historie für viele Tests für dasselbe traceRouteCtlEntryunterzubringen.

  • traceRouteMaxConcurrentRequests– Der Maximalwert ist 50. Wenn ein Test ausgeführt wird, hat er eine ausstehende Sonde. traceRouteMaxConcurrentRequests Stellt die maximale Anzahl von Traceroute-Tests dar, die den Wert enabled.traceRouteResultsOperStatus Jeder Versuch, einen Test mit ausgeführten Tests zu starten, führt dazu, dass ein Test traceRouteMaxConcurrentRequests erstellt wird, der traceRouteProbeHistoryStatus auf festgelegt maxConcurrentLimitReached ist, und dieser Test wird sofort beendet.

  • traceRouteCtlTable—Die maximal zulässige Anzahl von Einträgen in dieser Tabelle beträgt 100. Jeder Versuch, einen 101. Eintrag zu erstellen, führt zu einer BAD_VALUE Meldung für SNMPv1 und einer RESOURCE_UNAVAILABLE Meldung für SNMPv2.

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Feature Explorer, um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Release
Beschreibung
17.2X75-D100
Ab Junos OS Version 17.2X75-D100 müssen Sie RPM konfigurieren, bevor Sie einen ICMP-Ping starten.