Fehlerbehebung bei Bereitstellungen von Firepower Threat Defense-Richtlinien
Inhalt
Einleitung
Dieses Dokument beschreibt einen allgemeinen Überblick über den Richtlinienbereitstellungsprozess für FTD sowie grundlegende Fehlerbehebungstechniken.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Firewall Management Center (FMC)Firepower Threat Defense (FTD)
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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.
Hintergrundinformationen
Mit Cisco Firepower Threat Defense (FTD) werden die herkömmlichen Stateful-Firewall-Funktionen von Adaptive Security Appliances (ASA) und Next-Gen Firewall-Funktionen (powered by Snort ) nun zu einem Produkt kombiniert. Aufgrund dieser Änderung übernimmt Policy Deployment Infrastructure FTD nun Konfigurationsänderungen sowohl für den ASA-Code (auch als LINA bezeichnet) als auch Snort in einem Paket.
Übersicht über die Richtlinienbereitstellung
Cisco FTD dient Policy Deployments zur Verwaltung und Ausgabe von Konfigurationen für Geräte, die beim Firewall Management Center (FÜZ) selbst registriert sind.
Innerhalb der Bereitstellung gibt es eine Reihe von Schritten, die in Phasen unterteilt sind.
Die FMC-Phasen können in dieser Liste zusammengefasst werden.
| Phase 0 | Initialisierung der Bereitstellung |
| Phase 1 | Datenbankobjektsammlung |
| Phase 2 | Richtlinien- und Objektsammlung |
| Phase 3 | NGFW - Befehlszeilenkonfiguration |
| Phase 4 | Paketgenerierung für die Gerätebereitstellung |
| Phase 5 | Senden und Empfangen des Bereitstellungspakets |
| Phase 6 | Ausstehende Meldungen zu Bereitstellung, Bereitstellungsaktionen und erfolgreichen Bereitstellungen |
Die Kenntnis der Phasen und des Standorts von Fehlern im Prozess kann bei der Fehlerbehebung für ein Firepower System helfen.
In einigen Situationen kann es sich um einen Konflikt aufgrund früherer Konfigurationen handeln oder um einen Fehler, der durch ein fehlendes Schlüsselwort verursacht werden kann und Fehler verursachen kann, Advanced Flex Configuration die im Gerätebericht nicht behandelt werden.
Beispielübersicht
Schritt 1. Klicken Sie auf Deployment, um das auszuwählende Gerät anzugeben.
Schritt 2: Wenn die Bereitstellung für ein Gerät bestätigt wird, beginnt das FMC mit der Erfassung aller für das Gerät relevanten Konfigurationen.
Schritt 3: Wenn die Konfigurationen erfasst werden, erstellt das FMC das Paket und sendet es über seinen Kommunikationsmechanismus SFTunnel an den Sensor.
Schritt 4: Das FMC benachrichtigt den Sensor, den Bereitstellungsprozess mit der bereitgestellten Richtlinie zu starten, während es die einzelnen Antworten abhört.
Schritt 5: Das verwaltete Gerät entpackt das Archiv und beginnt mit der Anwendung der einzelnen Konfigurationen und Pakete.
A.: Die erste Hälfte der Bereitstellung betrifft die Snort Konfiguration, in der die Snort Konfiguration lokal getestet wird, um ihre Gültigkeit sicherzustellen.
Wenn sich herausstellt, dass die neue Konfiguration gültig ist, wird sie in das Produktionsverzeichnis verschoben. Wenn die Validierung fehlschlägt, schlägt die Snort. Richtlinienbereitstellung in diesem Schritt fehl.
B. Die zweite Hälfte der Bereitstellungspaketlast betrifft die LINA-Konfiguration, in der sie vom ngfwManager-Prozess direkt auf den LINA-Prozess angewendet wird.
Wenn ein Fehler auftritt, werden die Änderungen zurückgesetzt, und es tritt ein Fehler bei der Richtlinienbereitstellung auf.
Schritt 6: Wenn beide Snort und LINA-Pakete erfolgreich sind, signalisiert das verwaltete Gerät einen Neustart oder ein erneutes Laden, Snort um die neue Konfiguration zu laden und alle aktuellen Konfigurationen zu speichern.
Schritt 7: Wenn alle Meldungen erfolgreich sind, sendet der Sensor eine Erfolgsmeldung und wartet darauf, dass diese vom Management Center bestätigt wird.
Schritt 8: Nach Eingang markiert das FMC die Aufgabe als erfolgreich und ermöglicht das Fertigstellen des Richtlinienpakets.
Fehlerbehebung
Probleme, die während auftreten, Policy Deployment können auf Folgendes zurückzuführen sein:
- Fehlkonfiguration
- Kommunikation zwischen FMC und FTD
- Datenbank- und Systemstatus
- Softwarefehler und Hinweise
- Andere spezielle Situationen
Einige dieser Probleme können problemlos behoben werden, während andere die Unterstützung durch Cisco Technical Assistance Center (TAC)benötigen.
In diesem Abschnitt sollen Verfahren zur Isolierung des Problems und zur Ermittlung der Ursache beschrieben werden.
Grafische Benutzeroberfläche (GUI) von FMC
Cisco empfiehlt für Bereitstellungsfehler, jede Fehlerbehebungssitzung auf der FMC-Appliance zu starten.
Im Fehlerbenachrichtigungsfenster gibt es für alle Versionen nach 6.2.3 zusätzliche Tools, die bei anderen möglichen Fehlern helfen können.
Verwendung der Bereitstellungsprotokolle
Schritt 1: Aufrufen der Deployments Liste auf der FMC-Webbenutzeroberfläche.
Schritt 2: Klicken Sie bei ausgewählter Deployments Registerkarte auf Show History.
Schritt 3: Im Deployment History Feld werden alle früheren Bereitstellungen Ihres FMC angezeigt. Wählen Sie die Bereitstellung aus, in der Sie weitere Daten anzeigen möchten.
Schritt 4: Nachdem ein Bereitstellungselement ausgewählt wurde, wird in der Deployment Details Auswahl eine Liste aller Geräte innerhalb des Transactionangezeigt. Diese Einträge werden in folgende Spalten unterteilt: Device Number, Device Name, Status,und Transcript.
Schritt 5: Wählen Sie das betreffende Gerät aus, und klicken Sie auf die Transkript-Option, um das individuelle Bereitstellungsprotokoll anzuzeigen, das Sie über Fehler und Konfigurationen auf den verwalteten Geräten informieren kann.
Schritt 6. Dieses Transkript kann bestimmte Fehlerbedingungen festlegen und eine sehr wichtige Zahl für den nächsten Schritt angeben: Transaction ID.
Schritt 7: In einer Firepower Deploymentwird Transaction ID festgelegt, wie die einzelnen Abschnitte einer Richtlinienbereitstellung nachverfolgt werden können. Auf diese Weise können Sie über die Befehlszeile des Geräts eine detailliertere Version dieser Daten für die Sanierung und Analyse abrufen.
Fehlerbehebung mit FMC-Protokollen
Es ist zwar angemessen, das Cisco TAC für die Analyse der Protokolle zu beauftragen, eine Suche in den Protokollen kann jedoch bei der anfänglichen Problemisolierung und der schnelleren Behebung helfen. Es gibt mehrere Protokolldateien auf FMC, in denen die Details des Richtlinienbereitstellungsprozesses aufgezeigt werden.
Die beiden am häufigsten genannten Protokolle sind policy_deployment.log und usmsharedsvcs.log.
Alle in diesem Dokument erwähnten Dateien können mit mehreren Linux-Befehlen angezeigt werden, z. B. more, less und vi. Es ist jedoch sehr wichtig, sicherzustellen, dass nur read Aktionen ausgeführt werden. Alle Dateien benötigen Root-Zugriff, um sie anzeigen zu können.
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
Dieses Protokoll kennzeichnet den Beginn der Richtlinienbereitstellungsaufgabe auf dem FMC und den Abschluss jeder Phase. So kann festgestellt werden, in welcher Phase die Bereitstellung fehlschlug, und der Fehlercode angegeben werden.
Der transactionID im JSON-Teil des Protokolls enthaltene Wert kann verwendet werden, um Protokolleinträge zu finden, die sich auf einen bestimmten Bereitstellungsversuch beziehen.
10-May-2024 18:05:31.249,[INFO],(JsonRESTServerResource.java:111)
com.cisco.nm.vms.api.rest.DeploymentServerResource, ajp-nio-127.0.0.1-9009-exec-3
** REST Request [ DC ]
** ID : e45c6abd-0fff-4341-bdad-ddd5fee10034
** URL: POST https://localhost6/csm/api/deploy/GetTranscript
{
"data": {},
"deviceUUID": "49243dac-0ba7-11ef-af54-a592d78081a7",
"jobID": 34359753974,
"offset": {
"size": 20,
"start": 0
},
"requestID": "e3be908a0ef711ef9d519da21f9032fa",
"version": "7.2.5"
}
/var/log/sf/policy_deployment.log
Diese Protokolldatei existiert bereits in 6.x Versionen, die bei 6.4 beginnen, aber ihre Abdeckung wurde erweitert.
Es beschreibt nun die detaillierten Schritte, die von FMC zur Erstellung der Bereitstellungspakete unternommen wurden. Daher wird es am besten für die Analyse von Ausfällen aus Phase 1 - 4 verwendet.
Der Beginn jeder Phase ist durch eine Linie mit INFO start.
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: > SF::UMPD::CSMData::getPolicyRollbackInfo start (161.32M)
May 8 02:00:58 RTP-vFMC-Pod-09 ActionQueueScrape.pl[10413]: < SF::UMPD::CSMData::getPolicyRollbackInfo end (161.32M, 0.012(sec))
...
Fehlerbehebung für verwaltete Geräte
Es gibt weitere Phasen und Abschnitte, die vom Gerätepaket, der Hochverfügbarkeitskonfiguration und dem Ergebnis früherer Phasen für jedes verwaltete Gerät abhängen.
Wenn ein Bereitstellungsproblem auf einen Fehler auf dem verwalteten Gerät zurückgeführt wird, kann eine weitere Fehlerbehebung auf dem Gerät mit zwei Protokollen auf dem Gerät durchgeführt werden: policy_deployment.log und ngfwManager.log.
/ngfw/var/log/ngfwManager.log
Diese Protokolldatei enthält detaillierte Schritte, die von Config Communication Manager und Config Dispatcher für die Kommunikation mit FMC, die Arbeit mit dem Bereitstellungspaket und die Orchestrierung der Validierung und Anwendung von Snort- und LINA-Konfigurationen durchgeführt wurden.
Dies sind einige Beispiele für ngfwManager.log, die den Beginn der Hauptphasen darstellen:
FTD receives FMC's request for running configuration: May 30 16:37:10 ccm[4293] Thread-10: INFO com.cisco.ccm.ConfigCommunicationManager- Passing CD-Message-Request to Config Dispatcher... May 30 16:37:10 ccm[4293] Thread-10: DEBUG com.cisco.ccm.ConfigCommunicationManager- <?xml version="1.0" encoding="UTF-8"?><cdMessagesList><timeStamp>1559234230012</timeStamp><cdMessage><name>LinaShowCommand</name><messageId>-753133537443151390</messageId><contentType>XML</contentType><msgContent><![CDATA[<?xml version="1.0" encoding="UTF-8"?><message><name>LinaShowCommand</name>... FTD receives FMC's request to download the deployment package: May 30 16:37:18 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Downloading database (transaction 8589938211, version 1559234236) May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- handle record: 8589938211, status = PENDING May 30 16:37:18 ccm[4293] Thread-9: DEBUG com.cisco.ccm.DownloadManager- begin downloading database FTD begins the deployment of policy changes: May 30 16:37:21 ccm[4293] Thread-9: INFO com.cisco.ccm.ConfigCommunicationManager- Starting deployment May 30 16:37:21 ccm[4293] Thread-11: INFO com.cisco.ccm.ConfigCommunicationManager- Sending message: DEPLOYMENT_STATUS_CCM to Manager FTD begins LINA deployment: May 30 16:37:42 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Trying to send Start-Config-Sequencerequest to lina FTD begins finalizing the deployment: May 30 16:38:48 ccm[4293] Thread-19: DEBUG com.cisco.ngfw.configdispatcher.communicators.LinaCommunicatorImpl- Clustering Message sent out of ConfigDispatcher: Name:Cluster-App-Conf-Finalize-Request
/ngfw/var/log/sf/policy_deployment.log
Dieses Protokoll enthält die Details der auf angewendeten Richtlinie. Snort. Obwohl der Inhalt des Protokolls größtenteils fortgeschritten ist und eine Analyse durch das TAC erfordert, ist es dennoch möglich, den Prozess mit einigen Schlüsseleinträgen zu verfolgen:
Config Dispatcher begins extracting the packaged policies for validation: Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::exportDeviceSnapshotToSandbox (Plugin 230 <- Framework 611 <- Transaction 1085) Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO found NGFWPolicy => (NGFWPolicy::Util 32 <- NGFWPolicy::Device 43 <- Plugin 235) ... Jul 18 17:20:57 firepower policy_apply.pl[25122]: INFO export FTD platform settings... (PlatformSettings::FTD::Device 29 <- Plugin 235<339 <- PlatformSettings::Device 13) Config validation begins: Jul 18 17:21:37 firepower policy_apply.pl[25122]: INFO starting validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files (memory = 229.99 MB) (Framework 3950<687 <- Transaction 1101 <- main 194) Validation has completed successfully: Jul 18 17:21:49 firepower policy_apply.pl[25122]: INFO validateExportedFiles - sqlite = /var/cisco/deploy/sandbox/policy_deployment.db, sandbox = /var/cisco/deploy/sandbox/exported-files took 12 (memory = 238.50 MB, change = 8.51 MB) (Framework 3976<724 <- Transaction 1101 <- main 194) Config Dispatcher begins moving the validated configuration to the Snort directories in production: Jul 18 17:21:54 firepower policy_apply.pl[26571]: INFO -> calling SF::UMPD::Plugins::NGFWPolicy::Device::publishExportedFiles (Plugin 230 <- Framework 822 <- Transaction 1662) Snort processes will reload to apply the new configurations: Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO Reconfiguring DE a3bcd340-992f-11e9-a1f1-ac829f31a4f9... (Snort::SnortNotifications 292<154 <- Snort::Device 343 <- Plugin 235) Jul 18 17:22:02 firepower policy_apply.pl[26571]: INFO sending SnortReload to a3bcd340-992f-11e9-a1f1-ac829f31a4f9 (Snort::SnortNotifications 298<154 <- Snort::Device 343 <- Plugin 235) Snort reload has completed successfully: Jul 18 17:22:14 firepower policy_apply.pl[26571]: INFO notifyProcesses - sandbox = /var/cisco/deploy/sandbox/exported-files took 16 (memory = 169.52 MB, change = 16.95 MB) (Framework 3976<964 <- Transaction 1680 <- main 200) After LINA config apply finishes, Snort deployment is finalized: Jul 18 17:23:32 firepower policy_apply.pl[26913]: INFO starting finalizeDeviceDeployment - sandbox = /var/cisco/deploy/sandbox (memory = 101.14 MB) (Framework 3950<980 <- Transaction 1740 <- main 206)
Beispiel
Schritt 1: Eine Bereitstellung schlägt fehl.
Schritt 2: Rufen Sie das Deploy Transcript und Transaction ID.
Schritt 3. SSH in Ihre Management Center und nutzen Sie das Linux-Dienstprogramm, less um die Datei zu lesen, wie auf Ihrem FMC gezeigt:
Beispiel: sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log (Das sudo-Kennwort ist Ihr Benutzerkennwort für ssh.)
Schritt 4: Wenn Sie den Schrägstrich weiterleiten less, verwenden und die Nachrichten-ID eingeben, um nach Protokollen zu suchen, die sich auf die Bereitstellungstransaktions-ID beziehen.
Beispiel: /60129547881 (Während derless, Verwendung von n zum Navigieren zum nächsten Ergebnis.)
Beispiel einer ausgeführten Nachricht
Beispiel einer Fehlermeldung
5) Vergleichen Sie den ordnungsgemäßen Fehler mit der beigefügten Tabelle mit häufigen Fehlermeldungen.
Das heißt, failed_to_restore_running_configuration tritt bei Kommunikationsfehlern zwischen den beiden Geräten auf.
Häufige Fehlermeldungen
Dabei handelt es sich sowohl um gängige Fehlermeldungen, die am Front-End der Management Center Task als auch im Backend zu sehen sind.
Diese Meldungen können analysiert und mit den gängigen Gründen für mögliche Lösungen verglichen werden. Falls diese nicht erkannt werden oder sich Ihre Situation nicht beheben lässt, wenden Sie sich bitte an das TAC.
----------------------------------------------------------------------------------------
| Fehlercode |
Fehlermeldungen |
Grund |
|
|
Bereitstellungsfehler - Das Gerät hat die Domäne geändert. von {SRCDOMAIN} bis {DESTINATIONDOMAIN}. Versuchen Sie es später erneut. |
Dieser Fehler tritt in der Regel dann auf, wenn ein Gerät in eine zweite Domäne verschoben oder daraus entfernt wurde. Eine erneute Bereitstellung ohne domänenübergreifende Informationen ändert dieses Problem in der Regel. |
|
|
Fehler bei der Bereitstellung aufgrund einer anderen Bereitstellung für dieses Gerät. Versuchen Sie es später erneut. |
Dies wird in der Regel gemeldet, wenn die Bereitstellung auf einem bereitzustellenden Gerät ausgelöst wird. In einigen Versionen wird dies ohne Fehlermeldung verhindert. Diese Phase besteht jedoch weiterhin für die Fehlerbehebung. |
|
|
Die Bereitstellung kann nicht auf einem einzelnen Gerät durchgeführt werden, das zu einem Cluster gehört. Versuchen Sie später erneut, den Cluster bereitzustellen. |
Diese Meldung gilt für FTD auf Geräten mit dem FirePOWER eXtensible Operative System (FXOS) Chassis Manager. Wenn der Cluster auf FXOS, jedoch nicht auf dem FMC basiert, wird diese Meldung angezeigt. Erstellen Sie den Cluster auf der Management Center-Appliance, bevor Sie versuchen, ihn bereitzustellen. |
|
|
Richtlinien für ein oder mehrere Geräte wurden seit {TIMESTAMP} geändert. Wiederholen Sie die Bereitstellung. |
Dieser Fehler wird angezeigt, wenn eine Richtlinie oder ein Objekt für ein Gerät im Bereitstellungsauftrag geändert wird, nachdem der Benutzer die Bereitstellung ausgelöst hat und bevor CSM-Elemente und Domänen-Snapshots erstellt werden. Eine erneute Bereitstellung behebt dieses Problem. Dies kann der Fall sein, wenn viele Benutzer dasselbe FMC verwenden, um Objekte zu bearbeiten und zu speichern, während sie bereitgestellt werden. |
|
|
Die Richtlinie {Policy Name} wurde seit {Timestamp} geändert. Wiederholen Sie die Bereitstellung. |
Dieser Fehler wird angezeigt, wenn im Bereitstellungsauftrag eine Richtlinie oder ein Objekt für das betreffende Gerät geändert wird, nachdem der Benutzer die Bereitstellung ausgelöst hat und bevor CSM- und Domänen-Snapshots erstellt werden. Eine erneute Bereitstellung behebt dieses Problem. |
|
|
Fehler bei der Bereitstellung aufgrund eines Fehlers bei der Zusammenstellung von Richtlinien und Objekten. Wenn das Problem nach einem wiederholten Versuch weiterhin besteht, wenden Sie sich an das Cisco TAC. |
Wenn ein aktueller Policy Import bereitgestellt wurde, warten Sie etwa eine Stunde und versuchen Sie eine andere Bereitstellung. |
|
|
Fehler bei der Bereitstellung aufgrund eines Timeouts beim Erfassen von Richtlinien und Objekten. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Standardmäßig hat der Domänen-Snapshot eine Zeitüberschreitung von 5 Minuten. Steht das System unter hoher Auslastung oder kommt es zu einem Ausfall des Hypervisors, kann dies zu unnatürlichen Verzögerungen des Anrufs führen. Dies kann der Fall sein, wenn das Management Center oder das Gerät nicht über die entsprechende Menge an Speicherressourcen verfügt. Wenn dies ohne Last geschieht oder zu einem späteren Zeitpunkt nicht mehr geschieht, wenden Sie sich an das TAC. |
|
|
Fehler bei der Bereitstellung in Richtlinien- und Objektauflistung. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
TAC kontaktieren. Eine erweiterte Fehlerbehebung ist erforderlich. |
|
|
Fehler bei der Bereitstellung, da die Informationen zur Ausführungskonfiguration nicht vom Gerät abgerufen werden konnten. Wiederholen Sie die Bereitstellung. |
Diese Meldung kann auftreten, wenn die Verbindung zwischen einem Endsensor und einem FMC nicht wie erwartet funktioniert. Überprüfen Sie den Tunnelzustand zwischen den Geräten, und überwachen Sie die Verbindung zwischen den beiden Geräten. |
|
|
Fehler bei der Bereitstellung, da das Gerät eine vorherige Bereitstellung oder einen Neustart ausführen kann. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Diese Meldung wird angezeigt, wenn das FMC eine Bereitstellung versucht, während auf FTD eine vorherige Bereitstellung läuft. Tritt in der Regel auf, wenn eine vorherige Bereitstellung auf FTD noch nicht abgeschlossen ist und die FTD neu gestartet wurde oder der ngfwManager-Prozess auf FTD neu gestartet wurde. Ein Wiederholungsversuch nach 20 Minuten, um eine formelle Zeitüberschreitung für Prozesse zu ermöglichen, muss dieses Problem lösen. Wenn die Verzögerung nicht akzeptabel ist, wenden Sie sich an das TAC. |
|
|
Die Bereitstellung schlug aufgrund von Verbindungsproblemen mit dem Gerät fehl, oder das Gerät reagiert nicht. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
FMC gibt bestimmte LINA show-Befehle aus, um die aktuelle Konfiguration zur Konfigurationsgenerierung abzurufen. Dies kann passieren, wenn es Verbindungsprobleme oder Probleme mit dem ngfwManager-Prozess auf dem Endsensor gibt. Wenden Sie sich an das TAC, falls keine Verbindungsprobleme zwischen Ihren Einheiten auftreten. |
|
|
Fehler bei der Bereitstellung aufgrund eines Kommunikationsfehlers mit dem Gerät. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
tritt in der Regel bei hoher Netzwerklatenz zwischen den Geräten auf, um ein Timeout für Richtlinien zu verursachen. Überprüfen Sie die Netzwerklatenz zwischen den Geräten, um sicherzustellen, dass sie mit den Mindestwerten für die im Benutzerhandbuch genannte Version übereinstimmt. |
|
|
Fehler bei der Bereitstellung, da die Clusterkonfigurationssynchronisierung ausgeführt wird. Wiederholen Sie die Bereitstellung. |
Dies gilt nur für FTD-Cluster-Konfigurationen. Wenn eine Bereitstellung auf einem FTD-Cluster versucht wird, während eine App-Synchronisierung (Konfigurationssynchronisierung) durchgeführt wird, wird diese von FTD abgelehnt. Ein Wiederholungsversuch nach der Konfigurationssynchronisierung muss dieses Problem lösen. Der aktuelle Cluster-Status kann mit diesem Befehl in der CLISH des verwalteten Geräts verfolgt werden: > Clusterinformationen anzeigen |
| asa_configuration_generation_errors |
Fehler beim Generieren der Gerätekonfiguration durch die Bereitstellung. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Nach der Überprüfung der USMS-Protokolle, die zuvor erwähnt wurden, können Sie sehen, welche Konfiguration den Fehler verursacht. In der Regel handelt es sich hierbei um Bugs, bei denen die Protokolle mithilfe des Cisco Bug-Tools durchsucht werden können. Alternativ können Sie sich zur weiteren Fehlerbehebung an das Cisco TAC wenden. |
|
|
Fehler bei der Bereitstellung, da die Schnittstellen auf dem Gerät veraltet sind. Speichern Sie die Konfiguration auf der Schnittstellenseite, und wiederholen Sie den Vorgang. |
Dies ist bei 4100- oder 9300-Modellen der Fall, wenn die Zuordnung der Schnittstelle zum Gerät während oder direkt vor einer Bereitstellung aufgehoben wird. Überprüfen Sie, ob die Schnittstelle vollständig zugeordnet oder nicht zugeordnet ist, bevor Sie die Bereitstellung versuchen. |
|
|
Fehler beim Generieren der Konfiguration für das Gerät. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Dieser Fehler zeigt an, dass die Gerätekonfiguration für das Gerät nicht generiert werden konnte. TAC kontaktieren. |
|
|
Fehler bei der Bereitstellung aufgrund eines Timeouts während der Konfigurationsgenerierung. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Dies kann der Fall sein, wenn die Latenz zwischen den Geräten über den normalen Bereich hinausgeht. Wenden Sie sich an das TAC, wenn das Problem auch nach der Normalisierung der Latenz weiterhin auftritt. |
|
|
Fehler bei der Bereitstellung aufgrund eines Fehlers bei der Gerätekommunikation. Überprüfen Sie die Netzwerkverbindung, und wiederholen Sie die Bereitstellung. |
Diese Nachricht ist der Fallback für alle Kommunikationsprobleme zwischen den Geräten. Aufgrund seiner Ungenauigkeit wird es als Fallback geschrieben, um anzugeben, dass ein unbekannter Verbindungsfehler aufgetreten ist. |
|
|
Fehler bei der Richtlinienbereitstellung. Wiederholen Sie die Bereitstellung. |
Ein weiterer Versuch muss dieses Problem lösen. Dies kann der Fall sein, wenn das FMC die Bereitstellung aufgrund einer temporären Sperre der Datenbank nicht starten kann. |
|
|
Die Bereitstellung auf dem Gerät ist aufgrund eines Timeouts fehlgeschlagen. Wiederholen Sie die Bereitstellung. |
Dies bezieht sich auf FTD-Bereitstellungen. Die Prozesse auf FTD warten 30 Minuten, bis der Dispatch die Bereitstellung abgeschlossen hat. Wenn nicht, wird die Zeit knapp. In diesem Fall überprüfen Sie die Verbindung zwischen den Geräten, und wenden Sie sich an das TAC, wenn die Verbindung erwartungsgemäß hergestellt wurde. |
|
|
Fehler bei der Bereitstellung aufgrund einer Zeitüberschreitung beim Herunterladen der Konfiguration auf das Gerät. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Dies bezieht sich auf FTD-Bereitstellungen. Aufgrund von Verbindungsproblemen kann die FTD während der Bereitstellung nicht alle Gerätekonfigurationsdateien herunterladen. Versuchen Sie es erneut, nachdem die Netzwerkverbindung überprüft wurde. Wenn dies überprüft wurde, wenden Sie sich an das TAC. |
|
|
Fehler bei der Bereitstellung aufgrund eines Konfigurationsfehlers. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Alle Fehler in der Konfiguration, die von FMC für das Gerät generiert werden, müssen nach dem Auftreten dieses Fehlers auftreten. Dies muss in den USMS-Protokollen analysiert werden, um festzustellen, welche Probleme aufgetreten sind, und um ein Rollback zu versuchen. Nach der Reparatur sind in der Regel ein TAC-Eingriff und die Erstellung eines Bugs erforderlich, wenn die Protokolle nicht mit einem bekannten Fehler im Cisco Bug Search Tool abgeglichen werden können. |
|
|
Fehler bei der Bereitstellung aufgrund eines Timeouts für die Kommunikation mit dem Gerät. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Diese Zeitüberschreitung tritt auf, wenn das FMC nach ≤ 45 Minuten noch keine Rückmeldung von einem Gerät erhalten hat. Dies ist ein Kommunikationsfehler. Kommunikation überprüfen und falls verifiziert, TAC kontaktieren. |
|
|
Fehler bei der Bereitstellung im Cluster, da sich die primäre Einheit geändert hat. Wiederholen Sie die Bereitstellung. |
Wenn bei einer FTD-Cluster-Einrichtung der Primärknoten bei laufender Bereitstellung auf dem Gerät wechselt (nach Benachrichtigung), wird dieser Fehler angezeigt. Wiederholen Sie den Vorgang, sobald der Primärknoten stabil ist. Der aktuelle Cluster-Mitgliederstatus kann mit diesem Befehl in der CLISH des verwalteten Geräts verfolgt werden: > Clusterinformationen anzeigen |
|
|
Fehler bei der Bereitstellung für den Cluster aufgrund eines Fehlers bei der Identifizierung der primären Einheit. Wiederholen Sie die Bereitstellung. |
FMC konnte den aktuellen Primärknoten während der Bereitstellung nicht ermitteln. Dies liegt typischerweise an den folgenden Möglichkeiten: Verbindungsprobleme oder aktuelle primäre Fehler werden dem Cluster auf dem FMC nicht hinzugefügt. Dieser Fehler muss behoben werden, nachdem die Verbindung wiederhergestellt wurde oder nachdem der aktuelle primäre Cluster zum FMC-Cluster hinzugefügt wurde und ein erneuter Versuch durchgeführt wurde. Der aktuelle Cluster-Status kann mit diesem Befehl in der CLISH des verwalteten Geräts verfolgt werden: > Clusterinformationen anzeigen |
|
|
Fehler bei der Bereitstellung, da die Clusterkonfigurationssynchronisierung ausgeführt wird. Wiederholen Sie die Bereitstellung. |
Dies kann passieren, wenn sich das Gerät in der App-Synchronisierung befindet. Wenn die App-Synchronisierung abgeschlossen ist, wiederholen Sie die Bereitstellung erneut. |
|
|
Fehler bei der Bereitstellung aufgrund eines Konflikts mit der gleichzeitigen vorherigen Bereitstellung. Wenn das Problem nach einem weiteren Versuch weiterhin besteht, wenden Sie sich an Cisco TAC. |
Dies kann auftreten, wenn eine Bereitstellung auf einer Seite gleichzeitig ausgeführt wird, auf der anderen Seite jedoch nicht. Diese werden in der Regel durch Kommunikationsprobleme zwischen den Geräten verursacht. Wenn die Zeitüberschreitung auftritt und Sie die Bereitstellung weiterhin nicht durchführen können, wenden Sie sich an das TAC. |
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
02-Sep-2026
|
Rezertifizierung - Aktualisierte Formatierung |
3.0 |
13-May-2024
|
Rezertifizierung |
2.0 |
23-Sep-2022
|
Erstveröffentlichung |
1.0 |
17-Feb-2020
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)