Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Fehlerbehebung bei Sicherheitsgeräten

Fehlerbehebung bei der DNS-Namensauflösung in Logischen Systemsicherheitsrichtlinien (nur primäre Administratoren)

Problem

Beschreibung

Die Adresse eines Hostnamens in einem Adressbucheintrag, der in einer Sicherheitsrichtlinie verwendet wird, kann möglicherweise nicht richtig aufgelöst werden.

Ursache

Normalerweise werden Adressbucheinträge, die dynamische Hostnamen enthalten, für Geräte der SRX-Serie automatisch aktualisiert. Das TTL-Feld, das einem DNS-Eintrag zugeordnet ist, gibt die Zeit an, nach der der Eintrag im Richtliniencache aktualisiert werden soll. Sobald der TTL-Wert abläuft, aktualisiert das Gerät der SRX-Serie automatisch den DNS-Eintrag für einen Adressbucheintrag.

Wenn das Gerät der SRX-Serie jedoch keine Antwort vom DNS-Server erhalten kann (z. B. geht die DNS-Anfrage oder das Antwortpaket im Netzwerk verloren oder der DNS-Server kann keine Antwort senden), kann die Adresse eines Hostnamens in einem Adressbucheintrag möglicherweise nicht richtig aufgelöst werden. Dies kann dazu führen, dass der Datenverkehr abfällt, da keine Sicherheitsrichtlinien oder Sitzungsabgleiche gefunden werden.

Lösung

Der primäre Administrator kann den show security dns-cache Befehl verwenden, um DNS-Cache-Informationen auf dem Gerät der SRX-Serie anzuzeigen. Wenn die DNS-Cacheinformationen aktualisiert werden müssen, kann der primäre Administrator den clear security dns-cache Befehl verwenden.

HINWEIS:

Diese Befehle stehen nur dem primären Administrator auf Geräten zur Verfügung, die für logische Systeme konfiguriert sind. Dieser Befehl ist in logischen Benutzersystemen oder auf Geräten, die nicht für logische Systeme konfiguriert sind, nicht verfügbar.

Fehlerbehebung bei Sicherheitsrichtlinien

Synchronisierung von Richtlinien zwischen Routing-Engine und Packet Forwarding Engine

Problem

Beschreibung

Sicherheitsrichtlinien werden in der Routing-Engine und der Packet Forwarding Engine gespeichert. Sicherheitsrichtlinien werden von der Routing-Engine an die Packet Forwarding Engine übertragen, wenn Sie Konfigurationen festlegen. Wenn die Sicherheitsrichtlinien der Routing-Engine nicht mit der Packet Forwarding Engine synchronisiert sind, schlägt das Commit einer Konfiguration fehl. Core-Dump-Dateien können generiert werden, wenn der Commit wiederholt versucht wird. Der Ausfall der Synchronisierung kann auf folgendes zurückzuführen sein:

  • Eine Richtliniennachricht von der Routing-Engine an die Packet Forwarding Engine geht bei der Übertragung verloren.

  • Ein Fehler mit der Routing-Engine, wie z. B. eine wiederverwendete Richtlinie WIESS.

Infrastruktur

Die Richtlinien in der Routing-Engine und der Packet Forwarding Engine müssen synchronisiert sein, damit die Konfiguration festgelegt wird. Unter bestimmten Umständen können die Richtlinien in der Routing-Engine und der Packet Forwarding Engine nicht synchronisiert sein, was dazu führt, dass das Commit fehlschlägt.

Symptome

Wenn die Richtlinienkonfigurationen geändert werden und die Richtlinien nicht synchronisiert sind, wird die folgende Fehlermeldung angezeigt: error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.

Lösung

Verwenden Sie den show security policies checksum Befehl, um den Wert der Sicherheitsrichtlinien-Prüfsumme anzuzeigen, und verwenden Sie den request security policies resync Befehl, um die Konfiguration der Sicherheitsrichtlinien in der Routing-Engine und der Packet Forwarding Engine zu synchronisieren, wenn die Sicherheitsrichtlinien nicht synchronisiert sind.

Überprüfung eines Commit-Fehlers bei einer Sicherheitsrichtlinie

Problem

Beschreibung

Die meisten Fehler bei der Richtlinienkonfiguration treten während eines Commits oder der Laufzeit auf.

Commit-Fehler werden direkt über die CLI gemeldet, wenn Sie den CLI-Befehl commit-check im Konfigurationsmodus ausführen. Diese Fehler sind Konfigurationsfehler, und Sie können die Konfiguration nicht ohne behebung dieser Fehler festlegen.

Lösung

