Leistungsüberwachung in Echtzeit für SRX-Geräte
ZUSAMMENFASSUNG In diesem Abschnitt wird die Funktion zur Leistungsüberwachung in Echtzeit beschrieben, mit der Netzwerkbetreiber und deren Kunden die Leistung des Netzwerks zwischen zwei Endgeräten genau messen können.
RPM-Übersicht (SRX)
Mit dem RPM-Tool konfigurieren und senden Sie Probes an ein bestimmtes Ziel und überwachen die analysierten Ergebnisse, um Paketverlust, Roundtrip-Time und Jitter zu ermitteln.
MIT RPM können Sie die Servicelevel-Überwachung durchführen. Wenn RPM auf einem Gerät konfiguriert wird, berechnet das Gerät die Netzwerkleistung basierend auf Paketreaktionszeit, Jitter und Paketverlusten. Diese Werte werden je nach Konfiguration von HTTP-GET-Anforderungen (Hypertext Transfer Protocol), ICMP-Anforderungen (Internet Control Message Protocol) sowie TCP- und UDP-Anforderungen erfasst.
Dieser Abschnitt enthält die folgenden Themen:
- RPM-Sonden
- RPM-Tests
- Probe- und Testintervalle
- Jitter-Messung mit Hardware-Zeitstempel
- RPM-Statistik
- RPM-Schwellenwerte und Traps
- RPM für BGP-Überwachung
RPM-Sonden
Sie sammeln RPM-Statistiken, indem Sie Sondierungen an ein bestimmtes Probeziel senden, das durch eine IP-Adresse oder URL identifiziert wird. Wenn das Ziel die Probe empfängt, generiert es Antworten, die vom Gerät empfangen werden. Durch die Analyse der Transitzeiten zum und vom Remote-Server kann das Gerät Netzwerkleistungsstatistiken ermitteln.
Das Gerät sendet die folgenden Probe-Typen:
HTTP GET Request an einer Ziel-URL
HTTP GET-Anforderung für Metadaten an einer Ziel-URL
ICMP Echo Request an eine Zieladresse (Standard)
ICMP-Zeitstempelanfrage an eine Zieladresse
UDP-Ping-Pakete an ein Zielgerät
UDP-Zeitstempelanfragen an eine Zieladresse
TCP-Ping-Pakete an ein Zielgerät
Udp- und TCP-Probe-Typen erfordern, dass der Remote-Server als RPM-Empfänger konfiguriert ist, damit er Antworten auf die Sondierungen generiert.
Die ERGEBNISSE der RPM-Probe sind auch in Form von MIB-Objekten über das SNMP-Protokoll verfügbar.
Auf SRX300-, SRX320-, SRX340-, SRX1500-, SRX4600-Geräten und vSRX-Instanzen wird beim Konfigurieren grundlegender RPM-Probes die folgende Kombination der Konfigurationsparameter nicht unterstützt:
Quelladresse und Zielport und Next-Hop.
Durch die Konfiguration der RPM-Probe mit diesen Parametern wird verhindert, dass RPM-Probes an ein bestimmtes Probe-Ziel gesendet werden. Wir empfehlen, entweder den Quelladressen- oder Zielport zu konfigurieren und den nächsten Hop zur Konfiguration der RPM-Probe zu konfigurieren.
RPM-Tests
Jedes untersuchte Ziel wird im Verlauf eines Tests überwacht. Ein Test stellt eine Sammlung von Sondierungen dar, die in regelmäßigen Abständen, wie in der Konfiguration definiert, gesendet werden. Für jeden Test werden dann Statistiken zurückgegeben. Da ein Test eine Sammlung von Sondierungen ist, die über einen gewissen Zeitraum überwacht wurden, können Teststatistiken wie Standardabweichungen und Jitter berechnet und in die durchschnittliche Probe-Statistik aufgenommen werden.
Probe- und Testintervalle
Innerhalb eines Tests werden rpm-Sonden in regelmäßigen Abständen gesendet, die in Sekunden konfiguriert werden. Wenn die Gesamtzahl der Sondierungen gesendet wurde und die entsprechenden Antworten eingehen, ist der Test abgeschlossen. Sie können das Probe-Intervall für jeden Test manuell festlegen, um zu steuern, wie der RPM-Test durchgeführt wird.
Nachdem alle Probes für einen bestimmten Test gesendet wurden, beginnt der Test erneut. Die Zeit zwischen den Tests ist das Testintervall. Sie können das Testintervall manuell festlegen, um die RPM-Leistung zu optimieren.
Auf SRX340-Geräten wird der RPM-Serverbetrieb mit icmp nicht unterstützt. Der RPM-Server funktioniert einwandfrei mit TCP und UDP.
Jitter-Messung mit Hardware-Zeitstempel
Jitter ist der Unterschied in der relativen Transitzeit zwischen zwei aufeinander folgenden Sonden.
Sie können die folgenden RPM-Probes mit Zeitstempel versehen, um die Messung von Latenz oder Jitter zu verbessern:
ICMP-Ping
ICMP Ping-Zeitstempel
UDP-Ping
UDP-Ping-Zeitstempel
Das Gerät unterstützt hardwarebasierte Zeitstempel von UDP-Ping- und UDP-Ping-Zeitstempel-RPM-Probes nur, wenn der Zielport UDP-ECHO (Port 7) ist.
Der Zeitstempel erfolgt während des Weiterleitungsprozesses des Geräts, das die Probe stammt (der RPM-Client), nicht jedoch auf dem Remotegerät, das das Ziel der Probe ist (der RPM-Server).
Die unterstützten Kapselungen auf einem Gerät für den Zeitstempel sind Ethernet mit VLAN, synchrones PPP und Frame Relay. Die einzige logische Schnittstelle , die unterstützt wird, ist eine lt Services-Schnittstelle.
Die RPM-Probe-Generierung mit Hardware-Zeitstempel kann über das SNMP-Protokoll abgerufen werden.
RPM-Statistik
Am Ende jedes Tests erfasst das Gerät die Statistiken für Paket-Round-Trip-Zeit, Paketzu- und Ausgehende Zeiten (nur für ICMP-Zeitstempelsonden) und Sondierungen, wie in Tabelle 1 dargestellt.
RPM-Statistik |
Beschreibung |
|---|---|
| Hin- und Rückrunden | |
Minimale Hin- und Rücklaufzeit |
Kürzeste Round-Trip-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Maximale Hin- und Rücklaufzeit |
Längste Hin- und Rücklaufzeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Durchschnittliche Hin- und Rücklaufzeit |
Durchschnittliche Hin- und Rücklaufzeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Standardabweichung Hin- und Rücklaufzeit |
Standardabweichung der Round-Trip-Zeiten vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Jitter |
Unterschied zwischen der maximalen und der minimalen Round-Trip-Zeiten, wie sie im Verlauf des Tests gemessen wurden |
| Eingehende und ausgehende Zeiten (nur ICMP Timestamp Probes) | |
Minimale Ausgangszeit |
Kürzeste One-Way-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Testverlauf |
Maximale Eingangszeit |
Kürzeste One-Way-Zeit vom Remote-Server zum Gerät von Juniper Networks, gemessen im Verlauf des Tests |
Durchschnittliche Ausgangszeit |
Durchschnittliche One-Way-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Durchschnittliche Eingangszeit |
Durchschnittliche One-Way-Zeit vom Remote-Server zum Gerät von Juniper Networks, gemessen im Verlauf des Tests |
Ausgangszeit der Standardabweichung |
Standardabweichung der One-Way-Zeiten vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests |
Eingangszeit von Standardabweichungen |
Standardabweichung der One-Way-Zeiten vom Remote-Server zum Gerät von Juniper Networks, gemessen im Verlauf des Tests |
Ausgangs jitter |
Unterschied zwischen der maximalen und der minimalen Ausgangszeit, wie sie im Verlauf des Tests gemessen wurde |
Eingangs jitter |
Differenz zwischen der maximalen und der minimalen Eingangszeit, wie sie im Verlauf des Tests gemessen wurde |
| Probe-Anzahl | |
Gesendete Sondierungen |
Gesamtzahl der im Test gesendeten Sondierungen |
Empfangene Sondungsantworten |
Gesamtzahl der im Testverlauf eingehenden Sonddatenantworten |
Verlustanteil |
Prozentsatz der gesendeten Sondierungen, für die keine Antwort empfangen wurde |
RPM-Schwellenwerte und Traps
Sie können RPM-Schwellwerte für die Rundweg- und Eingangszeiten (Eingangs-) Zeiten und Ausgangszeiten (Outbound), die für jeden Probe gemessen werden, sowie für die Standardabweichungs- und Jitterwerte konfigurieren, die für jeden Test gemessen werden. Darüber hinaus können Sie Schwellenwerte für die Anzahl der aufeinanderfolgenden verlorenen Sondierungen innerhalb eines Tests und die Gesamtzahl der verlorenen Sondierungen innerhalb eines Tests konfigurieren.
Wenn das Ergebnis einer Probe oder eines Tests einen Schwellenwert überschreitet, generiert das Gerät eine Systemprotokollmeldung und sendet alle SNMP-Benachrichtigungen (Traps), die Sie konfiguriert haben.
Ab Junos OS Version 18.4R1 wird die Rpm-Testsonde (Echtzeitleistungsüberwachung) als fehlgeschlagen markiert, wenn das Ergebnis einer Probe oder eines Tests den Schwellenwert für den Paketverlust überschreitet. Die Testsonde schlägt auch fehl, wenn die Roundtrip-Time (RTT) den konfigurierten Schwellenwert überschreitet. Infolgedessen generiert das Gerät eine SNMP-Benachrichtigung (Trap) und markiert den RPM-Test als fehlgeschlagen. MIT RPM können Sie die Servicelevel-Überwachung durchführen. Wenn RPM auf einem Gerät konfiguriert wird, berechnet das Gerät die Netzwerkleistung basierend auf Paketreaktionszeit, Jitter und Paketverlusten.
RPM für BGP-Überwachung
Bei der Verwaltung von Peering-Netzwerken, die mit Border Gateway Protocol (BGP) verbunden sind, müssen Sie möglicherweise herausfinden, ob ein Pfad zwischen dem Gerät von Juniper Networks und seinen konfigurierten BGP-Nachbarn existiert. Sie können jeden BGP-Nachbarn manuell anpingen, um den Verbindungsstatus zu bestimmen, aber diese Methode ist nicht praktikabel, wenn auf dem Gerät eine große Anzahl von BGP-Nachbarn konfiguriert ist.
In dem Gerät können Sie RPM-Probes konfigurieren, um die BGP-Nachbarn zu überwachen und zu bestimmen, ob sie aktiv sind.
Richtlinien für die Konfiguration von RPM-Probes für IPv6-Geräte (SRX-Geräte)
Ab Junos OS Version 15.1X49-D10 können Sie RPM-Probes für IPv6 konfigurieren.
Beachten Sie die folgenden Richtlinien, wenn Sie IPv6-Adressen für RPM-Ziele oder -Server konfigurieren:
IPv6 RPM verwendet ICMPv6-Probe-Anforderungen. Sie können keine ICMP- oder ICMP-Zeitstempeltypen konfigurieren.
Für IPv6-Ziele, einschließlich VRF-Unterstützung, Spezifikation der Größe des Datenabschnitts von ICMPv6-Sondierungen, Datenmuster und Datenverkehrsklasse, wird nur Routing-Engine-basiertes RPM unterstützt.
Sie können Probes mit einer Kombination aus IPv4- und IPv6-Tests konfigurieren. Ein einzelner Test muss jedoch entweder IPv4 oder IPv6 sein.
Routing-Engine-basiertes RPM unterstützt keinen hardwarebasierten oder einseitigen hardwarebasierten Zeitstempel.
Wir empfehlen, die Anweisung auf Hierarchieebene
[edit services rpm]einzuschließenprobe-limit, um die Obergrenze für gleichzeitige Sondierungen auf 10 festzulegen. Höhere gleichzeitige Sondierungen können zu höheren Spitzen führen.SNMP-Set-Betrieb ist nur auf ICMP-Probes zulässig und wird für andere Probetypen nicht unterstützt.
In der folgenden Tabelle werden die speziellen IPv6-Adresspräfixe beschrieben, die in einer Probe nicht konfiguriert werden können.
IPV6-Adresstyp
IPV6-Adresspräfix
Unicast im Node-Bereich
::1/128 ist die Loopback-Adresse
::/128 ist die nicht spezifizierte Adresse
IPv4-zugeordnete Adressen
::FFFF:0:0/96
IPv4-kompatible Adressen
:<ipv4-Adresse>/96
Link-Scoped-Unicast
fe80::/10
Einzigartig-lokal
fc00::/7
Dokumentation Präfix
2001:db8::/32
6to4
2002::/16
6Bone
5f00::/8
ORCHID
2001:10::/28
Teredo
2001::/32
Standardroute
::/0
Multicast
ff00:/8
In Routing-Engine-basierten RPM können RtT-Spitzen (Route-Trip Time) aufgrund von Warteschlangenverzögerungen auftreten, selbst bei einem einzigen Test.
Da RPM möglicherweise TCP- und UDP-Ports für die Kommunikation zwischen dem RPM-Server und dem RPM-Client öffnen kann, empfehlen wir die Verwendung von Firewalls und DDoS-Angriffsfiltern (Distributed Denial of Service) zum Schutz vor Sicherheitsbedrohungen.
IPv6 RPM Probes (vSRX)
Ab Junos OS Version 15.1X49-D10 kann das auf der Route-Engine basierende RPM IPv6-Sondierungen senden und empfangen, um die Leistung in IPv6-Netzwerken zu überwachen.
Eine Probe-Anfrage ist ein Standard-IPv6-Paket mit entsprechenden TCP-, UDP- und ICMPv6-Headern. Eine Probeantwort ist auch ein Standard-IPv6-Paket mit entsprechenden TCP-, UDP- und ICMPv6-Headern. An das Standardpaket für RE-basiertes RPM wird kein RPM-Header angefügt. Ein IPv6-basierter RPM-Test wird zwischen einem IPv6-RPM-Client und einem IPv6-RPM-Server durchgeführt.
Sie können sowohl IPv4- als auch IPv6-Tests in derselben Probe haben.
Konfigurieren von IPv6-RPM-Probes (vSRX)
Ab Junos OS Version 15.1X49-D10 können Sie IPv6-Zieladressen für einen IPv6-basierten RPM-Probetest konfigurieren.
So konfigurieren Sie einen IPv6-RPM-Test:
Tuning RPM-Sonden (SRX-Geräte)
Nach der Konfiguration einer RPM-Probe können Sie Parameter festlegen, um Probe-Funktionen zu steuern, z. B. das Intervall zwischen Probes, die Gesamtzahl der gleichzeitigen Probes, die ein System verarbeiten kann, und die für jedes Probepaket verwendete Quelladresse.
So stimmen Sie DIE RPM-Sonden ab:
Überwachung von RPM-Sonden (SRX-Geräte)
Die RPM-Informationen umfassen die Rundlaufzeit, jitter und Standardabweichungswerte für jeden konfigurierten RPM-Test auf dem Gerät. Um diese RPM-Eigenschaften anzuzeigen, wählen Sie Fehlerbehebung>RPM> RPM in der J-Web-Benutzeroberfläche anzeigen, oder geben Sie im Konfigurationsmodus den show Folgenden Befehl ein:
[edit] user@host# run show services rpm probe-results
Zusätzlich zu den RPM-Statistiken für jeden RPM-Test zeigt die J-Web-Benutzeroberfläche die Roundtrip-Zeiten und den kumulativen Jitter grafisch an. Abbildung 1 zeigt Musterdiagramme für einen RPM-Test.
In Abbildung 1 werden die Rundlaufzeit- und Jitterwerte in Abhängigkeit von der Systemzeit dargestellt. Große Spitzen in Der Hin- und Rücklaufzeit oder beim Jitter deuten auf eine langsamere Ausgangs- (Ausgangs-) oder Eingangszeit für die zu diesem bestimmten Zeitpunkt gesendete Probe hin.
Tabelle 2 fasst die wichtigsten Ausgabefelder in RPM-Anzeigen zusammen.
Feld |
Werte |
Zusätzliche Informationen |
|---|---|---|
| Derzeit laufende Tests | ||
Diagramm |
Klicken Sie auf den Link Graph , um das Diagramm anzuzeigen (falls es nicht bereits angezeigt wird) oder das Diagramm für einen bestimmten Test zu aktualisieren. |
|
Besitzer |
Konfigurierter Besitzername des RPM-Tests. |
– |
Testname |
Konfigurierter Name des RPM-Tests. |
– |
Probe-Typ |
Typ der für den angegebenen Test konfigurierten RPM-Probe:
|
– |
Zieladresse |
IPv4-Adresse, IPv6-Adresse oder URL des Remoteservers, der durch den RPM-Test geprüft wird. |
– |
Quelladresse |
Explizit konfigurierte IPv4- oder IPv6-Quelladresse, die in den Probe-Paket-Headern enthalten ist. |
Wenn keine Quelladresse konfiguriert ist, verwenden die RPM-Probepakete die ausgehende Schnittstelle als Quelladresse, und das Feld Quelladresse ist leer. |
Mindest-RTT |
Kürzeste Round-Trip-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests. |
– |
Maximale RTT |
Längste Round-Trip-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests. |
– |
Durchschnittliche RTT |
Durchschnittliche Hin- und Rücklaufzeit vom Gerät von Juniper Networks zum Remote-Server, gemessen im Verlauf des Tests. |
– |
Standardabweichung RTT |
Standardabweichung der Hin- und Rücklaufzeiten vom Gerät von Juniper Networks zum Remote-Server, wie sie im Verlauf des Tests gemessen wurde. |
– |
Gesendete Sondierungen |
Gesamtzahl der Im Test gesendeten Sondierungen. |
– |
Verlustanteil |
Prozentsatz der gesendeten Sondierungen, für die keine Antwort empfangen wurde. |
– |
| Round-Trip-Time für eine Probe | ||
Proben |
Gesamtzahl der für den Datensatz verwendeten Sondierungen. |
Das Gerät von Juniper Networks speichert Aufzeichnungen der letzten 50 Probes für jeden konfigurierten Test. Diese 50 Sondierungen werden verwendet, um RPM-Statistiken für einen bestimmten Test zu erstellen. |
Frühestes Beispiel |
Systemzeit, wenn die erste Probe in der Probe empfangen wurde. |
– |
Neuestes Beispiel |
Systemzeit, wann die letzte Probe in der Probe empfangen wurde. |
– |
Mittelwert |
Durchschnittliche Hin- und Rücklaufzeit für die Probe mit 50 Probe. |
– |
Standardabweichung |
Standardabweichung der Round-Trip-Zeiten für die Probe mit 50 Probe. |
– |
Niedrigster Wert |
Kürzeste Round-Trip-Zeit vom Gerät zum Remote-Server, gemessen über die Probe mit 50 Probe. |
– |
Zeit der niedrigsten Stichprobe |
Systemzeit, wenn der niedrigste Wert in der Probe mit 50 Probe empfangen wurde. |
– |
Höchster Wert |
Längste Round-Trip-Zeit vom Gerät von Juniper Networks zum Remote-Server, gemessen in der Probe mit 50 Probe. |
– |
Zeit der höchsten Stichprobe |
Systemzeit, wenn der höchste Wert in der Probe mit 50 Probe empfangen wurde. |
– |
| Kumulativer Jitter für eine Probe | ||
Proben |
Gesamtzahl der für den Datensatz verwendeten Sondierungen. |
Das Gerät von Juniper Networks speichert Aufzeichnungen der letzten 50 Probes für jeden konfigurierten Test. Diese 50 Sondierungen werden verwendet, um RPM-Statistiken für einen bestimmten Test zu erstellen. |
Frühestes Beispiel |
Systemzeit, wenn die erste Probe in der Probe empfangen wurde. |
– |
Neuestes Beispiel |
Systemzeit, wann die letzte Probe in der Probe empfangen wurde. |
– |
Mittelwert |
Durchschnittlicher Jitter für die Probe mit 50 Probe. |
– |
Standardabweichung |
Standardabweichung der Jitter-Werte für die Probe mit 50 Probe. |
– |
Niedrigster Wert |
Kleinster Jitterwert, gemessen über die Probe mit 50 Probe. |
– |
Zeit der niedrigsten Stichprobe |
Systemzeit, wenn der niedrigste Wert in der Probe mit 50 Probe empfangen wurde. |
– |
Höchster Wert |
Höchster Jitter-Wert, gemessen über die Probe mit 50 Probe. |
– |
Zeit der höchsten Stichprobe |
Systemzeit, wenn der höchste Jitterwert in der Probe mit 50 Probe empfangen wurde. |
– |
Beispiel: Konfigurieren von grundlegenden RPM-Probes (SRX)
Dieses Beispiel zeigt, wie Sie grundlegende RPM-Sondierungen konfigurieren, um die Leistung zwischen zwei Netzwerkendpunkten zu messen.
Anforderungen
Bevor Sie beginnen:
Grundlegende Konnektivität herstellen.
Konfigurieren Sie Netzwerkschnittstellen. Siehe Schnittstellen-Benutzerhandbuch für Sicherheitsgeräte.
Übersicht
In diesem Beispiel konfigurieren Sie grundlegende Sondierungen für zwei RPM-Besitzer, customerA und customerB. Sie konfigurieren den RPM-Test als icmp-test für customerA mit einem Testintervall von 15 Sekunden und geben einen Probe-Typ als icmp-Ping-Timestamp, einen Probe-Zeitstempel und eine Zieladresse als 192.178.16.5 an. Anschließend konfigurieren Sie die RPM-Schwellenwerte und die entsprechenden SNMP-Traps, um Eingangszeiten von mehr als 3.000 Mikrosekunden abzufangen.
Dann konfigurieren Sie den RPM-Test als http-Test für customerB mit einem Testintervall von 30 Sekunden und geben einen Probetyp als http-get und eine Ziel-URL als http://customerB.net an. Schließlich konfigurieren Sie RPM-Schwellenwerte und entsprechende SNMP-Traps als Probe-Failure und Testausfall, um drei oder mehr aufeinanderfolgende verlorene Sondierungen und insgesamt verlorene Probes von 10 zu erfassen.
Auf SRX300-, SRX320-, SRX340-, SRX1500- und vSRX-Instanzen wird beim Konfigurieren grundlegender RPM-Probes die folgende Kombination der Konfigurationsparameter nicht unterstützt:
Quelladresse und Zielport und Next-Hop.
Durch die Konfiguration der RPM-Probe mit diesen Parametern wird verhindert, dass RPM-Probes an ein bestimmtes Probe-Ziel gesendet werden. Wir empfehlen, entweder den Quelladressen- oder Zielport zu konfigurieren und den nächsten Hop zur Konfiguration der RPM-Probe zu konfigurieren.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
set services rpm probe customerA test icmp-test probe-interval 15 set services rpm probe customerA test icmp-test probe-type icmp-ping-timestamp set services rpm probe customerA test icmp-test hardware-timestamp set services rpm probe customerA test icmp-test target address 192.178.16.5 set services rpm probe customerA test icmp-test thresholds ingress-time 3000 set services rpm probe customerA test icmp-test traps ingress-time-exceeded set services rpm probe customerB test http-test probe-interval 30 set services rpm probe customerB test http-test probe-type http-get set services rpm probe customerB test http-test target url http://customerB.net set services rpm probe customerB test http-test thresholds successive-loss 3 set services rpm probe customerB test http-test thresholds total-loss 10 set services rpm probe customerB test http-test traps probe-failure set services rpm probe customerB test http-test traps test-failure
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch .
So konfigurieren Sie grundlegende RPM-Probes:
Konfigurieren Sie das RPM.
[edit] user@host# edit services rpm
Konfigurieren Sie die RPM-Besitzer.
[edit services rpm] user@host# set probe customerA user@host# set probe customerB
Konfigurieren Sie den RPM-Test für customerA.
[edit services rpm] user@host# edit probe customerA user@host# set test icmp-test probe-interval 15 user@host# set test icmp-test probe-type icmp-ping-timestamp
Geben Sie einen Probe-Zeitstempel und eine Zieladresse an.
[edit services rpm probe customerA] user@host# set test icmp-test hardware-timestamp user@host# set test icmp-test target address 192.178.16.5
Konfigurieren Sie RPM-Schwellenwerte und entsprechende SNMP-Traps.
[edit services rpm probe customerA] user@host# set test icmp-test thresholds ingress-time 3000 user@host# set test icmp-test traps ingress-time-exceeded
Konfigurieren Sie den RPM-Test für customerB.
[edit] user@host# edit services rpm probe customerB user@host# set test http-test probe-interval 30
Geben Sie einen Probetyp und eine Ziel-URL an.
[edit services rpm probe customerB] user@host# set test http-test probe-type http-get user@host# set test http-test target url http://customerB.net
Konfigurieren Sie RPM-Schwellenwerte und entsprechende SNMP-Traps.
[edit services rpm probe customerB] user@host# set test http-test thresholds successive-loss 3 user@host# set test http-test thresholds total-loss 10 user@host# set test http-test traps probe-failure user@host# set test http-test traps test-failure
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den run show services rpm Befehl eingeben. Wenn in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit]
user@host# run show services rpm
probe customerA {
test icmp-test {
probe-type icmp-ping-timestamp;
target address 192.178.16.5;
probe-interval 15;
thresholds {
ingress-time 3000;
}
traps ingress-time-exceeded;
hardware-timestamp;
}
}
probe customerB {
test http-test {
probe-type http-get;
target url http://customerB.net;
probe-interval 30;
thresholds {
successive-loss 3;
total-loss 10;
}
traps [ probe-failure test-failure ];
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Überprüfung von RPM-Services
Zweck
Stellen Sie sicher, dass die RPM-Konfiguration innerhalb der erwarteten Werte liegt.
Aktion
Geben Sie im Betriebsmodus den show services rpm Befehl ein. Die Ausgabe zeigt die Werte an, die für RPM auf dem Gerät konfiguriert sind.
Überprüfung der RPM-Statistik
Zweck
Stellen Sie sicher, dass die RPM-Sondierungen funktionieren und dass die RPM-Statistiken innerhalb der erwarteten Werte liegen.
Aktion
Geben Sie im Betriebsmodus den show services rpm probe-results Befehl ein.
user@host> show services rpm probe-results
Owner: customerD, Test: icmp-test
Probe type: icmp-ping-timestamp
Minimum Rtt: 312 usec, Maximum Rtt: 385 usec, Average Rtt: 331 usec,
Jitter Rtt: 73 usec, Stddev Rtt: 27 usec
Minimum egress time: 0 usec, Maximum egress time: 0 usec,
Average egress time: 0 usec, Jitter egress time: 0 usec,
Stddev egress time: 0 usec
Minimum ingress time: 0 usec, Maximum ingress time: 0 usec,
Average ingress time: 0 usec, Jitter ingress time: 0 usec,
Stddev ingress time: 0 usec
Probes sent: 5, Probes received: 5, Loss percentage: 0
Owner: customerE, Test: http-test
Target address: 192.176.17.4, Target URL: http://customerB.net,
Probe type: http-get
Minimum Rtt: 1093 usec, Maximum Rtt: 1372 usec, Average Rtt: 1231 usec,
Jitter Rtt: 279 usec, Stddev Rtt: 114 usec
Probes sent: 3, Probes received: 3, Loss percentage: 0
Owner: Rpm-Bgp-Owner, Test: Rpm-Bgp-Test-1
Target address: 10.209.152.37, Probe type: icmp-ping, Test size: 5 probes
Routing Instance Name: LR1/RI1
Probe results:
Response received, Fri Oct 28 05:20:23 2005
Rtt: 662 usec
Results over current test:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Measurement: Round trip time
Minimum: 529 usec, Maximum: 662 usec, Average: 585 usec,
Jitter: 133 usec, Stddev: 53 usec
Results over all tests:
Probes sent: 5, Probes received: 5, Loss percentage: 0
Measurement: Round trip time
Minimum: 529 usec, Maximum: 662 usec, Average: 585 usec,
Jitter: 133 usec, Stddev: 53 usec
Konfigurieren Sie die gewünschten Traps mit dem set services rpm probe p1 test t1 traps Befehl.
Wenn eine Trap ausgelöst wird, können Sie diese mithilfe des Befehls in der Protokolldatei mit dem Namen Nachrichten show snmp log messages | match rmopd anzeigen.
| Mögliche Option |
Wertesatz |
|---|---|
| Ausgehender Jitter überschritten |
Überschreitung des Jitter-Schwellenwerts für die Ausgangszeit |
| egress-std-dev-exceeded |
Standardabweichungsschwellenwert für die Ausgangszeit überschritten |
| Ausgehende Zeit überschritten |
Schwellenwert für maximale Ausgangszeit überschritten |
| Eingangs-Jitter-überschritten |
Überschreitung des Jitter-Schwellenwerts in der Eingangszeit |
| ingress-std-dev-exceeded |
Standardabweichungsschwellenwert für die Eingangszeit überschritten |
| Probe-Fehler |
Aufeinanderfolgender Schwellenwert für Probeverlust erreicht |
| rtt-exceeded (rtt-exceeded) |
Schwelle für maximale Hin- und Rücklaufzeit überschritten |
| std-dev-exceeded |
Standardabweichungsschwellenwert für die Hin- und Rücklaufzeit überschritten |
| Testabschluss |
Test abgeschlossen |
| Testausfall |
Schwellenwert für den Gesamtverlust der Probe erreicht |
Beispiel: Konfigurieren von RPM mit TCP- und UDP-Probes (SRX-Geräte)
Dieses Beispiel zeigt, wie Sie RPM mithilfe von TCP- und UDP-Probes konfigurieren.
Anforderungen
Bevor Sie beginnen:
Grundlegende Konnektivität herstellen.
Konfigurieren Sie Netzwerkschnittstellen. Siehe Schnittstellen-Benutzerhandbuch für Sicherheitsgeräte.
Konfigurieren Sie den Probe-Besitzer, den Test und die spezifischen Parameter der RPM-Probe. Siehe Echtzeit-Leistungsüberwachung für SRX-Geräte.
Übersicht
In diesem Beispiel konfigurieren Sie sowohl den Host (Gerät A) als auch das Remotegerät (Gerät B), um als TCP- und UDP-Server zu fungieren. Sie konfigurieren eine Probe für customerC, die TCP-Pakete verwendet. Gerät B wird als RPM-Server für TCP- und UDP-Pakete konfiguriert und verwendet eine lt-Services-Schnittstelle als Zielschnittstelle und die Ports 50000 bzw. 50037.
Verwenden Sie die Testklassifizierung mit Vorsicht, da eine falsche Konfiguration dazu führen kann, dass Pakete unterbrochen werden.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
{device A}
set services rpm probe customerC test tcp-test probe-interval 5
set services rpm probe customerC test tcp-test probe-type tcp-ping
set services rpm probe customerC test tcp-test target address 192.162.45.6
set services rpm probe customerC test tcp-test destination-interface lt-0/0/0
set services rpm probe customerC test tcp-test destination-port 50000
{device B}
set services rpm probe-server tcp port 50000
set services rpm probe-server udp port 50037
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch .
So konfigurieren Sie RPM mithilfe von TCP- und UDP-Probes:
Konfigurieren Sie den RPM-Besitzer auf Gerät A.
{device A} [edit] user@host# edit services rpm user@host# set probe customerCKonfigurieren Sie den RPM-Test.
{device A} [edit services rpm] user@host# edit services rpm probe customerC user@host# set test tcp-test probe-interval 5Legen Sie den Probetyp fest.
{device A} [edit services rpm probe customerC] user@host# set test tcp-test probe-type tcp-pingGeben Sie die Zieladresse an.
{device A} [edit services rpm probe customerC] user@host# set test tcp-test target address 192.162.45.6Konfigurieren Sie die Zielschnittstelle.
{device A} [edit services rpm probe customerC] user@host# set test tcp-test destination-interface It-0/0/0Konfigurieren Sie Port 50000 als TCP-Port, an den die RPM-Probes gesendet werden.
{device A} [edit services rpm probe customerC] user@host# set test tcp-test destination-port 50000Konfigurieren Sie Gerät B so, dass es als TCP-Server über Port 50000 fungiert.
{device B} [edit] user@host# edit services rpm user@host# set probe-server tcp port 50000Konfigurieren Sie Gerät B so, dass es als UDP-Server über Port 50037 fungiert.
{device B} [edit services rpm] user@host# set probe-server udp port 50037
Ergebnisse
Bestätigen Sie ihre Konfiguration im Betriebsmodus, indem Sie den show services rpm Befehl eingeben. Wenn in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit]
user@host# show services rpm
probe customerC {
test tcp-test {
probe-type tcp-ping;
target address 192.162.45.6;
probe-interval 5;
destination-port 50000;
destination-interface lt-0/0/0.0;
}
}
probe-server {
tcp {
port 50000;
}
udp {
port 50037;
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .
Überprüfung
Überprüfung von RPM-Probe-Servern
Zweck
Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.
Stellen Sie sicher, dass das Gerät für den Empfang und die Übertragung von TCP- und UDP-RPM-Probes auf den richtigen Ports konfiguriert ist.
Aktion
Geben Sie im Betriebsmodus den show services rpm active-servers Befehl ein. Die Ausgabe zeigt eine Liste der Protokolle und entsprechenden Ports, für die das Gerät als RPM-Server konfiguriert ist.
user@host> show services rpm active-servers
Protocol: TCP, Port: 50000
Protocol: UDP, Port: 50037
Beispiel: Konfigurieren von RPM-Probes für die BGP-Überwachung
Dieses Beispiel zeigt, wie Sie RPM-Sondierungen konfigurieren, um BGP-Nachbarn zu überwachen.
Anforderungen
Bevor Sie beginnen:
Konfigurieren Sie die BGP-Parameter unter der RPM-Konfiguration, um RPM-Probes an BGP-Nachbarn zu senden. Siehe Echtzeit-Leistungsüberwachung für SRX-Geräte.
Verwenden Sie TCP- oder UDP-Probes, indem Sie sowohl den Probe-Server (Gerät von Juniper Networks) als auch den Probe-Empfänger (das Remotegerät) konfigurieren, um RPM-Probes am selben TCP- oder UDP-Port zu senden und zu empfangen. Siehe Echtzeit-Leistungsüberwachung für SRX-Geräte.
Übersicht
In diesem Beispiel geben Sie einen Hexadezimalwert an, den Sie für den Datenabschnitt der RPM-Probe als ABCD123 verwenden möchten. ( Er reicht von 1 bis 2048 Zeichen.) Sie geben die Datengröße der RPM-Probe als 1024 Bytes an. ( Der Wert reicht von 0 bis 65.507.)
Dann konfigurieren Sie den Zielport 50000 als den TCP-Port, an den die RPM-Probes gesendet werden. Sie geben die Anzahl der Probeergebnisse, die im Probeverlauf gespeichert werden sollen, als 25 an. (Er reicht von 0 bis 255, und der Standard ist 50.) Sie legen die Probeanzahl auf 5 und das Probe-Intervall auf 1 fest. (Die Probe-Anzahl reicht von 1 bis 15, und der Standard ist 1; und das Probe-Intervall liegt zwischen 1 und 255, und der Standard ist 3.) Anschließend geben Sie tcp-ping als Typ der Probe an, die im Rahmen des Tests gesendet werden soll.
Schließlich legen Sie das Testintervall auf 60 fest. Der Wert reicht für das Intervall zwischen den Tests von 0 bis 86.400 Sekunden.
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, kopieren Sie die Befehle, fügen Sie sie auf Hierarchieebene in die [edit] CLI ein, und geben Sie dann aus dem Konfigurationsmodus ein commit .
set services rpm bgp data-fill ABCD123 data-size 1024 set services rpm bgp destination-port 50000 history-size 25 set services rpm bgp probe-count 5 probe-interval 1 set services rpm bgp probe-type tcp-ping test-interval 60
Schritt-für-Schritt-Verfahren
Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch .
So konfigurieren Sie RPM-Probes zur Überwachung von BGP-Nachbarn:
Konfigurieren Sie rpm und BGP.
[edit] user@host# edit services rpm bgp
Geben Sie einen Hexadezimalwert an.
[edit services rpm bgp] user@host# set data-fill ABCD123
Geben Sie die Datengröße der RPM-Probe an.
[edit services rpm bgp] user@host# set data-size 1024
Konfigurieren Sie den Zielport.
[edit services rpm bgp] user@host# set destination-port 50000
Geben Sie die Anzahl der Sondierungen an.
[edit services rpm bgp] user@host# set history-size 25
Legen Sie die Probeanzahl und das Probe-Intervall fest.
[edit services rpm bgp] user@host# set probe-count 5 probe-interval 1
Geben Sie den Typ der Probe an.
[edit services rpm bgp] user@host# set probe-type tcp-ping
Hinweis:Wenn Sie den Probetyp nicht angeben, werden die Standard-ICMP-Probes gesendet.
Legen Sie das Testintervall fest.
[edit services rpm bgp] user@host# set test-interval 60
Ergebnisse
Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den run show services rpm Befehl eingeben. Wenn in der Ausgabe die beabsichtigte Konfiguration nicht angezeigt wird, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
[edit]
user@host# run show services rpm
bgp {
probe-type tcp-ping;
probe-count 5;
probe-interval 1;
test-interval 60;
destination-port 50000;
history-size 25;
data-size 1024;
data-fill ABCD123;
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .