Fehlerbehebung bei unerwartetem Neustart einer sicheren Firewall/Firepower

Einleitung

In diesem Dokument werden die Schritte zur Fehlerbehebung bei unerwarteten Neuladevorgängen der Secure Firewall/Firepower-Firewalls beschrieben.

Voraussetzungen

Anforderungen

Grundlegendes Produktwissen.

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Sichere Firewall 1200, 3100, 4200
• FirePOWER 1000, 4100, 9300
• Cisco Secure Extensible Operating System (FXOS) 2.16(0.136)
• Cisco Secure Firewall Threat Defense (FTD) 7.6.1.291
• Cisco Secure Firewall Management Center (FMC) 7.6.1.291
• Adaptive Security Appliance (ASA) 9.22.2.9

Hintergrundinformationen

In diesem Dokument werden "reboot", "reload" und "restart" synonym verwendet. Aus Sicht des Benutzers kann ein unerwarteter Neustart grob als jeder Neustart definiert werden, mit Ausnahme der bekannten, dokumentierten oder erwarteten Fälle:

1. Neustart nach Softwareinstallation oder -upgrades.
2. Neustart aufgrund von vom Benutzer ausgelösten Aktionen, wie z. B. Neustart über die Kommandozeile (CLI) oder die grafische Benutzeroberfläche (UI), oder manuelle Ein-/Ausschaltaktionen.

Je nach Auslöser kann ein Neustart entweder fehlerfrei oder nicht erfolgreich sein:

1. Ein ordnungsgemäßer Neustart bezieht sich im Allgemeinen auf den Neustart eines Systems, Geräts oder Dienstes, sodass alle aktuellen Prozesse ordnungsgemäß abgeschlossen und alle Dateien oder Daten vor dem Neustart gespeichert werden können. Dies hilft, Datenverlust oder -beschädigung zu vermeiden. Beispiele für einen ordnungsgemäßen Neustart:
   • Neustart nach Softwareinstallation oder -upgrades.
   • Neustarts aufgrund von Aktionen, die vom Benutzer ausgelöst werden, wie z. B. ein Neustart über die Kommandozeile (CLI) oder die grafische Benutzeroberfläche (UI).
   • In einigen Fällen, Software-Traceback.

2. Ein unberechtigter Neustart ist das Gegenteil eines ordnungsgemäßen Neustarts, wenn das System nicht ordnungsgemäß startet, d. h. ohne ordnungsgemäßes Beenden der Prozesse. Unanständige Neustarts können zu Datenverlusten oder -beschädigungen führen. Beispiele für Auslöser:
   • Ein- und Ausschalten durch Trennen aller Netzkabel oder Umschalten des Betriebsschalters.
   • Engpässe bei der Stromversorgung, Probleme mit den Netzteilen des Chassis
   • Verschiedene Probleme in Hardware, FPGA, Umgebung usw., die einen abrupten Neustart verursachen.

Häufige Ursachen von Neustarts:

• Aktionen von Benutzern über die Kommandozeile oder die Verwaltungs-Benutzeroberfläche
• Software-Upgrades oder -Downgrades.
• Software-Rückverfolgung.
• Auslöser sind betriebssystem- bzw. systemkritische Prozesse aus anderen Gründen als dem Traceback in der Software.
• Hardwareprobleme wie beschädigte SSD, Speicherfehler, CPU-Ausnahmen, interner FPGA usw.
• Umweltprobleme wie Stromausfall, Überhitzung usw.
• Softwarefehler oder andere Probleme bei Komponenten von Drittanbietern.
• Hohe Speicherplatznutzung.

Bei Chassis-basierten Plattformen ist es wichtig, den Umfang des Neustarts zu berücksichtigen und dabei insbesondere die genauen Neustarts zu berücksichtigen:

• die ASA/FTD-Anwendung,
• das Sicherheitsmodul (Firepower 4100/9300)
• das Chassis.

Das Standardverhalten umfasst Folgendes:

1. Wenn ein Neustart auf FTD im nativen Modus oder ASA auf Firepower 1000/2100 oder Secure Firewall 3100/4200 ausgelöst wird, wird das Gehäuse ebenfalls neu gestartet.
2. Wenn ein Neustart auf FTD im nativen Modus oder ASA auf Firepower 4100/9300-Sicherheitsmodulen ausgelöst wird, wird das Sicherheitsmodul ebenfalls neu gestartet. Das Chassis ist nicht betroffen.
3. Wenn ein Neustart im FTD-Multi-Instance-Modus auf den Firepower 4100/9300 Sicherheitsmodulen ausgelöst wird, wird nur diese Instance neu gestartet, das Sicherheitsmodul und das Gehäuse sind nicht betroffen.
4. Wenn ein Neustart im FTD-Modus mit mehreren Instanzen auf der sicheren Firewall 3100 und 4200 ausgelöst wird, wird nur diese Instanz neu gestartet, das Gehäuse ist nicht betroffen.
5. Ein Neustart auf Firepower 4100/9300 Sicherheitsmodulen startet auch alle Anwendungen, die auf betroffenen Modulen ausgeführt werden, unabhängig vom nativen Multi-Instanzmodus neu.
6. Beim Neustart des Chassis werden außerdem alle Sicherheitsmodule und Anwendungen neu gestartet.

Das Beenden bestimmter kritischer Prozesse, ob fehlerfrei oder nicht, kann zu Neustarts führen. Beispiele:

• Wenn der Datenebenenprozess, der auch als Lina bezeichnet wird, aufgrund von Rückverfolgung beendet wird, wird die Firewall neu gestartet. Eine Ausnahme bildet die Softwareversion mit der Funktion zum schnellen Neuladen der Datenebene, die in ASA 9.20(x) und FTD 7.4.1 für bestimmte Plattformen eingeführt wurde.
• Wenn der Prozess-Manager pm beendet wird, startet die Firewall neu.

Fehlerbehebung-Workflow

Gehen Sie den Fehlerbehebungsworkflow durch, der sich auf die Schritte zur Fehlerbehebung bezieht:

Schritte zur Fehlerbehebung

1. Achten Sie so genau wie möglich auf den Zeitstempel des Ereignisses, um sicherzustellen, dass Sie die Zeitzone berücksichtigen.
2. Überprüfen Sie die genaue Hardware, den Typ der sicheren Firewall-Software (ASA oder FTD), die Softwareversion und den Bereitstellungsmodus (nativer oder Multi-Instance-Modus). Detaillierte Verifizierungsschritte finden Sie unter Verifizieren der Firepower-Softwareversionen und Verifizieren der Firepower, Instanz, Verfügbarkeit und Skalierbarkeitskonfiguration.

3. Im Abschnitt Betriebszeiten analysieren können Sie die Betriebszeiten der ASA-/FTD-Anwendung, des Sicherheitsmoduls (nur Firepower 4100/9300) und des Chassis korrelieren. Das Ziel besteht darin, den Umfang des Neustarts zu verdeutlichen: die Anwendung, das Sicherheitsmodul oder das Chassis.
4. Wenn das Gehäuse neu gestartet wurde, gehen Sie wie folgt vor:

Firepower 1000, 2100, Secure Firewall 1200, 3100 und 4200 mit FTD im nativen Modus oder mit ASA

4.1. Überprüfen Sie den Abschnitt Analyse von FTD-Nachrichten Dateien (nur FTD).

4.2. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-pm.log.

4.3. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-shutdown.log.

4.4. Überprüfen Sie den Abschnitt Protokolle der ASA/FTD-Konsole analysieren.

4.5. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome von Software-Rückverfolgung und Datenerfassung zu überprüfen.

4.6. Überprüfen Sie den Abschnitt Analyse der Chassis-Zurücksetzungsgründe.

4.7. Überprüfen Sie den Abschnitt Hardwarefehler oder -ausnahmen analysieren.

4.8. Überprüfen Sie den Abschnitt Protokolldateien der Analyseplattform.

Sichere Firewall 3100, 4200 mit FTD im Containermodus

4.9. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-pm.log.

4.10. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-shutdown.log.

4.11. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome von Software-Rückverfolgung und Datenerfassung zu überprüfen.

4.12. Überprüfen Sie den Abschnitt Analyse der Chassis-Zurücksetzungsgründe.

4.13. Überprüfen Sie den Abschnitt Hardwarefehler oder -ausnahmen analysieren.

4.14. Überprüfen Sie den Abschnitt Protokolldateien der Analyseplattform.

Firepower 4100/9300

4.15. Überprüfen Sie den Abschnitt Analyse der Chassis-Zurücksetzungsgründe.

4.16. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome von Software-Rückverfolgung und Datenerfassung zu überprüfen.

Virtuelle Plattformen mit FTD

4.17. Überprüfen Sie den Abschnitt FTD-Nachrichten analysieren Dateien.

4.18. Überprüfen Sie den Abschnitt Protokolle der ASA/FTD-Konsole analysieren.

4.19. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome der Software-Rückverfolgung und für die Datenerfassung zu überprüfen.

5. Wenn Zurücksetzungsgründe wie diese im Abschnitt Analyse der Chassis-Zurücksetzungsgründe gefunden werden, finden Sie entsprechende Gründe im Abschnitt Analyse der Netzspannungs- und Versorgungsprobleme:

• Einschalten
• PowerCycle-Anforderung
• Zurücksetzen aufgrund falscher Spannung 
• Keine Zeit (Grund: Unbekannt)

6. Wenn der Neustart des Gehäuses wiederholt auftritt, sammeln Sie Konsolenprotokolle.

7. Gehen Sie bei einem Neustart des Sicherheitsmoduls für Firepower 4100/9300 wie folgt vor:

Sicherheitsmodul für Firepower 4100/9300 mit FTD im nativen Modus oder mit ASA

7.1. Überprüfen Sie den Abschnitt Analyse von FTD-Nachrichten Dateien (nur FTD).

7.2. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-pm.log.

7.3. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-shutdown.log.

7.4. Überprüfen Sie den Abschnitt Protokolle der ASA-/FTD-Konsole analysieren.

7.5. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome der Software-Rückverfolgung und für die Datenerfassung zu überprüfen.

7.6. Überprüfen Sie den Abschnitt Hardwarefehler oder -ausnahmen analysieren.

7.7. Überprüfen Sie den Abschnitt SEL/OBFL-Dateien analysieren.

7.8. Überprüfen Sie den Abschnitt Protokolldateien der Analyseplattform.

Firepower 4100/9300 Sicherheitsmodul mit FTD im Containermodus

7.9.  Überprüfen Sie den Abschnitt Analyse der Dateien ssp-pm.log.

7.10. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-shutdown.log.

7.11. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome der Software-Rückverfolgung und für die Datenerfassung zu überprüfen.

7.12. Überprüfen Sie den Abschnitt Hardwarefehler oder -ausnahmen analysieren.

7.13. Überprüfen Sie den Abschnitt SEL/OBFL-Dateien analysieren.

7.14. Überprüfen Sie den Abschnitt Protokolldateien der Analyseplattform.

8. Gehen Sie wie folgt vor, wenn eine mehrinstanzige FTD mit Firepower 4100, 9300 oder Secure Firewall 3100, 4200 neu gestartet wurde, aber weder das Gehäuse noch das Sicherheitsmodul Firepower 4100 und 9300 neu gestartet wurde:

8.1. Überprüfen Sie den Abschnitt Analyse von FTD-Nachrichten Dateien.

8.2. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-pm.log.

8.3. Überprüfen Sie den Abschnitt Analyse der Dateien ssp-shutdown.log.

8.4. Überprüfen Sie den Abschnitt Protokolle der ASA-/FTD-Konsole analysieren.

8.5. Fahren Sie mit den Schritten unter Sammeln von Daten für die Ursachenanalyse von Software-Rückverfolgung/Absturz in der sicheren Firewall fort, um die Symptome der Software-Rückverfolgung und für die Datenerfassung zu überprüfen.

9. Wenn Anzeichen für einen Neustart aufgrund von Software-Rückverfolgung vorliegen, öffnen Sie ein TAC-Ticket, und stellen Sie die erfassten Daten bereit.

10. Suchen Sie nach Softwarefehlern mit den Schlüsselwörtern unerwartet, reboot, power, reload, restart, silent:

Wird ein entsprechender Fehler gefunden, gilt Folgendes:

• Stellen Sie sicher, dass die Symptome und Bedingungen mit den im Defekt beschriebenen übereinstimmen.
• Wenden Sie ggf. die Problemumgehung an.
• Führen Sie ggf. ein Upgrade auf die feste Version durch.

11. Gehen Sie durch den Abschnitt Datenerfassung, und öffnen Sie ein TAC-Ticket.

Analyse der Betriebszeit

In diesem Abschnitt soll die Betriebszeit der ASA-/FTD-Anwendung, des Sicherheitsmoduls (nur Firepower 4100/9300) und des Gehäuses überprüft werden.

1. Überprüfen Sie die Betriebszeit der Firewall-Engine mit dem Befehl show version auf ASA und mit dem Befehl show version system auf FTD:

> show version system
---------------[ firewall-FTD ]---------------
Model                     : Cisco Firepower 4112 Threat Defense (76) Version 7.6.1 (Build 291)
UUID                      : e9460e12-674c-11f0-97e5-d5ad3617d287
LSP version               : lsp-rel-20241211-1948
VDB version               : 408
---------------------------------------------------

Cisco Adaptive Security Appliance Software Version 9.22(1)21
SSP Operating System Version 2.16(0.3007)

Compiled on Thu 29-May-25 01:38 GMT by fpbesprd
System image file is "disk0:/fxos-lfbff-k8.2.16.0.136.SPA"

Config file at boot was "startup-config"

firewall-FTD up 5 days 0 hours

Überprüfen Sie in der FTD-Fehlerbehebungsdatei die Datei command-output/'usr-local-sf-bin-sfcli.pl show_tech_support asa_lina_cli_util.output':

/command-outputs$ less 'usr-local-sf-bin-sfcli.pl show_tech_support asa_lina_cli_util.output'
…
firewall-FTD up 5 days 0 hours
…

Prüfen Sie für ASA die Betriebszeit in der Show-Tech-Datei.

2. IFs oder FTDs, die auf virtuellen Plattformen im nativen Modus ausgeführt werden, Firepower 1000, 2100, Secure Firewall 1200, 3100 und 4200 überprüfen die Betriebszeit des Betriebssystems (Tage, Stunden und Minuten) im Expert-Modus.  In diesem Fall entspricht die Betriebszeit des Chassis in etwa der Betriebszeit des Betriebssystems:

> expert
admin@firepower:/ngfw/Volume/home/admin$ uptime
 06:30:40 up 6 days,  8:01,  1 user,  load average: 5.14, 5.45, 5.48

Überprüfen Sie in der FTD-Problembehebungsdatei die Datei dir-archives/var-log/top.log:

dir-archives/var-log$ less top.log
===================================================================================================

Tue Jul 22 04:02:11 UTC 2025

top - 04:02:11 up 6 days, 13:57,  4 users,  load average: 2.23, 2.42, 2.59
Tasks: 167 total,   2 running, 165 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.6 us,  7.8 sy,  1.6 ni, 64.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7629.8 total,   2438.4 free,   4559.6 used,    631.8 buff/cache
MiB Swap:   5369.2 total,   3713.7 free,   1655.5 used.   2849.9 avail Mem

3. Für FTD im Multi-Instance-Modus auf Secure Firewall 3100 oder 4200 und ASA auf Firepower 1000, 2100, Secure Firewall 1200, 3100 und 4200 steht kein Befehl zur Verfügung, um die Verfügbarkeit des Chassis zu überprüfen.

Sie können die Betriebszeit der Blades überprüfen:

> connect fxos
…
firewall# scope ssa
firewall /ssa # show slot detail expand

Slot:
    Slot ID: 1
    …
        Blade Uptime: up 16 hours, 2 min       

Überprüfen Sie in der Datei für die Chassis-Fehlerbehebung die Verfügbarkeit in der Datei opt/cisco/platform/logs/sysmgr/sam_logs/topout.log:

opt/cisco/platform/logs/sysmgr/sam_logs/topout.log $ less topout.log
[Jul 23 13:15:22]
top - 13:15:22 up 16:02,  1 user,  load average: 12.24, 11.85, 11.75

4. Im Fall von Firepower 4100/9300 überprüfen Sie die Betriebszeit des Chassis und Sicherheitsmoduls in der FXOS-CLI.

Chassis-Betriebszeit:

firewall /ssa # connect fxos
firewall(fxos)# show system uptime
System start time:          Tue Jul 22 21:57:44 2025
System uptime:              6 days, 9 hours, 49 minutes, 50 seconds
Kernel uptime:              6 days, 9 hours, 45 minutes, 58 seconds
Active supervisor uptime:   6 days, 9 hours, 49 minutes, 50 seconds

Betriebszeit des Sicherheitsmoduls:

firewall# scope ssa
firewall /ssa # show slot detail expand
Slot:
    Slot ID: 1
    …
        Blade Uptime: up 5 days, 37 min       