Gehen Sie folgendermaßen vor, um diese Fehler zu beheben:

  1. Überprüfen Sie Ihre Konfigurationsdaten.

  2. Öffnen Sie die Datei /var/log/nsd_chk_only. Diese Datei wird jedes Mal, wenn Sie eine Commit-Prüfung durchführen, überschrieben und enthält detaillierte Fehlerinformationen.

Verifizieren eines Commits zur Sicherheitsrichtlinie

Problem

Beschreibung

Führen Sie beim Ausführen eines Richtlinienkonfigurations-Commits die folgenden Schritte aus, um dieses Problem zu beheben, wenn Sie feststellen, dass das Systemverhalten falsch ist:

Lösung

  1. Betriebsbefehle show : Führen Sie die Betriebsbefehle für Sicherheitsrichtlinien aus und stellen Sie sicher, dass die in der Ausgabe angezeigten Informationen mit den erwartungen übereinstimmen. Falls nicht, muss die Konfiguration entsprechend geändert werden.

  2. Traceoptions: Legen Sie den traceoptions Befehl in Ihrer Richtlinienkonfiguration fest. Die Flags unter dieser Hierarchie können je nach Benutzeranalyse der show Befehlsausgabe ausgewählt werden. Wenn Sie nicht bestimmen können, welches Flag verwendet werden soll, kann die Flag-Option all verwendet werden, um alle Ablaufverfolgungsprotokolle zu erfassen.

Sie können auch einen optionalen Dateinamen konfigurieren, um die Protokolle zu erfassen.

Wenn Sie in den Trace-Optionen einen Dateinamen angegeben haben, können Sie im /var/log/<filename> nach der Protokolldatei suchen, um festzustellen, ob Fehler in der Datei gemeldet wurden. (Wenn Sie keinen Dateinamen angegeben haben, ist der Standarddateiname ereignisiert.) Die Fehlermeldungen geben den Ort des Fehlers und den entsprechenden Grund an.

Nach der Konfiguration der Trace-Optionen müssen Sie die Konfigurationsänderung erneut verwenden, die das falsche Systemverhalten verursacht hat.

Debugging-Richtliniensuche

Problem

Beschreibung

Wenn Sie über die richtige Konfiguration verfügen, aber ein Teil des Datenverkehrs fälschlicherweise unterbrochen oder zugelassen wurde, können Sie das lookup Flag in den Traceoptionen für Sicherheitsrichtlinien aktivieren. Das lookup Flag protokolliert die suchbezogenen Ablaufverfolgungen in der Trace-Datei.

Lösung

Protokoll-Fehlermeldungen, die zur Fehlerbehebung von ISSU-bezogenen Problemen verwendet werden

Die folgenden Probleme können während eines ISSU-Upgrades auftreten. Sie können die Fehler identifizieren, indem Sie die Details in den Protokollen verwenden. Ausführliche Informationen zu bestimmten Systemprotokollmeldungen finden Sie unter Systemprotokoll-Explorer.

Fehler bei gehäusebehafteten Vorgängen

Problem

Beschreibung

Fehler im Zusammenhang mit Chassisd.

Lösung

Verwenden Sie die Fehlermeldungen, um die Probleme im Zusammenhang mit chassisd zu verstehen.

Wenn ISSU gestartet wird, wird eine Anfrage an chassisd gesendet, um zu prüfen, ob es Aus Sicht des Gehäuses Probleme im Zusammenhang mit der ISSU gibt. Wenn es ein Problem gibt, wird eine Protokollmeldung erstellt.

Grundlegendes zur allgemeinen Fehlerbehandlung für ISSU

Problem

Beschreibung

Bei einer ISSU kann es zu Problemen kommen. In diesem Abschnitt finden Sie Details zur Handhabung.

Lösung

Alle Fehler, die während einer ISSU auftreten, führen zur Erstellung von Protokollmeldungen, und ISSU funktioniert weiterhin ohne Auswirkungen auf den Datenverkehr. Wenn eine Revertierung zu früheren Versionen erforderlich ist, wird das Ereignis entweder protokolliert oder die ISSU wird angehalten, um keine nicht übereinstimmenden Versionen auf beiden Knoten des Chassis-Clusters zu erstellen. Tabelle 4 stellt einige der häufigen Fehlerbedingungen und die Problemumgehungen für sie bereit. Die darin Tabelle 4 verwendeten Beispielnachrichten stammen vom SRX1500-Gerät und gelten auch für alle unterstützten Geräte der SRX-Serie.

Tabelle 4: ISSU-bezogene Fehler und Lösungen

Fehlerbedingungen

Lösungen

Versuch, eine ISSU zu initiieren, wenn die vorherige Instanz einer ISSU bereits läuft

Die folgende Meldung wird angezeigt:

warning: ISSU in progress

Sie können den aktuellen ISSU-Prozess abbrechen und den ISSU mit dem request chassis cluster in-service-upgrade abort Befehl erneut initiieren.

