AUF DIESER SEITE
Informationen zum Abrufen von Sitzungsinformationen für Firewalls der SRX-Serie
Anzeigen globaler Sitzungsparameter für alle Services Gateways der SRX-Serie
Anzeigen einer Zusammenfassung der Sitzungen für Services Gateways der SRX-Serie
Anzeigen von Sitzungs- und Datenflussinformationen zu Sitzungen für Services Gateways der SRX-Serie
Informationen in Sitzungsprotokolleinträgen für Services Gateways der SRX-Serie
Überwachen von Sicherheitsflusssitzungen
In diesem Thema werden Informationen zum Überwachen, Anzeigen und Überprüfen von Schemasitzungen mithilfe von Befehlen für den Betriebsmodus behandelt. So können Sie debuggen, ohne Ihre laufende Konfiguration bestätigen oder ändern zu müssen.
Überwachen von Sicherheitsablaufsitzungen – Übersicht
Mit Junos OS können Sie die Überwachung von Flow-Sitzungen mithilfe von Befehlen für den Betriebsmodus konfigurieren und starten. So können Sie debuggen, ohne Ihre laufende Konfiguration bestätigen oder ändern zu müssen. Dieser Ansatz kann besonders nützlich sein, wenn Sie den Status Ihres Geräts nicht ändern möchten, indem Sie die Konfiguration zum Aktivieren von Ablaufverfolgungsoptionen festlegen.
Um die Überwachung von Flow-Sitzungen zu konfigurieren, müssen Sie Flow-Filter definieren, die Ausgabedatei angeben und die Überwachung starten. Die Überwachung von Flow-Sitzungen wird erst gestartet, wenn ein Filter (mindestens einer) und eine Ausgabedatei angegeben sind. Außerdem löst das Definieren der Filter selbst keine Überwachung aus. Sie müssen die monitor security flow start
Befehle and monitor security flow stop
explizit verwenden, um die Überwachung zu aktivieren bzw. zu deaktivieren.
Definieren von Flow-Filtern: Definieren Sie die Flow-Sitzungen, die Sie überwachen möchten, mithilfe von Kombinationen von Übereinstimmungskriterien, z. B. Quelladresse, Zieladresse, Quellport, Zielport, IP-Protokollnummer, Name der ein- oder ausgehenden Schnittstelle und der Name des logischen Systems. Sie können Filter mit dem
clear monitor security flow filter
Befehl löschen.Anmerkung:Im Gegensatz zu Filtern, die im Konfigurationsmodus definiert sind, werden Filter, die mit Befehlen für den Betriebsmodus definiert wurden, gelöscht, wenn Sie Ihr System neu starten.
Geben Sie die Ausgabedatei an: Erstellen Sie eine Ausgabedatei, in der die Informationen zur Überwachung des Sicherheitsdatenflusses gespeichert werden sollen. Diese Datei wird im
/var/log/
Verzeichnis gespeichert. Sie können den Inhalt dieser Datei anzeigen, indem Sie denshow log filename
Befehl verwenden. Verwenden Sie den Befehl, um diemonitor security flow file
Eigenschaften der Ausgabedatei anzugeben, z. B. die maximale Größe, die maximale Anzahl und den Typ.Überwachung starten: Verwenden Sie den Befehl, um die
monitor security flow start
Überwachung zu starten. Sobald die Überwachung startet, wird der Datenverkehr, der den Filtern entspricht, in der angegebenen Ausgabedatei im/var/log/
Verzeichnis gespeichert. Das basic-datapath-Flag ist das Standardflag und wird aktiviert, wenn die Überwachung beginnt.Verwenden Sie den Befehl, um die
monitor security flow stop
Überwachung zu beenden. Sobald die Überwachung beendet ist, wird das Flag basic-datapath gelöscht.Monitoring-Flow-Informationen anzeigen: Verwenden Sie den
show monitoring security flow
Befehl, um Details zum Monitoring-Vorgang anzuzeigen.
Sie können die Überwachung und das Debuggen von Datenflusssitzungen mithilfe der Konfigurationsanweisungen "Überwachungsbetriebsmodus" und "Ablaufverfolgungsoptionen" konfigurieren. Diese beiden Vorgänge können nicht parallel ausgeführt werden. Wenn Sie die Sicherheits-Flow-Überwachung aktivieren, wird die Flow-Trace-Optionssitzung blockiert, und wenn die Flow-Traceoptions-Sitzung ausgeführt wird, wird die Überwachung der Flow-Sitzung blockiert.
Informationen zum Abrufen von Sitzungsinformationen für Firewalls der SRX-Serie
Sie können Informationen zu den auf Ihrem Gerät aktiven Sitzungen und Paketflüssen abrufen, einschließlich detaillierter Informationen zu bestimmten Sitzungen. (Die Firewall der SRX-Serie zeigt auch Informationen zu fehlgeschlagenen Sitzungen an.) Sie können diese Informationen anzeigen, um Aktivitäten zu beobachten und zu Debugging-Zwecken. Sie können z. B. den Befehl show security flow session verwenden:
So zeigen Sie eine Liste der eingehenden und ausgehenden IP-Datenströme, einschließlich der Dienste an
So zeigen Sie die Sicherheitsattribute an, die einem Datenfluss zugeordnet sind, z. B. die Richtlinien, die für Datenverkehr gelten, der zu diesem Datenfluss gehört
So zeigen Sie den Sitzungstimeoutwert an, wann die Sitzung aktiv wurde, wie lange sie aktiv war und ob in der Sitzung aktiver Datenverkehr vorhanden ist
Wenn eine Schnittstellen-NAT konfiguriert ist und Sitzungen mit der NAT unter Verwendung dieser Schnittstellen-IP-Adresse eingerichtet werden, werden die mit NAT eingerichteten Sitzungen bei jeder Änderung der Schnittstellen-IP-Adresse aktualisiert, und neue Sitzungen werden mit einer neuen IP-Adresse eingerichtet. Dies können Sie mit dem show security flow session
CLI-Befehl überprüfen.
Sitzungsinformationen können auch protokolliert werden, wenn eine entsprechende Richtlinienkonfiguration die Protokollierungsoption enthält. Für das Flow-Sitzungsprotokoll auf allen Firewalls der SRX-Serie wurde die Richtlinienkonfiguration verbessert. Informationen über den Schnittstellenparameter für eingehende Pakete im Sitzungsprotokoll für session-init und session-close sowie für den Fall, dass eine Sitzung von einer Richtlinie oder von der Anwendungsfirewall verweigert wird, werden bereitgestellt, um die Einhaltung der Common Criteria (CC) Medium Robustness Protection Profiles (MRPP) zu gewährleisten:
Richtlinienkonfiguration – So konfigurieren Sie die Richtlinie für die Sitzung, für die Sie Übereinstimmungen als Protokoll protokollieren möchten, oder session-close um Sitzungen im Syslog session-init aufzuzeichnen:
set security policies from-zone untrustZone to-zone trust zone policy policy13 match source-address extHost1
set security policies from-zone untrustZone to-zone trustZone policy policy13 match application junos-ping
set security policies from-zone untrustZone to-zone trustZone policy policy13 then permit
set security policies from-zone untrustZone to-zone trustZone policy policy13 then log session-init
set security policies from-zone untrustZone to-zone trustZone policy policy13 then log session-close
Example : Die Flow-Übereinstimmungsrichtlinie13 zeichnet die folgenden Informationen im Protokoll auf:
<14>1 2010-09-30T14:55:04.323+08:00 mrpp-srx550-dut01 RT_FLOW - RT_FLOW_SESSION_CREATE [junos@2626.192.0.2.1.40 source-address="192.0.2.1" source-port="1" destination-address="198.51.100.12" destination-port="46384" service-name="icmp" nat-source-address="192.0.2.1" nat-source-port="1" nat-destination-address="198.51.100.12" nat-destination-port="46384" src-nat-rule-name="Keine" dst-nat-rule-name="Keine" protocol-id="1" policy-name="policy1" source-zone-name="trustZone" destination-zone-name="untrustZone" session-id-32="41" packet-incoming-interface="ge-0/0/1.0"] Sitzung erstellt 192.0.2.1/1-->198.51.100.12/46384 icmp 192.0.2.1/1-->198.51.100.12/46384 Keine Keine 1 policy1 trustZone untrustZone 41 ge-0/0/1.0
<14>1 2010-09-30T14:55:07.188+08:00 mrpp-srx550-dut01 RT_FLOW - RT_FLOW_SESSION_CLOSE [junos@2626.192.0.2.1.40 reason="Antwort erhalten" source-address="192.0.2.1" source-port="1" destination-address="198.51.100.12" destination-port="46384" service-name="icmp" nat-source-address="192.0.2.1" nat-source-port="1" nat-destination-address="198.51.100.12" nat-destination-port="46384" src-nat-rule-name="Keine" dst-nat-rule-name="Keine" protocol-id="1" policy-name="policy1" source-zone-name="trustZone" destination-zone-name="untrustZone" session-id-32="41" packets-from-client="1" bytes-from-client="84" packets-from-server="1" bytes-from-server="84" elapsed-time="0" packet-incoming-interface="ge-0/0/1.0"] Sitzung geschlossen Antwort erhalten: 192.0.2.1/1-->198.51.100.12/46384 ICMP 192.0.2.1/1-->198.51.100.12/46384 Keine Keine 1 policy1 trustZone untrustZone 41 1(84) 1(84) 0 ge-0/0/1.0
Anzeigen globaler Sitzungsparameter für alle Services Gateways der SRX-Serie
Zweck
Abrufen von Informationen zu konfigurierten Parametern, die für alle Schemata oder Sitzungen gelten.
Aktion
Geben Sie den folgenden Befehl ein, um Sitzungsinformationen in der CLI anzuzeigen:
user@host# show security flow
Bedeutung
Der show security flow
Konfigurationsbefehl zeigt die folgenden Informationen an:
allow-dns-reply
- Gibt an, ob nicht übereinstimmende eingehende DNS-Antwortpakete (Domain Name System) zulässig sind.route-change-timeout
– Wenn diese Option aktiviert ist, wird der Sitzungs-Timeout-Wert angezeigt, der bei einer Routenänderung zu einer nicht vorhandenen Route verwendet werden soll.tcp-mss
- Zeigt die aktuelle Konfiguration für den Wert für die maximale TCP-Segmentgröße an, der für alle TCP-Pakete für den Netzwerkverkehr verwendet werden soll.tcp-session
: Zeigt alle konfigurierten Parameter an, die Sitzungsparameter steuern.syn-flood-protection-mode
– Zeigt den SYN-Proxy-Modus an.
Anzeigen einer Zusammenfassung der Sitzungen für Services Gateways der SRX-Serie
Zweck
Bestimmen Sie die Arten von Sitzungen auf Ihrem Gerät, wie viele von jeder Art vorhanden sind (z. B. die Anzahl der Unicast- und Multicastsitzungen), die Anzahl der fehlgeschlagenen Sitzungen, die Anzahl der derzeit verwendeten Sitzungen und die maximale Anzahl von Sitzungen, die das Gerät unterstützt. Mit diesem Befehl werden auch die Details der aktuell verwendeten Sitzungen angezeigt. Zum Beispiel gültige Sitzungen, ausstehende Sitzungen, ungültige Sitzungen und Sitzungen in anderen Status.
Aktion
Geben Sie den folgenden CLI-Befehl ein, um Sitzungszusammenfassungsinformationen in der CLI anzuzeigen:
user@host> show security flow session summary
Anzeigen von Sitzungs- und Datenflussinformationen zu Sitzungen für Services Gateways der SRX-Serie
Zweck
Zeigen Sie Informationen zu allen Sitzungen auf Ihrem Gerät an, einschließlich der Sitzungs-ID, des virtuellen Systems, zu dem die Sitzung gehört, des NAT-Quellpools (Network Address Translation) (falls Quell-NAT verwendet wird), des konfigurierten Zeitüberschreitungswerts für die Sitzung und ihrer Standardzeitüberschreitung sowie der Startzeit der Sitzung und der Zeit, in der die Sitzung aktiv war. Das Display zeigt auch alle Standard-Datenflussinformationen an, einschließlich der Richtung des Datenstroms, der Quelladresse und des Ports, der Zieladresse und des Ports, des IP-Protokolls und der für die Sitzung verwendeten Schnittstelle.
Aktion
Geben Sie den folgenden Befehl ein, um Sitzungsflussinformationen in der CLI anzuzeigen:
user@host> show security flow session
Anzeigen von Sitzungs- und Datenflussinformationen zu einer bestimmten Sitzung für Services Gateways der SRX-Serie
Zweck
Wenn Sie die Sitzungs-ID kennen, können Sie alle Sitzungs- und Flow-Informationen für eine bestimmte Sitzung und nicht für alle Sitzungen anzeigen.
Aktion
Geben Sie den folgenden Befehl ein, um Informationen zu einer bestimmten Sitzung in der CLI anzuzeigen:
user@host> show security flow session session-identifier 40000381
Verwenden von Filtern zum Anzeigen von Sitzungs- und Datenflussinformationen für Services Gateways der SRX-Serie
Zweck
Sie können Flow- und Sitzungsinformationen zu einer oder mehreren Sitzungen anzeigen, indem Sie einen Filter als Argument für den show security flow session
Befehl angeben. Sie können die folgenden Filter verwenden: application, destination-port, destination-prefix, family, idp, interface, nat, protocol, resource-manager, session-identifier, source-port, source-prefix und tunnel. Das Gerät zeigt die Informationen für jede Sitzung an, gefolgt von einer Zeile, die die Anzahl der gemeldeten Sitzungen angibt. Im Folgenden finden Sie ein Beispiel für den Befehl, der den Quellpräfixfilter verwendet.
Aktion
Geben Sie den folgenden Befehl ein, um Informationen zu ausgewählten Sitzungen mithilfe von Filtern in der CLI anzuzeigen:
user@host> show security flow session source-prefix 10/8
Informationen in Sitzungsprotokolleinträgen für Services Gateways der SRX-Serie
Sitzungsprotokolleinträge sind an die Richtlinienkonfiguration gebunden. Jedes Hauptsitzungsereignis – Erstellen, Schließen und Ablehnen – erstellt einen Protokolleintrag, wenn die steuernde Richtlinie die Protokollierung aktiviert hat.
Es werden verschiedene Felder für Sitzungserstellungs-, Sitzungsschließungs- und Sitzungsverweigerungsereignisse protokolliert, wie in Tabelle 1, Tabelle 2 und Tabelle 3 dargestellt. Der gleiche Feldname unter jedem Typ gibt an, dass die gleichen Informationen protokolliert werden, aber jede Tabelle ist eine vollständige Liste aller Daten, die für diesen Typ von Sitzungsprotokoll aufgezeichnet wurden.
In der folgenden Tabelle sind die Felder definiert, die in Sitzungsprotokolleinträgen angezeigt werden.
Field |
Description |
---|---|
|
Quell-IP-Adresse des Pakets, das die Sitzung erstellt hat. |
|
Quellport des Pakets, das die Sitzung erstellt hat. |
|
Ziel-IP-Adresse des Pakets, das die Sitzung erstellt hat. |
|
Zielport des Pakets, das die Sitzung erstellt hat. |
|
Anwendung, die das Paket durchlaufen hat (z. B. "junos-telnet" für Telnet-Datenverkehr während der Sitzung, die durch eine Richtlinie zulässig ist, die natives Telnet zulässt). |
|
Die übersetzte NAT-Quelladresse, falls NAT angewendet wurde; Andernfalls die Quelladresse wie oben. |
|
Der übersetzte NAT-Quellport, falls NAT angewendet wurde; Andernfalls der Quellport wie oben. |
|
Die übersetzte NAT-Zieladresse, falls NAT angewendet wurde; Andernfalls die Zieladresse wie oben. |
|
Der übersetzte NAT-Zielport, falls NAT angewendet wurde; Andernfalls der Zielport wie oben. |
|
Die Quell-NAT-Regel, die auf die Sitzung angewendet wurde (falls vorhanden). Wenn auch eine statische NAT konfiguriert und auf die Sitzung angewendet wird und eine Übersetzung der Quelladresse stattfindet, wird in diesem Feld der Name der statischen NAT-Regel angezeigt.* |
|
Die Ziel-NAT-Regel, die auf die Sitzung angewendet wurde (falls vorhanden). Wenn auch eine statische NAT konfiguriert und auf die Sitzung angewendet wird und eine Zieladressübersetzung stattfindet, wird in diesem Feld der Name der statischen NAT-Regel angezeigt.* |
|
Die Protokoll-ID des Pakets, das die Sitzung erstellt hat. |
|
Der Name der Richtlinie, die die Sitzungserstellung zugelassen hat. |
|
Die 32-Bit-Sitzungs-ID. |
* Beachten Sie, dass bei einigen Sitzungen möglicherweise sowohl Ziel- als auch Quell-NAT angewendet und die Informationen protokolliert werden. |
Ab Junos OS Version 12.1X47-D20 und Junos OS Version 17.3R1 enthält das Systemprotokoll Informationen zum NAT-Regeltyp. In der NAT-Regelsitzung werden zwei neue Felder vom Typ "src-nat-rule-type" und "dst-nat-rule-type" eingeführt.
Field |
Description |
---|---|
|
Der Grund, warum die Sitzung geschlossen wurde. |
|
Quell-IP-Adresse des Pakets, das die Sitzung erstellt hat. |
|
Quellport des Pakets, das die Sitzung erstellt hat. |
|
Ziel-IP-Adresse des Pakets, das die Sitzung erstellt hat. |
|
Zielport des Pakets, das die Sitzung erstellt hat. |
|
Anwendung, die das Paket durchlaufen hat (z. B. "junos-telnet" für Telnet-Datenverkehr während der Sitzung, die durch eine Richtlinie zulässig ist, die natives Telnet zulässt). |
|
Die übersetzte NAT-Quelladresse, falls NAT angewendet wurde; Andernfalls die Quelladresse wie oben. |
|
Der übersetzte NAT-Quellport, falls NAT angewendet wurde; Andernfalls der Quellport wie oben. |
|
Die übersetzte NAT-Zieladresse, falls NAT angewendet wurde; Andernfalls die Zieladresse wie oben. |
|
Der übersetzte NAT-Zielport, falls NAT angewendet wurde; Andernfalls der Zielport wie oben. |
|
Die Quell-NAT-Regel, die auf die Sitzung angewendet wurde (falls vorhanden). Wenn auch eine statische NAT konfiguriert und auf die Sitzung angewendet wird und eine Übersetzung der Quelladresse stattfindet, wird in diesem Feld der Name der statischen NAT-Regel angezeigt.* |
|
Die Ziel-NAT-Regel, die auf die Sitzung angewendet wurde (falls vorhanden). Wenn auch eine statische NAT konfiguriert und auf die Sitzung angewendet wird und eine Zieladressübersetzung stattfindet, wird in diesem Feld der Name der statischen NAT-Regel angezeigt.* |
|
Die Protokoll-ID des Pakets, das die Sitzung erstellt hat. |
|
Der Name der Richtlinie, die die Sitzungserstellung zugelassen hat. |
|
Die 32-Bit-Sitzungs-ID. |
|
Die Anzahl der Pakete, die vom Client im Zusammenhang mit dieser Sitzung gesendet wurden. |
|
Die Anzahl der Datenbytes, die vom Client im Zusammenhang mit dieser Sitzung gesendet wurden. |
|
Die Anzahl der Pakete, die vom Server im Zusammenhang mit dieser Sitzung gesendet wurden. |
|
Die Anzahl der Datenbytes, die vom Server im Zusammenhang mit dieser Sitzung gesendet wurden. |
|
Die gesamte verstrichene Sitzungszeit von der Freigabe bis zum Schließen (in Sekunden). |
|
Während der Sitzungserstellung können Sie den Grund für das Schließen der Sitzung als Die Sitzung wird mit dem Grund |
|
Die Sitzung wurde durch ein TCP-Reset-Paket geschlossen, das vom Client an sie gesendet wurde. |
|
Die Sitzung wurde durch ein TCP-Reset-Paket geschlossen, das vom Server an sie gesendet wurde. |
|
FIN von beiden Enden erhalten. |
|
Antwort, die für eine Paketanforderung empfangen wurde (z. B. ICMP req-reply). |
|
ICMP-Fehler empfangen. |
|
Die Sitzung wurde ausgealtert. |
|
ALG-Fehler haben die Sitzung beendet (z. B. maximale Grenze für RAS-Server (Remote Access Server) erreicht). |
|
HA-Meldung beendete die Sitzung. |
|
Es gab keinen Datenverkehr für die Sitzung, bevor die konfigurierte Ausalterungszeit erreicht wurde. |
|
Authentifizierung fehlgeschlagen. |
|
IDP hat die Sitzung aufgrund eines internen Fehlers des Sicherheitsmoduls (SM) geschlossen. |
|
Ein SYN-Proxyfehler beendete die Sitzung. |
|
Grund für das Fehlschlagen bei der Zuweisung einer kleineren Sitzung, die ursprüngliche Sitzung muss freigegeben werden. |
|
Die übergeordnete Sitzung ist geschlossen. |
|
Die Sitzung wurde von einer CLI gelöscht. |
|
CP NACK-Antwort erhalten. |
|
Durch das Löschen der CP-Bestätigung wurde die Sitzung geschlossen. |
|
Entsprechende Richtlinie, die zum Löschen markiert ist. |
|
Die Sitzung wurde aufgrund des Löschens der Weiterleitungssitzung geschlossen. |
|
Die Sitzung wurde geschlossen, da sich die Multicast-Route geändert hat. |
|
Der erste Pfad wird umgeleitet und die Sitzung wird neu erstellt. |
|
SPU hat eine ACK-Nachricht vom zentralen Punkt empfangen, konnte jedoch die DIP-Ressource nicht empfangen. Daher wird dieses Paket verworfen und die Sitzung geschlossen. |
|
Die Sitzung wurde aus allen anderen Gründen geschlossen (z. B. musste die PIM-Registrierung aktualisiert werden). |
|
Fehler bei der Erstellung von IKE-Pass-Through-Vorlagen. |
|
Die Sitzung wird gelöscht, da die IKE-Pass-Through-Vorlagensitzung kein untergeordnetes Element hat. |
|
Die ausstehende Sitzung wurde geschlossen, da der Timeout-Timer den Status "Ausstehend" erreicht hat. |
|
Die Sitzung wurde aus unbekannten Gründen geschlossen. |
* Beachten Sie, dass bei einigen Sitzungen möglicherweise sowohl Ziel- als auch Quell-NAT angewendet und die Informationen protokolliert werden. |
Field |
Description |
---|---|
|
Quell-IP-Adresse des Pakets, das versucht hat, die Sitzung zu erstellen. |
|
Quellport des Pakets, das versucht hat, die Sitzung zu erstellen. |
|
Ziel-IP-Adresse des Pakets, das versucht hat, die Sitzung zu erstellen. |
|
Zielport des Pakets, das versucht hat, die Sitzung zu erstellen. |
|
Anwendung, die das Paket zu durchlaufen versuchte. |
|
Die Protokoll-ID des Pakets, das versucht hat, die Sitzung zu erstellen. |
|
Der ICMP-Typ, wenn das verweigerte Paket ICMP-konfiguriert wurde; Andernfalls ist dieses Feld 0. |
|
Der Name der Richtlinie, die die Sitzungserstellung verweigert hat. |
Erweiterungen für die Fehlerbehandlung
Verbesserungen bei der Fehlererkennung und Fehlerbehandlung in Chassis Manager FPC
Die Funktion zur Erkennung und Verwaltung von Junos OS-Routing-Engine und Microkernel-Fehlern auf den Geräten SRX5400, SRX5600 und SRX5800 ermöglicht es der Routing-Engine und dem ukernel, den Verlauf aller gemeldeten Fehleraktivitäten und -indikatoren für verschiedene Schweregrade zu sammeln und zu speichern. Sie können konfigurieren, wie Fehler behandelt werden, und die Schweregrade und die Aktionen angeben, die ausgeführt werden sollen, wenn ein Fehler erkannt und ein Schwellenwert erreicht wird. Sie können Berichte für aufgetretene Fehler basierend auf gespeicherten Informationen generieren und anzeigen.
Ab Junos OS Version 15.1X49-D30 und Junos OS Version 17.3R1 werden Verbesserungen bei der Fehlererkennung bereitgestellt, die zusätzliche Fehler auf IOCs und SPCs erkennen und ein verbessertes Fehlermanagement ermöglichen. Diese Implementierung erweitert die Fehlererkennung und -verwaltung, die show chassis fpc error
im Thema behandelt wird.
Diese Funktion wird von Routing-Engine Version 1 nicht unterstützt.
- Fehlerbehandlung bei IOCs und SPCs
- Fehlererkennung und -management
- Prozesse zur Fehlererkennung
- Integration mit Chassis-Cluster
- Keilerkennung, Berichterstellung und -management
Fehlerbehandlung bei IOCs und SPCs
Ab Junos OS Version 15.1-X49-D50 und Junos OS Version 17.3R1 werden die Verbesserungen der Fehlerverwaltung auf IOC2- und IOC3-E/A-Karten (IOCs) und SPC2 Services Processing Cards (SPCs) unterstützt. Einige Erweiterungsfunktionen sind spezifisch für IOC2 und IOC3 oder SPC2-FPCs, und die Unterschiede werden in diesem Thema beschrieben.
Fehlererkennung und -management
Fehlermanagement beinhaltet:
Erkennen eines Fehlers.
Junos OS überwacht den Zustand der Gehäusekomponenten, um eine Reihe von Fehlerzuständen zu erkennen. Ein erkannter Fehler kann zu einem der vorkonfigurierten Fehlerschweregrade gehören:
Tödlich
Haupt
Kleiner
Identifizieren der zu ergreifenden Maßnahme.
Wenn ein Fehler auftritt, identifiziert das System die zu ergreifende Aktion basierend auf dem Schweregrad des Fehlers und den festgelegten und erreichten Schwellenwerten.
Ein FPC verwaltet eine Reihe von Fehlerindikatoren für jeden Fehlerschweregrad. Ein Fehlerindikatorensatz besteht aus einem Indikator, der über alle Fehler und Leistungsindikatoren für einzelne Fehler und Typen kumulativ ist. Es sind diese Informationen, die in der Routing-Engine gespeichert werden. Jeder Vorkommensindikator ist einem Schwellenwert für das Auftreten von Fehlern zugeordnet. Es gibt zwei Schwellenwerte: eine basierend auf dem Typ und die andere basierend auf dem Schweregrad.
Ausführen der Aktion.
Für diese Verbesserungen sind die vorkonfigurierten Aktionen, die Sie dem Gerät zuweisen können, wenn die Anzahl der Fehler der Routing-Engine für eine bestimmte Sicherheitsstufe den konfigurierten Schwellenwert erreicht, wie folgt:
Zurücksetzen
Offline
Alarm
Get-Zustand
Log
Seien Sie vorsichtig, wenn Sie die Fehlerbehandlungsaktionen für SPC2-Karten in der SRX5000 Gerätereihe festlegen. Bedenken Sie: Wenn Sie die Fehlerbehandlungsaktion auf einer SPC2-Karte auf "Offline" oder "Reset" setzen, startet der Chassis-Daemon (chassisd) alle FPC-Karten neu, sowohl SPCs als auch IOCs, wenn die Karte offline geschaltet wird oder ein Neustart erfolgt, d. h., das gesamte Gehäuse wird neu gestartet.
Prozesse zur Fehlererkennung
Mit diesen Erweiterungen werden die folgenden Fehlererkennungsprozesse ermöglicht und unterstützt:
Fehlerverwaltung in der Routing-Engine Version 2.
Fehlermanagement bei ukernel-Modulen auf SPC2-Karten.
Fehlermanagement auf den IOC2- und IOC3-Karten.
Der Treiber prüft die Erkennung von Keilbedingungen durch Datenpfadfehler.
Anmerkung:Die Erkennung des Keilzustands für den Trinity Offload Engine-Treiber wird nur auf SPC2-Karten unterstützt. Das heißt, es wird auf den IOC2- und IOC3-Karten nicht unterstützt.
Keilerkennung für Host-Loopback.
Anmerkung:Die Erkennung von Keilbedingungen für Host-Loopback wird nur auf SPC2-Karten unterstützt. Das heißt, es wird auf den IOC2- und IOC3-Karten nicht unterstützt.
Erkennung von Chassis Manager-Fabric-Fehlern.
Kontrollpfadfehlererkennung auf IOC2- und IOC3-Karten.
Integration mit Chassis-Cluster
Wenn in einer Chassis-Cluster-Umgebung zum ersten Mal ein Alarm aufgrund eines schwerwiegenden oder schwerwiegenden Fehlers ausgelöst wird, wird eine Umschaltung der Redundanzgruppe 1 (RG1) ausgelöst. Dies ist das Standardverhalten der Firewalls der SRX-Serie, und es bleibt unverändert. Mit diesen Verbesserungen wird der Alarm jedoch zur standardmäßigen Fehlerbehandlungsaktionsliste für einen schwerwiegenden Fehler hinzugefügt. Durch Hinzufügen eines Alarms zur Standardliste für die Fehlerbehandlung kann der Chassis-Alarm die RG1-Umschaltung auslösen, sobald der schwerwiegende Fehler erkannt wird.
Keilerkennung, Berichterstellung und -management
Eine Keilbedingung wird durch einen Fehler verursacht, der den Netzwerkverkehr blockiert.
Diese Funktion erkennt verschiedene Arten von Keilzuständen. Es:
Bestimmt, ob der Keil vorübergehend oder irreversibel ist.
Zeichnet die Keilbedingungen in Statistiken und Syslogs auf.
Warnt Netzwerkadministratoren vor irreversiblen Keilen, indem ein Chassis-Alarm an der Routing-Engine ausgelöst wird.
Überprüft, ob die folgenden Datenpfadfehlererkennungen für die IOC2-, IOC3- und SPC2-Karten aktiviert sind:
Keilerkennung für XM-Treiber
Keilerkennung für LU-Treiber
Keilerkennung für XL-Treiber
Keilerkennung für Zehennehmer (nur SPC2)
Keilerkennung für Host-Loopback (nur SPC2)
Alle Bedingungen des Datenpfadkeils werden innerhalb von 5 Sekunden erkannt und gemeldet. Jedes Fehlererkennungsmodul zeichnet den Status und die Historie seiner identifizierbaren Keilbedingungen auf und meldet diese.
Tabelle "Änderungshistorie"
Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.