Überprüfen Sie in der Datei für die Chassis-Fehlerbehebung die Ausgaben des Befehls show system uptime in file *_BC1_all/FPRM_A_TechSupport/sw_techsupportinfo, und überprüfen Sie den Befehl show slot expand detail expand in file *_BC1_all/FPRM_A_TechSupport/sam_techsupportinfo, wobei * Teil des Problembehandlung bei Dateinamen, z. B. 20250311123356_ FW _BC1_all.

FTD-Nachrichten analysieren Dateien

In diesem Abschnitt wird die Analyse der FTD-Nachrichtendatei behandelt, die Protokolle zu Herunterfahren, Neustart und möglichen Auslösern enthält.

FTD läuft auf allen Plattformen

Die Datei enthält Protokolle zum Herunterfahren, Neustart und den möglichen Auslösern auf FTD, die auf folgenden Geräten ausgeführt werden:

• Virtuelle Plattformen, Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200 Chassis.
• Firepower 4100 und 9300 Sicherheitsmodule.

Der Zugriff auf die Datei erfolgt über:

• FTD CLISH im Expert-Modus: /ngfw/var/log/messages
• FTD-Fehlerbehebungsdatei: dir-archives/var-log/messages

Um den Auslöser von Herunterfahrten oder Neustarts zu finden, überprüfen Sie in den FTD-Fehlerbehebungsdateien die Meldungen, die Defense in der Datei messages file enthalten. Überprüfen Sie alle Nachrichtendateien, einschließlich messages.1, messages.2 usw. Diese Meldungen weisen eindeutig auf ein ordnungsgemäßes Herunterfahren hin:

• Cisco Secure Firewall wird beendet...oder Cisco FirePOWER wird beendet...
• Threat Defence wird heruntergefahren

root@CSF1220-2:/ngfw/var/log# grep -a Defense /ngfw/var/log/messages
messages:Jul 22 21:07:10 firepower-1220 SF-IMS[36894]: [36894] S11audit-startup-shutdown:start [INFO] Cisco Secure Firewall 1220CX Threat Defense has started
messages:Jul 22 21:12:37 firepower-1220 SF-IMS[62594]: [62594] sensor:CLI Start [INFO] Starting Cisco Secure Firewall 1220CX Threat Defense
messages:Jul 22 21:13:03 firepower-1220 SF-IMS[65410]: [65410] S99sensor:CLI Start [INFO] Starting Cisco Secure Firewall 1220CX Threat Defense
messages:Jul 23 12:56:43 CSF1220-2 SF-IMS[61878]: [61878] K01sensor:CLI Stop [INFO] Stopping Cisco Secure Firewall 1220CX Threat Defense
messages:Jul 23 12:57:03 CSF1220-2 SF-IMS[62749]: [62749] K69audit-startup-shutdown:stop [INFO] Cisco Secure Firewall 1220CX Threat Defense is shutting down
messages:Jul 23 13:00:21 CSF1220-2 SF-IMS[10866]: [10866] S11audit-startup-shutdown:start [INFO] Cisco Secure Firewall 1220CX Threat Defense has started
messages:Jul 23 13:00:36 CSF1220-2 SF-IMS[13443]: [13443] S99sensor:CLI Start [INFO] Starting Cisco Secure Firewall 1220CX Threat Defense

root@1140-2:/ngfw/var/log# grep -a Defense /ngfw/var/log/messages

messages:Jul 22 09:20:42 FPR1140-2 SF-IMS[6012]: [6012] S11audit-startup-shutdown:start [INFO] Cisco Firepower 1140 Threat Defense has started
messages:Jul 22 09:21:35 FPR1140-2 SF-IMS[9050]: [9050] S99sensor:CLI Start [INFO] Starting Cisco Firepower 1140 Threat Defense
messages:Jul 22 11:32:37 FPR1140-2 SF-IMS[15129]: [15129] K01sensor:CLI Stop [INFO] Stopping Cisco Firepower 1140 Threat Defense
messages:Jul 22 11:32:55 FPR1140-2 SF-IMS[15940]: [15940] K69audit-startup-shutdown:stop [INFO] Cisco Firepower 1140 Threat Defense is shutting down
messages:Jul 22 11:36:38 FPR1140-2 SF-IMS[5980]: [5980] S11audit-startup-shutdown:start [INFO] Cisco Firepower 1140 Threat Defense has started
messages:Jul 22 11:36:53 FPR1140-2 SF-IMS[7594]: [7594] S99sensor:CLI Start [INFO] Starting Cisco Firepower 1140 Threat Defense

Analyse von Sicherheitsmodul- oder Chassis-Meldungen Dateien

Dieser Abschnitt behandelt die Analyse der Sicherheitsmodul- oder Chassis-Meldungsdatei, die Protokolle für den Betriebssystem-Kernel enthält.

Die Datei enthält Protokolle zum Herunterfahren, Neustart und den möglichen Auslösern auf FTD, die auf folgenden Geräten ausgeführt werden:

• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200.
• Firepower 4100 und 9300 Sicherheitsmodule.

Der Zugriff auf die Datei erfolgt über:

• hardwarebasiertes FTD im nativen Modus: /opt/cisco/platform/log/messages
• Fehlerbehebung in der Datei der hardwarebasierten FTD, die im nativen Modus ausgeführt wird: dir-archives/opt-cisco-platform-logs/messages.
• Problembehebungsdatei für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200: /opt/cisco/platform/log/messages
• Firepower 4100/9300 Sicherheitsmodul show-tech file: /opt/cisco/platform/log/messages

Dies sind die wichtigsten Punkte der Protokolle in dieser Datei:

• Überprüfen Sie alle Nachrichtendateien, einschließlich messages.1, messages.2 usw.
• Wenn der Betriebssystem-Kernel bootet, werden die Kernel-Protokolle in diese Datei geschrieben. Auf Hardwareplattformen und Sicherheitsmodulen werden Protokolle zunächst in die UTC-Zeitzone geschrieben, bis die benutzerdefinierte Zeitzone während des Starts angewendet wird.

Aus diesem Grund können verschiedene Protokolle in derselben Datei unterschiedliche Zeitstempel mit unterschiedlichen Zeitzonen aufweisen.

Betrachten Sie dieses Beispiel eines Firepower 4100-Sicherheitsmoduls mit der UTC+2-Zeitzone:

2025-08-18T14:54:16+02:00 Firepower-module1/2 root: FXOS shutdown log started: pid = 52994 cmdline = /bin/sh/sbin/fxos_log_shutdown ####
2025-08-18T14:54:16+02:00 Firepower-module1/2 root: FXOS shutdown log completed: pid = 52994
2025-08-18T14:54:17+02:00 Firepower-module1/2 syslog-ng[1230]: syslog-ng shutting down; version='3.36.1' <--- syslog-ng shutting down indicates graceful shutdown
2025-08-18T12:57:11+00:00 intel-x86-64/1 syslog-ng[1237]: syslog-ng starting up; version='3.36.1' <--- syslog-ng start timestamp with UTC timezone
2025-08-18T12:57:11+00:00 intel-x86-64/1 kernel: [    0.000000] Linux version 5.10.200-yocto-standard (oe-user@oe-host) (x86_64-wrs-linux-gcc (GCC) 10.3.0, GNU ld (GNU Binutils) 2.36.1.20210703) #1 SMP Fri Feb 7 01:00:00 UTC 2025
2025-08-18T12:57:11+00:00 intel-x86-64/1 kernel: [    0.000000] Command line: rw console=ttyS0,38400 loglevel=2 auto kstack=128 reboot=force panic=1 ide_generic.probe_mask=0x1 ide1=noprobe pci=nocrs pci=realloc processor.max_cstate=1 iommu=pt nousb platform=sspxru boot_img=disk0:/fxos-lfbff-k8.2.16.0.136.SPA ciscodmasz=1048576 cisconrsvsz=1572864 hugepagesz=1g hugepages=12 pti=off  rom_ver=1.3.1.44 ssp_mode=0
…
2025-08-18T12:58:34+00:00 intel-x86-64/1 csp-console: Adi not started yet, trying to bring up
2025-08-18T12:58:34+00:00 intel-x86-64/1 ssp_tz[12159]: INFO: Lina is started
2025-08-18T12:58:34+00:00 intel-x86-64/1 SMA: INFO ExecProcessorMain [140588852127296]: finished processing of sma_slot1.deletePlatformLicense, removed it from queue
2025-08-18T12:58:34+00:00 intel-x86-64/1 ssp_tz[12167]: INFO: notify TZ to ASA LINA <---- Time zone change was propagated to the firewall
2025-08-18T14:58:35+02:00 intel-x86-64/1 ssp_tz[12192]: INFO: successfully notified TZ to ASA LINA, wait <---- Logs with the UTC+2 timestamp
2025-08-18T14:58:36+02:00 intel-x86-64/1 csp-console: Adi not started yet, trying to bring up
2025-08-18T14:58:39+02:00 intel-x86-64/1 csp-console[1237]: Last message 'Adi not started yet,' repeated 1 times, suppressed by syslog-ng on intel-x86-64