Neustartfehler auf dem sekundären Knoten

Es gibt keine Serviceausfälle, da der primäre Knoten weiterhin die erforderlichen Services bereitstellt. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie aufgefordert werden, vorhandene ISSU-Zustände manuell zu löschen und den Gehäuse-Cluster wiederherzustellen.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

Ab Junos OS Version 17.4R1 wird der Hold Timer für den ersten Neustart des sekundären Knotens während des ISSU-Prozesses von 15 Minuten (900 Sekunden) auf 45 Minuten (2700 Sekunden) in Gehäuseclustern auf SRX1500-, SRX4100-, SRX4200- und SRX4600-Geräten verlängert.

Sekundärer Knoten konnte die kalte Synchronisierung nicht abschließen

Wenn der sekundäre Knoten die kalte Synchronisierung nicht abgeschlossen hat, wird ein Zeitfenster für den primären Knoten angezeigt. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie vorhandene ISSU-Zustände manuell löschen und den Gehäuse-Cluster wiederherstellen. In diesem Szenario treten keine Serviceausfälle auf.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node  

Failover der neu aktualisierten Sekundäre ist fehlgeschlagen

Es gibt keine Serviceausfälle, da der primäre Knoten weiterhin die erforderlichen Services bereitstellt. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie aufgefordert werden, vorhandene ISSU-Zustände manuell zu löschen und den Gehäuse-Cluster wiederherzustellen.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Upgrade-Fehler am primären

Es gibt keine Serviceausfallzeiten, da der sekundäre Knoten als primärer ausfällt und weiterhin die erforderlichen Services bereitstellt.

Neustartfehler am primären Knoten

Vor dem Neustart des primären Knotens, bei dem Geräte außerhalb der ISSU-Einrichtung sind, werden keine ISSU-bezogenen Fehlermeldungen angezeigt. Wenn ein anderer Fehler erkannt wird, wird die folgende Fehlermeldung angezeigt:

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

SUPPORT-bezogene ISSU-Fehler

Problem

Beschreibung

Installationsfehler treten aufgrund von nicht unterstützter Software und nicht unterstützter Funktionskonfiguration auf.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die Kompatibilitätsprobleme zu verstehen:

Fehler bei der anfänglichen Validierung

Problem

Beschreibung

Die anfänglichen Validierungsprüfungen schlagen fehl.

Lösung

Die Validierungsprüfungen schlagen fehl, wenn das Bild nicht vorhanden ist oder wenn die Bilddatei beschädigt ist. Die folgenden Fehlermeldungen werden angezeigt, wenn die anfänglichen Validierungsprüfungen fehlschlagen, wenn das Bild nicht vorhanden ist und die ISSU abgebrochen wird:

Wenn ein Bild nicht vorhanden ist

Wenn die Bilddatei beschädigt ist

Wenn die Bilddatei beschädigt ist, wird die folgende Ausgabe angezeigt:

Der Primäre Knoten validiert die Gerätekonfiguration, um sicherzustellen, dass sie mit der neuen Softwareversion festgelegt werden kann. Wenn etwas schief läuft, bricht die ISSU ab und Fehlermeldungen werden angezeigt.

Installationsbedingte Fehler

Problem

Beschreibung

Die Installations-Image-Datei ist nicht vorhanden, oder die Remote-Site ist nicht zugänglich.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die installationsbezogenen Probleme zu verstehen:

ISSU lädt das Installationsimage, wie im ISSU-Befehl angegeben, als Argument herunter. Die Bilddatei kann eine lokale Datei sein oder sich an einem Remote-Standort befinden. Wenn die Datei nicht vorhanden ist oder die Remote-Site nicht zugänglich ist, wird ein Fehler gemeldet.

Redundanz-Gruppen-Failoverfehler

Problem

Beschreibung

Fehler bei automatischen Redundanzgruppen (RG).

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um das Problem zu verstehen:

Fehler bei der Kernel-Zustandssynchronisierung

Problem

Beschreibung

Fehler im Zusammenhang mit ksyncd.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die Probleme im Zusammenhang mit ksyncd zu verstehen:

ISSU prüft, ob ksyncd-Fehler auf dem sekundären Knoten (Knoten 1) vorliegen, und zeigt die Fehlermeldung an, wenn es Probleme gibt, und bricht das Upgrade ab.

Release-Verlaufstabelle
Release
Beschreibung
17.4R1
Ab Junos OS Version 17.4R1 wird der Hold Timer für den ersten Neustart des sekundären Knotens während des ISSU-Prozesses von 15 Minuten (900 Sekunden) auf 45 Minuten (2700 Sekunden) in Gehäuseclustern auf SRX1500-, SRX4100-, SRX4200- und SRX4600-Geräten verlängert.