Dateien ssp-pm.log analysieren

Dieser Abschnitt behandelt die Analyse der Dateien /opt/cisco/platform/logs/ssp-pm.log, die Protokolle enthalten, die mit dem Herunterfahren oder Neustart von ASA-/FTD-Anwendungen zusammenhängen.

Die Datei enthält Protokolle zum Herunterfahren oder Neustarten für ASA-/FTD-Anwendungen, die auf folgenden Systemen ausgeführt werden:

• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200
• Firepower 4100 und 9300 Sicherheitsmodule (nicht das Chassis)

Auf die Datei kann nur zugegriffen werden in:

• Nativer FTD-Modus (nicht Multi-Instance) CLISH im Expert-Modus: opt/cisco/platform/logs/ssp-pm.log
• Datei zur Fehlerbehebung im nativen FTD-Modus: dir-archives/opt-cisco-platform-logs/ssp-pm.log.
• Chassis-Fehlerbehebung für Dateien auf Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200: /opt/cisco/platform/logs/ssp-pm.log

Um einwandfreie Abschaltungen oder Neustarts zu identifizieren, suchen Sie nach Zeilen wie SHUTDOWN WARNUNG, die mit dem Zeitstempel für Neustart/Herunterfahren übereinstimmen. Überprüfen Sie alle ssp-pm.log-Dateien, einschließlich ssp-pm.log.1, ssp-pm.log.2 usw. Diese Meldungen weisen eindeutig auf ein ordnungsgemäßes Herunterfahren hin:

Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING: Beginning System Shutdown request for CSP Apps
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-GetShutdownMaxForceQuitTimer: acquiring max force_quit_timeout from all heimdall confs
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING: Upgrade process ready for reboot
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-GetShutdownMaxForceQuitTimer: No force_quit_timeout found among conf files. Sendsigs_Sleep = 1
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING: Continue System Shutdown request for CSP Apps
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-SysShutdown_HeimdallSvcDownAllCspApps: corresponding heimdall conf file folder:
cisco-asa.9.22.2.9__asa_001_JMX2324G1DJ947ECO1.conf
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-SysShutdown_HeimdallSvcDownAllCspApps: corresponding cspCfgXML file folder:
...cspCfg_cisco-asa.9.22.2.9__asa_001_JMX2324G1DJ947ECO1.xml.allocated_cpu_core
…
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-SysShutdown_HeimdallSvcDownAllCspApps: stopping all CSPs according to existing heimdall/etc/confs
Fri Jul 25 10:28:51 UTC 2025 -(PM_UTILS)- SHUTDOWN WARNING:-SysShutdown_HeimdallSvcDownAllCspApps: Stopping App for CONF:cisco-asa.9.22.2.9__asa_001_JMX2324G1DJ947ECO1.conf

Dateien ssp-shutdown.log analysieren

Dieser Abschnitt behandelt die Analyse der Dateien /opt/cisco/platform/logs/ssp-shutdown.log, die Protokolle enthalten, die beim Herunterfahren oder Neustart des Chassis-/Sicherheitsmoduls generiert werden.

Die Datei enthält Protokolle zum Herunterfahren oder Neustarten für:

• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200.
• Firepower 4100 und 9300 Sicherheitsmodule (nicht das Chassis).

Auf die Datei kann nur zugegriffen werden in:

• Nativer FTD-Modus (nicht Multi-Instance) CLISH im Expert-Modus: opt/cisco/platform/logs/ssp-shutdown.log.
• Datei zur Fehlerbehebung im nativen FTD-Modus: dir-archives/opt-cisco-platform-logs/ssp-shutdown.log.
• Chassis-Fehlerbehebung in den Dateien Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200: /opt/cisco/platform/logs/ssp-shutdown.log
• Sicherheitsmodul für Firepower 4100/9300 - Problembehebungsdatei: opt/cisco/platform/logs/ssp-shutdown.log.

Informationen zum Generieren der FTD-, Gehäuse- und Sicherheitsmodul-Fehlerbehebungsdateien finden Sie unter https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html.

Gehen Sie folgendermaßen vor, um den Auslöser für normale Abschaltungen oder Neustarts zu finden:

1. Überprüfen Sie, ob die Zeilen wie "FXOS shutdown started" mit dem Zeitstempel für Neustart/Herunterfahren übereinstimmen. Überprüfen Sie alle ssp-shutdown.log-Dateien, einschließlich ssp-shutdown.log.1, ssp-shutdown.log.2 usw.

#### Wed Jul 23 12:56:42 UTC 2025: FXOS shutdown started: pid = 61677 cmdline = /bin/sh/sbin/fxos_log_shutdown

2. Suchen Sie im Prozessbaum nach Zeilen, die fxos_log_shutdown oder shutdown enthalten oder reboot.sh.
   
   Beispiel 1 - Die Anforderung für einen Neustart stammte von einem Peer mit UUID 068f09e6-3825-11ee-a72c-e78d34d303cc und der IP-Adresse 192.0.2.100, die lautet: das FÜZ:

root     61074  4593  2 12:56 ?        00:00:00          |   \_ /usr/bin/perl /ngfw/usr/local/sf/bin/exec_perl.pl 068f09e6-3825-11ee-a72c-e78d34d303cc 192.0.2.100 068f09e6-3825-11ee-a72c-e78d34d303cc SF::System::
Privileged::RebootSystem
root     61097 61074  0 12:56 ?        00:00:00          |       \_ /bin/sh /ngfw/usr/local/sf/bin/reboot.sh
root     61670 61097  0 12:56 ?        00:00:00          |           \_ /bin/sh /sbin/shutdown -r now
root     61671 61670  0 12:56 ?        00:00:00          |               \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     61676 61671  0 12:56 ?        00:00:00          |                   \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root     61677 61676  0 12:56 ?        00:00:00          |                       \_ /bin/sh /sbin/fxos_log_shutdown
root     61685 61677  0 12:56 ?        00:00:00          |                           \_ /bin/ps -ef –forest

> show managers
Type                      : Manager
Host                      : 192.0.2.100
Display name              : 192.0.2.100
Version                   : 7.6.1 (Build 291)
Identifier                : 068f09e6-3825-11ee-a72c-e78d34d303cc
Registration              : Completed
Management type           : Configuration and analytics

Beispiel 2 - Neustart aufgrund eines Software-Upgrades:

root      2432     1  0 03:59 ?        00:00:00 /bin/bash /isan/bin/kp_reboot.sh Reboot requested for Software Upgrade
root      2694  2432  0 03:59 ?        00:00:00  \_ /bin/sh /isan/bin/sam_reboot.sh Reboot requested for Software Upgrade
root      3774  2694  0 04:00 ?        00:00:00      \_ /usr/bin/sudo /sbin/shutdown -r now Reboot requested for Software Upgrade
root      3777  3774  0 04:00 ?        00:00:00          \_ /bin/sh /sbin/shutdown -r now Reboot requested for Software Upgrade
root      3778  3777  0 04:00 ?        00:00:00              \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root      3783  3778  0 04:00 ?        00:00:00                  \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root      3784  3783  0 04:00 ?        00:00:00                      \_ /bin/sh /sbin/fxos_log_shutdown
root      3790  3784  0 04:00 ?        00:00:00                          \_ /bin/ps -ef –forest

Beispiel 3 - Der Neustart wurde vom Administrator mit dem CLISH-Befehl reboot angefordert:

root     22189     1  0 Jul23 ?        00:00:01 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
root     20963 22189  0 06:55 ?        00:00:00  \_ sshd: admin [priv]
admin    20970 20963  0 06:55 ?        00:00:00  |   \_ sshd: admin@pts/0
admin    20975 20970  0 06:55 pts/0    00:00:00  |       \_ /isan/bin/ucssh --ucs-mgmt -p admin -c connect ftd -z /home/admin
admin    21077 20975  0 06:55 pts/0    00:00:00  |           \_ /ngfw/usr/bin/clish
admin    36022 21077  0 07:23 pts/0    00:00:00  |               \_ /ngfw/usr/bin/clish
admin    36023 21077  0 07:23 pts/0    00:00:00  |               \_ /bin/sh /tmp/klish.fifo.21077.1Hwyq1
admin    36024 36023  8 07:23 pts/0    00:00:01  |                   \_ /usr/bin/perl /usr/local/sf/bin/sfcli.pl reboot system
root     36083 36024  0 07:23 pts/0    00:00:00  |                       \_ /usr/bin/sudo /ngfw/usr/local/sf/bin/reboot.sh
root     36088 36083  0 07:23 pts/0    00:00:00  |                           \_ /bin/sh /usr/local/sf/bin/reboot.sh
root     36433 36088  0 07:23 pts/0    00:00:00  |                               \_ /bin/sh /sbin/shutdown -r now
root     36434 36433  0 07:23 pts/0    00:00:00  |                                   \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     36439 36434  0 07:23 pts/0    00:00:00  |                                       \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root     36440 36439  0 07:23 pts/0    00:00:00  |                                           \_ /bin/sh /sbin/fxos_log_shutdown
root     36448 36440  0 07:23 pts/0    00:00:00  |                                               \_ /bin/ps -ef --forest

Beispiel 4 - Das Herunterfahren wurde durch Klicken auf den Betriebsschalter ausgelöst. PBTN steht für einen physischen Netzschalter. Das Drücken des Betriebsschalters an einem Gerät löst dieses Ereignis aus. Das Skript verwendet dieses Ereignis, um einen Abschaltvorgang zu initiieren, in der Regel weil ein Benutzer beabsichtigt, die Firewall sicher abzuschalten:

root      1310     1  0 00:14 ?        00:00:00 /usr/sbin/acpid -c /etc/acpi/events
root     50700  1310  0 00:32 ?        00:00:00  \_ /bin/sh /etc/acpi/acpi_handler.sh button/power PBTN 00000080 00000000
root     50701 50700  0 00:32 ?        00:00:00      \_ /bin/sh /sbin/shutdown -h now
root     50702 50701  0 00:32 ?        00:00:00          \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     50707 50702  0 00:32 ?        00:00:00              \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root     50708 50707  0 00:32 ?        00:00:00                  \_ /bin/sh /sbin/fxos_log_shutdown
root     50715 50708  0 00:32 ?        00:00:00                      \_ /bin/ps -ef –forest

Beispiel 5 - Neustart wurde vom internen npu_accel_mgr-Prozess angefordert:

root     12649  5280  0 13:59 ?        00:01:06  \_ npu_accel_mgr
root     19030 12649  0 18:22 ?        00:00:00  |   \_ /bin/sh /sbin/shutdown -r now
root     19031 19030  0 18:22 ?        00:00:00  |       \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     19036 19031  0 18:22 ?        00:00:00  |           \_ /usr/bin/ timeout 15 /sbin/fxos_log_shutdown
root     19037 19036  0 18:22 ?        00:00:00  |               \_ /bin/sh /sbin/fxos_log_shutdown
root     19043 19037  0 18:22 ?        00:00:00  |                   \_ /bin/ps -ef –forest

Beispiel 6 - Shutdown wurde vom internen poshd-Prozess angefordert:

root       643     1  0 13:00 ?        00:00:00 /usr/bin/poshd
root     13207   643  0 13:43 ?        00:00:00  \_ /bin/sh /sbin/shutdown -h -P now
root     13208 13207  0 13:43 ?        00:00:00      \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     13213 13208  0 13:43 ?        00:00:00          \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root     13214 13213  0 13:43 ?        00:00:00              \_ /bin/sh /sbin/fxos_log_shutdown
root     13221 13214  0 13:43 ?        00:00:00                  \_ /bin/ps -ef –forest

poshd ist verantwortlich für das sanfte Herunterfahren des Geräts bei Stromausfall (entweder über den Netzschalter oder den externen Leistungsfaktor).

Beispiel 7 - Neustart wurde durch Statusänderungen der Firewall-Engine Lina ausgelöst, z. B.:

• durch Ausführen des Befehls reload in der ASA-CLI oder der FTD-Diagnose-CLI
• das Lina Engine-Traceback (mit Ausnahme der Versionen mit der Funktion zum schnellen Neuladen der Datenebene, die in ASA 9.20(x) und FTD 7.4.1 eingeführt wurde).
• unvollständige/teilweise Synchronisierung von aktiver zu Standby-Einheit

root     56833 56198  0 00:48 ?        00:00:00  |   \_ /ngfw/usr/local/sf/bin/consoled /ngfw/var/run/lina.pid -coredump_filter=0x67 /ngfw/usr/local/asa/bin/lina_monitor -l
root     57003 56833  0 00:48 ?        00:00:00  |       \_ /bin/sh /sbin/shutdown -r now
root     59448 57003  0 00:48 ?        00:00:00  |           \_ /bin/sh /sbin/exec_fxos_log_shutdown.sh
root     59453 59448  0 00:48 ?        00:00:00  |               \_ /usr/bin/timeout 15 /sbin/fxos_log_shutdown
root     59454 59453  0 00:48 ?        00:00:00  |                   \_ /bin/sh /sbin/fxos_log_shutdown
root     59461 59454  0 00:48 ?        00:00:00  |                       \_ /bin/ps -ef –forest

Analyse der Chassis-Zurücksetzungsgründe

In diesem Abschnitt wird die Analyse der Gründe für das Zurücksetzen des Chassis beschrieben. Auf dem Firepower 4100/9300-Chassis kann nur in den folgenden Fällen auf den Grund für das Zurücksetzen zugegriffen werden:

• FXOS-CLI:

# connect fxos
(fxos)# show system reset-reason

• In der Ausgabe des Befehls show system reset-reason in chassis troubleshoot files *_BC1_all/FPRM_A_TechSupport/sw_techsupportinfo, wobei * der Teil des Dateinamens für die Fehlerbehebung ist, z. B. 20250311123356_ FW_BC1_all

Auf Firepower 1000, 2100, Secure Firewall 1200, 3100, 4200 kann nur in den folgenden Fällen auf den Grund für das Zurücksetzen zugegriffen werden:

• Nativer FTD-Modus (nicht Multi-Instance) CLISH im Expert-Modus: opt/cisco/platform/logs/portmgr.out
• Datei zur Fehlerbehebung im nativen FTD-Modus: dir-archives/opt-cisco-platform-logs/portmgr.out
• Chassis-Fehlerbehebung für Dateien auf Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200: /opt/cisco/platform/logs/portmgr.out

Informationen zum Generieren der FTD-, Gehäuse- und Sicherheitsmodul-Fehlerbehebungsdateien finden Sie unter https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html.

Gehen Sie wie folgt vor, um den Grund für das Zurücksetzen von anderen Hardwareplattformen als Firepower 4100/9300 zu finden:

1. Suchen Sie unter /opt/cisco/platform/logs/portmgr.out nach Zeilen wie Letzte Rücksetzursache, die mit dem Zeitstempel für Neustart/Herunterfahren übereinstimmen. Überprüfen Sie alle portmgr.out-Dateien, einschließlich portmgr.out.1, portmgr.out.2 usw.

2. In der folgenden Tabelle finden Sie eine Erläuterung häufiger Zurücksetzungsgründe:

Gehen Sie folgendermaßen vor, um den Grund für das Zurücksetzen des Firepower 4100/9300 zu finden:

1. Führen Sie auf der FXOS-CLI den Befehl show system reset-reason in der fxos-Befehls-Shell aus. 

FPR4115-2 # connect fxos
…
FPR4115-2(fxos)# show system reset-reason
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) ---
1) At 612806449 usecs after Tue Jul 22 23:50:33 2025
    Reason: Reset Requested by CLI command reload
    Service:
    Version: 5.0(3)N2(4.141)

2) No time
    Reason: Unknown
    Service:
    Version: 5.0(3)N2(4.141)

3) No time
    Reason: Unknown
    Service:
    Version: 5.0(3)N2(4.141)

4) At 723697 usecs after Thu Oct  3 17:56:08 2024
    Reason: Reset Requested by CLI command reload
    Service:
    Version: 5.0(3)N2(4.120)

Die Ausgabe dieses Befehls ist auch in der Fehlerbehebungsdatei für das Chassis verfügbar *_BC1_all/FPRM_A_TechSupport/sw_techsupportinfo, wobei * der Teil des Namens der Fehlerbehebungsdatei ist, z. B. 20250311123356_ FW_BC1_all

# pwd
20250521112103_FPR9300_BC1_all/FPRM_A_TechSupport
# less sam_techsupportinfo

Häufigste Gründe:

2. Der unbekannte Grund ohne Zeit in Schritt 1 deutet in der Regel auf einen abrupten Stromausfall oder Probleme mit dem Netzteil hin. Es wird empfohlen, Vorfälle im Hinblick auf externe Stromausfälle oder Stromverteilungsprobleme zu prüfen.

3. Zusätzlich überprüfen Sie die Ausgabe des show logging Onboard interne Reset-Grund | no-more-Befehl. Die Ausgabe dieses Befehls steht auch in der Fehlerbehebungsdatei für das Chassis zur Verfügung *_BC1_all/FPRM_A_TechSupport/sw_kernel_trace_log, wobei * der Teil des Namens der Fehlerbehebungsdatei ist, z. B. 20250311123356_ FW_BC1_all:

FPR4115-2 # connect fxos
…
KSEC-FPR4115-2(fxos)# show logging onboard internal reset-reason | no-more 
----------------------------
OBFL Data for
    Module:  1
----------------------------
Reset Reason for this card:
        Image Version : 5.0(3)N2(4.141)
        Reset Reason (SW): Unknown (0) at time Fri Jul  4 23:57:21 2025
          Service (Additional Info):
        Reset Reason (HW): FPGA  reset code: 0x0001
          FPGA Power-ON Reset at time Fri Jul  4 23:57:21 2025

Analyse von Hardwarefehlern oder -ausnahmen

Dieser Abschnitt behandelt die Analyse von Dateien, die Hardwarefehler oder -ausnahmen enthalten.

Firepower 1000, 2100, Secure Firewall 1200, 3100, 4200, Firepower 4100/9300 Sicherheitsmodule

Die entsprechenden Dateien sind:

• /opt/cisco/platform/logs/mce.log (Computerprüfungs-Ausnahmeprotokolle)
• /ngfw/var/log/dmesg.log (nur FTD)
• /opt/cisco/config/var/logs/dmesg.log
• /opt/cisco/platform/logs/messages

Diese Dateien können Hardwarefehler- oder Ausnahmenprotokolle enthalten für:

• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200
• Firepower 4100 und 9300 Sicherheitsmodule (nicht das Chassis)

Auf die Dateien kann nur zugegriffen werden in:

• Nativer FTD-Modus (nicht Multi-Instance) CLISH im Expert-Modus:
  • /opt/cisco/platform/logs/mce.log
  • /ngfw/var/log/dmesg.log (nur FTD)
  • /opt/cisco/config/var/logs/dmesg.log
  • /opt/cisco/platform/logs/messages
• Datei zur Fehlerbehebung im nativen FTD-Modus:
  • dir-archives/var-common-platform_ts/opt/cisco/platform/logs/mce.log
  • dir-archives/var-common-platform_ts/opt/cisco/platform/logs/messages
  • dir-archives/var-common-platform_ts/opt/cisco/config/var/logs/dmesg.log
  • dir-archives/var-log/dmesg.log
• Chassis-Fehlerbehebung für Dateien auf Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200:
  • /opt/cisco/platform/logs/mce.log
  • /opt/cisco/config/var/logs/dmesg.log
  • /opt/cisco/platform/logs/messages
• Sicherheitsmodul show-tech file auf Firepower 4100/9300:
  • /opt/cisco/platform/logs/mce.log
  • /opt/cisco/config/var/logs/dmesg.log
  • /opt/cisco/platform/logs/messages

Beispiele für Hardwarefehler:

opt/cisco/config/var/logs/ $ less dmesg.log
[Sun Apr 27 05:17:10 2025] mce: [Hardware Error]: Machine check events logged
[Sun Apr 27 05:17:10 2025] mce: [Hardware Error]: Machine check events logged

/opt/cisco/platform/logs $ less messages
Jul  9 17:39:38 fw2 kernel: [  628.949572] [Hardware Error]: Corrected error, no action required.
Jul  9 17:39:38 fw2 kernel: [  629.023798] [Hardware Error]: CPU:2 (19:1:1) MC18_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc2040000000011b
Jul  9 17:39:38 fw2 kernel: [  629.152245] [Hardware Error]: Error Addr: 0x0000000068d06d40
Jul  9 17:39:38 fw2 kernel: [  629.152248] [Hardware Error]: PPIN: 0x02b0bc114ba60075
Jul  9 17:39:38 fw2 kernel: [  629.281830] [Hardware Error]: IPID: 0x0000009600550f00, Syndrome: 0x000400040a801200
Jul  9 17:39:38 fw2 kernel: [  629.374797] [Hardware Error]: Unified Memory Controller Ext. Error Code: 0, DRAM ECC error.
Jul  9 17:39:38 fw2 kernel: [  629.475078] [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
Jul  9 17:44:40 fw2 kernel: [  930.967028] [Hardware Error]: Corrected error, no action required.
Jul  9 17:44:40 fw2 kernel: [  931.041247] [Hardware Error]: CPU:2 (19:1:1) MC18_STATUS[Over|CE|MiscV|AddrV|-|-|SyndV|CECC|-|-|-]: 0xdc2040000000011b
Jul  9 17:44:40 fw2 kernel: [  931.169689] [Hardware Error]: Error Addr: 0x000000007191d0c0
Jul  9 17:44:40 fw2 kernel: [  931.237616] [Hardware Error]: PPIN: 0x02b0bc114ba60075
Jul  9 17:44:40 fw2 kernel: [  931.299275] [Hardware Error]: IPID: 0x0000009600550f00, Syndrome: 0x000040000a801100


/opt/cisco/platform/logs $ less mce.log
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 7 TSC 7b29f624ae62e 
MISC 140129286 ADDR 3402b9a00 
TIME 1745747035 Sun Apr 27 09:43:55 2025
MCG status:
MCi status:
Corrected error
MCi_MISC register valid
MCi_ADDR register valid
MCA: MEMORY CONTROLLER RD_CHANNEL0_ERR
Transaction: Memory read error
STATUS 8c00004000010090 MCGSTATUS 0
MCGCAP 1000c16 APICID 0 SOCKETID 0 
PPIN afeebaf20487b95
MICROCODE 700000d
CPUID Vendor Intel Family 6 Model 86 Step 3
mcelog: failed to prefill DIMM database from DMI data

Catastrophic Errors (CATERR) bei Firepower 4100/9300-Sicherheitsmodulen

Eine CATERR ist eine Ausnahme, die vom Prozessor behauptet wird. Eine CATERR kann auf einen CPU-Absturz oder Probleme auf niedriger Ebene hinweisen, die dazu führen, dass auf den Blade-Server nicht zugegriffen werden kann. Der Chassis-Supervisor startet das Sicherheitsmodul neu, für das CATERR zuständig war. Die CATERR-Protokolle befinden sich in der Fehlerbehebungsdatei für Firepower 4100/9300 in CIMC<X>_TechSupport/obfl/ und CIMC<X>_TechSupport/var/log/sel, wobei <X> für die Modulnummer steht.

Ein Beispiel aus einer Beispiel-Chassis-Fehlerbehebungsdatei *_BC1_all/CIMC<X>_TechSupport.tar.gz/CIMC<X>_TechSupport.tar/obfl/obfl-log, wobei * der Teil des Namens der Fehlerbehebungsdatei ist, z. B. 20250311123356_ FW_BC1_all und <X > die Sicherheitsmodul-ID ist:

2022 Mar 25 22:33:13 CET:4.1(30b):selparser:1950: selparser.c:727: # BF 06 00 00 01 02 00 00 19 35 3E 62 20 00 04 07 81 00 00 00 04 01 FF FF # 6bf | 03/25/2022 22:33:13 CET | CIMC | Processor CATERR_N #0x81 | Predictive Failure asserted | Asserted

Die aktuelle Data Management Engine (DME) meldet sich unter *_BC1_all/FPRM_A_TechSupport.tar.gz\FPRM_A_TechSupport.tar\var\sysmgr\sam_logs\svc_sam_dme.log* oder die Protokolle vor dem Neustart unter *_BC1_all/FPRM_A_TechSupport.tar.gz/FPRM_A_TechSupport.tar/opt/sam_logs.tgz/sam_logs.tar/sam_logs/svc_sam_dme.log* enthalten die Leitungen mit Power Cycle Blade X aufgrund von CATERR, wobei X die Blade-ID ist.

Im Falle von CATERR kann ein Crash Dump erzeugt werden. Das Absturzabbild befindet sich in *_BC1_all/CIMC<X>_TechSupport.tar.gz/CIMC<X>_TechSupport.tar/techsupport_pidxxxx/nv/etc/log/eng-repo/caterrlog.first.

Beispielinhalt:

CRASH DUMP START TIME = Mon Dec 19 00:42:40 2022
               SERVER: presidio
               GetCpuID: CPUID = 0x00050654
               PresidioCatErrHandler: CPU TYPE : Skylake
               handleCaterr_Purley: ---
               PECI BUS : LOCKED
               CPU Socket 1 : Populated
               CPU Socket 2 : Populated
               Stage1Dump: ---
               MC0: IFU - Instruction Fetch Unit and Instruction Cache
               CPU1 (0x30): ThreadID 0 : IA32_MC0_CTL (0x400) : 0x0000000000000fff
               CPU1 (0x30): ThreadID 0 : IA32_MC0_STATUS (0x401) : 0x0000000000000000
               CPU1 (0x30): ThreadID 0 : IA32_MC0_ADDR (0x402) : 0x0000000000000000

Analysieren anderer Plattformprotokolldateien

Dieser Abschnitt behandelt die Analyse der Dateien, die Plattformprotokolle enthalten. Je nach Hardware können einige dieser Dateien Protokolle enthalten, die sich auf einen von bestimmten Komponenten ausgelösten Neustart beziehen.

Firepower 1000, 2100, Secure Firewall 1200, 3100, 4200, Firepower 4100/9300 Sicherheitsmodule

Die Dateien enthalten Chassisprotokolle für:

• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200
• Firepower 4100 und 9300 Sicherheitsmodule (nicht das Chassis)

Auf die Dateien kann nur zugegriffen werden in:

• Nativer FTD-Modus (nicht Multi-Instance) CLISH im Expert-Modus in /opt/cisco/platform/logs/
• FTD-Fehlerbehebung im nativen Modus für Datei dir-archives/var-common-platform_ts/opt/cisco/platform/logs/
• Chassis-Fehlerbehebung für Dateien auf Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200 in /opt/cisco/platform/logs/
• Sicherheitsmodul show-tech file on Firepower 4100/9300 in /opt/cisco/platform/logs/

Um nach potenziellen Protokollen zu suchen, die mit einem Neustart in Zusammenhang stehen, suchen Sie nach Zeilen, die Schlüsselwörter wie Neustart, Neustart, Stromversorgung, Ausschalten, Neuladen enthalten. Beachten Sie, dass es sich hierbei um eine bestmögliche Methode handelt, da das Suchergebnis eine große Anzahl übereinstimmender Zeilen zurückgeben kann. Der Benutzer muss die entsprechenden Zeilen analysieren.

Beispiel 1:

admin@firewall:/opt/cisco/platform/logs$ grep -Ei "power|reboot|reload|restart|shut" *
...
npu_accel_fatal_err_stats.log:nic_top_inb_q_restart_drop_cnt = 0
npu_accel_fatal_err_stats.log:nic_top_norm_q_restart_drop_cnt = 0
npu_accel_fatal_err_stats.log:nic_top_inb_q_restart_drop_cnt = 0
npu_accel_mgr.log:2025 Oct 03 14:29:16 NPU ACCEL MGR: FATAL - NPU Accelerator FAILED - REBOOTING the device !!
npu_accel_mgr.log:2025 Oct 09 18:13:09 NPU ACCEL MGR: FATAL - NPU Accelerator FAILED - REBOOTING the device !!
npu_accel_mgr.log:2025 Oct 17 17:11:23 NPU ACCEL MGR: FATAL - NPU Accelerator FAILED - REBOOTING the device !!
npu_accel_mgr.log:2025 Oct 17 17:31:55 NPU ACCEL MGR: FATAL - NPU Accelerator FAILED - REBOOTING the device !!
npu_accel_mgr.log:2025 Oct 17 19:29:29 NPU ACCEL MGR: FATAL - NPU Accelerator FAILED - REBOOTING the device !!
ntp.log:27 Sep 02:21:16 ntpd[1580]: 0.0.0.0 c016 06 restart
ntp.log:27 Sep 02:23:27 ntpd[10193]: 0.0.0.0 c016 06 restart
...

In diesem Fall wurde der Neustart aufgrund des Ausfalls des Network Processing Unit (NPU) Accelerator der sicheren Firewall 4200 ausgelöst.

Analyse von SEL-/OBFL-Dateien

Dieser Abschnitt behandelt die Analyse der Dateien mit den Sicherheitsereignisprotokollen (SEL) und den integrierten Fehlerprotokollen (OBFL) der Firepower 4100/9300 Sicherheitsmodule.

Diese Dateien enthalten die Hardwareereignisse des Moduls und Änderungen des Leistungsstatus und befinden sich in der Fehlerbehebungsdatei für Firepower 4100/9300 in CIMC<X>_TechSupport/obfl/ und CIMC<X>_TechSupport/var/log/sel, wobei <X> für die Modulnummer steht.

Achten Sie auf Leitungen ohne Berücksichtigung der Groß-/Kleinschreibung: Stopp, Herunterfahren, Ausschalten, Zurücksetzen, Kritisch.

Beispiel 1:

2023 Sep 21 13:53:13:4.1(30b):cipmi:1088: [[xxxCVxxx]]:oem_command.c:457:IPMI Request Message --> Chan:15, Netfn:0x04, Cmd:0x02, Data: 0x41 0x03 0x20 0x46 0x6f 0xa1 0x61 0x74, CC:0x00
2023 Sep 21 13:53:13:4.1(30b):selparser:1203: [[xxxCVxxx]]:selparser.c:727: # A9 04 00 00 01 02 00 00 49 DA 0B 65 41 F0 04 20 46 00 00 00 6F A1 61 74 # 4a9 | 09/21/2023 13:53:13 AWST | System Mgmt Software | OS stop/shutdown #0x46 | Run-time critical stop |  | Asserted
2023 Sep 21 13:53:14:4.1(30b):cipmi:1088: peci.c:278:Error: Failed to read local PCI config after 3 retries! Completion Code error [PECI Dev=0x30,Resp=0x00,CC=0x80] Request Details: [pci_bus=0x02,pci_dev=0x0a,pci_fxn=0x03,pci_reg=0x104,length=0x04]
2023 Sep 21 13:53:15:4.1(30b):kernel:-:<5>[platform_reset_cb_handler]:75:Platform Reset ISR -> ResetState: 1
2023 Sep 21 13:53:15:4.1(30b):cipmi:1088: ocmds_intel_me.c:251:Intel ME Operating State:[M0 without UMA](5)
2023 Sep 21 13:53:15:4.1(30b):cipmi:1088: ocmds_intel_me.c:261:Intel ME is initializing.

Beispiel 2 - Herunterfahren auf Betriebssystemebene:

2025 Jul 30 23:31:02 UTC:4.1(30b):cipmi:1052: [[xxxCVxxx]]:oem_command.c:457:IPMI Request Message --> Chan:15, Netfn:0x04, Cmd:0x02, Data: 0x41 0x03 0x20 0x46 0x6f 0xa1 0x61 0x74, CC:0x00
2025 Jul 30 23:31:02 UTC:4.1(30b):selparser:1169: [[xxxCVxxx]]:selparser.c:727: # 48 03 00 00 01 02 00 00 36 AB 8A 68 41 F0 04 20 46 00 00 00 6F A1 61 74 # 348 | 07/30/2025 23:31:02 UTC | System Mgmt Software | OS stop/shutdown #0x46 | Run-time critical stop |  | Asserted
2025 Jul 30 23:31:04 UTC:4.1(30b):kernel:-:<5>[platform_reset_cb_handler]:75:Platform Reset ISR -> ResetState: 1
2025 Jul 30 23:31:05 UTC:4.1(30b):kernel:-:<4>[peci_ioctl]:293:non-responsive controller, resetting peci.  process = qpi_logger.
2025 Jul 30 23:31:05 UTC:4.1(30b):cipmi:1052: ocmds_intel_me.c:251:Intel ME Operating State:[M0 without UMA](5)
2025 Jul 30 23:31:05 UTC:4.1(30b):cipmi:1052: ocmds_intel_me.c:261:Intel ME is initializing.
2025 Jul 30 23:31:05 UTC:4.1(30b):information_logger:589: uptime.c:1219:Host Transition Ocurred. Event Count: 146. New state is "Power Off".

Beispiel 3 - Zurücksetzen des Baseboard Management Controllers aufgrund eines Watchdog:

2025 Jun 14 07:44:50 CDT:4.1(30b):kernel:-:<3>[watchdog_init]:487:BMC Watchdog resetted BMC.
2025 Jun 14 07:44:50 CDT:4.1(30b):kernel:-:<3>[watchdog_init]:489:BMC Watchdog System Bus Debug Status Registers: 0x0 and0x0
2025 Jun 14 07:44:50 CDT:4.1(30b):kernel:-:<3>[watchdog_init]:523:BMC Watchdog resetted BMC due to OOM.

Analyse der ASA-/FTD-Konsolenprotokolle

Dieser Abschnitt behandelt die Analyse der ASAConsole.log-Dateien, die Protokolle der Lina-Engine enthalten und auf Anzeichen von Software-Traceback oder Neustart überprüft werden können.

Die Datei enthält Protokolle zum Herunterfahren oder Neustarten für ASA/FTD auf virtuellen Plattformen, Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200 sowie Sicherheitsmodule für Firepower 4100 und 9300 (nicht das Gehäuse)

Auf die Datei kann nur zugegriffen werden in:

• FTD CLISH im Expert-Modus: /ngfw/var/log/ASAConsole.log
• FTD-Fehlerbehebungsdatei: dir-archives/opt-cisco-platform-logs/ASAConsole.log.
• Sicherheitsmodul-Fehlerbehebung für Datei auf Firepower 4100/9300: /opt/platform/logs/ASAConsole.log
• Chassis für Firepower 1000, 2100 und Secure Firewall 1200, 3100, 4200 - Technische Datei: /opt/platform/logs/ASAConsole.log

Symptome von Traceback und Generierung von Kerndateien:

root@KSEC-CSF1210-6:/ngfw/var/log# less ASAconsole.log
2025-08-09 01:06:11 /bin/grep: (standard input): Resource temporarily unavailable
2025-08-09 01:06:11 /bin/grep: (standard input): Resource temporarily unavailable
2025-08-09 01:06:11 /bin/grep: (standard input): Resource temporarily unavailable
2025-08-09 01:06:35 !! !! First Crash in tid: 14834 signo: 11
2025-08-09 01:06:35
2025-08-09 01:06:35 Writing live core file to flash. Please do not reload.
2025-08-09 01:06:35
2025-08-09 01:06:35 Coredump starting....
2025-08-09 01:06:35 Corehelper: /opt/cisco/csp/cores/core.lina.11.14550.1754701595
2025-08-09 01:06:35 Waiting for Corehelper to finish....
2025-08-09 01:06:35 Livecore: generating coredump of 14550
2025-08-09 01:06:35 [New LWP 14795]
2025-08-09 01:06:35 [New LWP 14796]
2025-08-09 01:06:35 [New LWP 14834]
2025-08-09 01:06:35 [New LWP 14835]
2025-08-09 01:06:35 [New LWP 14836]
2025-08-09 01:06:35 [New LWP 14869]
2025-08-09 01:06:35 [New LWP 14934]
2025-08-09 01:06:35 [New LWP 14939]
2025-08-09 01:06:35 [New LWP 14940]
2025-08-09 01:06:35 [New LWP 14941]
2025-08-09 01:06:35 [New LWP 14942]
2025-08-09 01:06:35 [New LWP 14943]
2025-08-09 01:06:35 [New LWP 14945]
2025-08-09 01:06:35 [New LWP 14947]
2025-08-09 01:06:35 [New LWP 14948]

 Symptome von Lina Motor Boot, beachten Sie die Lücke in der log-Zeitstempel:

root@KSEC-CSF1210-6:/ngfw/var/log# less ASAconsole.log
2024-11-13 22:43:09 INFO: SW-DRBG health test passed.
2024-11-13 22:43:09 M_MMAP_THRESHOLD 65536, M_MMAP_MAX 82155
2024-11-13 22:43:10 /bin/grep: (standard input): Resource temporarily unavailable
2024-11-13 22:43:10 /bin/grep: (standard input): Resource temporarily unavailable
2024-11-13 22:43:10 /bin/grep: (standard input): Resource temporarily unavailable
2024-11-13 22:43:10 /bin/grep: (standard input): Resource temporarily unavailable
2024-11-13 22:43:10 User enable_1 logged in to firepower
2024-11-13 22:43:10 Logins over the last 1 days: 1. 
2024-11-13 22:43:10 Failed logins since the last login: 0. 
2024-11-13 22:43:10 Type help or '?' for a list of available commands.
2024-11-13 22:43:10 ^Mfirepower>
2025-04-04 09:11:46 System Cores 8 Nodes 1 Max Cores 24
2025-04-04 09:11:46 Number of Cores 3
2025-04-04 09:11:46 IO Memory Nodes: 1
2025-04-04 09:11:46 IO Memory Per Node: 1073741824 bytes num_pages = 262144 page_size = 4096
2025-04-04 09:11:46
2025-04-04 09:11:46 Global Reserve Memory Per Node: 2147483648 bytes Nodes=1
2025-04-04 09:11:46
2025-04-04 09:11:46 LCMB: got DMA 1073741824 bytes on numa-id=0, phys=0x00000001c0000000, virt=0x0000400040000000
2025-04-04 09:11:46 LCMB: HEAP-CACHE POOL got 2147483648 bytes on numa-id=0, virt=0x0000400080000000
2025-04-04 09:11:46
2025-04-04 09:11:46 total_reserved_mem = 1073741824
2025-04-04 09:11:46
2025-04-04 09:11:46 total_heapcache_mem = 2147483648
2025-04-04 09:11:46 total mem 5384115842 system 16318316544 kernel 21847377 image 85732792
2025-04-04 09:11:46 new 5384115842 old 1159474616 reserve 3221225472 priv new 2184737747 priv old 0
2025-04-04 09:11:46 Processor memory:   5384115842
2025-04-04 09:11:46 POST started...
2025-04-04 09:11:46 POST finished, result is 0 (hint: 1 means it failed)
2025-04-04 09:11:46
2025-04-04 09:11:46 Cisco Adaptive Security Appliance Software Version 9.22(1)1

Analyse von Problemen mit der Stromspannung und dem Netzteil

Fahren Sie mit diesem Abschnitt fort, wenn im Abschnitt Gründe für das Zurücksetzen des Gehäuses analysieren Gründe für das Zurücksetzen gefunden wurden, wie diese:

• Einschalten
• PowerCycle-Anforderung
• Zurücksetzen aufgrund falscher Spannung
• Unbekannter Grund:

No time
    Reason: Unknown
    Service:
    Version:

Diese Gründe können auf potenzielle Probleme mit einer oder mehreren der folgenden Ursachen hinweisen:

• Engpässe bei der Stromversorgung
• Probleme mit den Netzteilen
• Probleme mit den Netzkabeln
• Probleme mit den Stromverteilereinheiten (PDU) im Rack
• Probleme mit dem Netzteil

Gehen Sie wie folgt vor:

1. Beantworten Sie die folgenden Fragen, um den Problembereich einzugrenzen:

• Handelt es sich bei dem Stromausfall um ein einmaliges oder wiederkehrendes Problem?
• Verfügt die Firewall über redundante Netzteile?
• Sind die Netzteile an verschiedene Stromquellen und/oder PDUs angeschlossen?
• Sind andere Geräte mit derselben Stromquelle und/oder demselben Netzteil verbunden?
• Gab es bei anderen Geräten, die an dieselbe Stromquelle und/oder PSU angeschlossen waren, ebenfalls Stromausfälle?

2. Wenn bei den Fragen aus dem ersten Schritt nur die Firewall betroffen ist, stellen Sie Folgendes sicher:

• Die Netzkabel sind fest mit der Stromquelle und dem Gehäuse verbunden.
• Netzkabel sind nicht beschädigt. Versuchen Sie, die Netzkabel auszutauschen, um potenzielle Probleme mit den Kabeln auszuschließen.
  
  

3. Wenn der Neustart des Gehäuses unerwartet fortgesetzt wird, nehmen Sie die Ausgabe dieser Befehle in FXOS einige Male zusammen:

scope chassis 1
show psu detail expand
scope psu 1
show stats history psu-stats detail expand
show stats psu-stats detail expand
exit
scope psu 2
show stats history psu-stats detail expand
show stats psu-stats detail expand

4. Sammeln Sie die Datei für die Chassis-Fehlerbehebung.

Referenzen 

1. FirePOWER-Softwareversionen überprüfen
2. Überprüfen der FirePOWER-, Instanz-, Verfügbarkeits- und Skalierbarkeitskonfiguration
3. Sammeln von Daten zur Ursachenanalyse von Software-Traceback/Absturz in einer sicheren Firewall
4. Fehlerbehebung bei FirePOWER-Verfahren zur Dateigenerierung