排除Firepower威脅防禦策略部署故障

下載選項

  • PDF     (1.0 MB)
    在多種裝置上使用 Adobe Reader 檢視
已更新: 2026 年 9 月 2 日
文件 ID:215258

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案將簡要概述FTD上的原則部署流程和基本疑難排解技術。 

必要條件

需求

思科建議您瞭解以下主題：

  • Firewall Management Center (FMC)
  • Firepower Threat Defense (FTD)

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

若使Cisco Firepower Threat Defense 用(FTD),Adaptive Security Appliances Next-Gen(ASA)提供的傳統狀態防火牆功能和(由Snort ASA提供支援的)防火牆功能現在將組合到一個產品中。由於此變更，Policy Deployment InfrastructureFTD上現在會處理兩個ASA代碼（也稱為LINA）和一個捆綁包的配置更Snort改。 

策略部署概述

Cisco FTD利用Policy Deployments來管理和推出已註冊到(FMC)本身Firewall Management Center的裝置組態。

在部署中，有一系列步驟分為多個階段。

FMC階段可總結在此清單中。

第0階段 部署初始化
第1階段 資料庫對象集合
第2階段 策略和對象集合
第3階段 NGFW命令列配置生成
第4階段 生成裝置部署包
第5階段 傳送和接收部署包
第6階段 待處理的部署、部署操作和部署成功消息

瞭解流程中的階段和故障位置有助於排除系統面臨的Firepower故障。

在某些情況下，衝突可能是由於先前的配置或缺少關鍵字引起的，該關鍵字可能導致裝置報告無法解決的故障Advanced Flex Configuration。

示例概述

步驟1.按一下Deployment以指定要選擇的裝置。

步驟2.提交裝置部署後，FMC開始收集與該裝置相關的所有配置。 

步驟3.收集配置後，FMC會建立包並通過其稱為SFTunnel的通訊機制將其傳送到感測器。

步驟4. FMC在偵聽單個響應時通知感測器使用提供的策略啟動部署過程。

步驟5.受管裝置開啟歸檔檔案包，並開始應用各個配置和檔案包。

A.部署的前半部分是在本地測Snort試配置Snort以確保其有效性的配置。

當證明有效時，新配置將移動到生產目錄Snort.中。如果驗證失敗，則策略部署在此步驟中失敗。

B.部署包負載的第二半部分用於LINA配置，在該配置中它由ngfwManager進程直接應用於LINA進程。

如果發生故障，更改將回退並且策略部署發生故障。

步驟6.如果和SnortLINA包都成功，受管裝置將發出訊號重新啟動或重新載入，以便載入新配置並儲存所有當前配置Snort。

步驟7.如果所有消息均成功，感測器將傳送成功消息，並等待管理中心確認該消息。

步驟8.收到任務後，FMC將任務標籤為成功並允許完成策略包。

疑難排解

期間遇到Policy Deployment的問題可能是由於（但不限於）：

  1. 組態錯誤
  2. FMC和FTD之間的通訊
  3. 資料庫和系統運行狀況
  4. 軟體缺陷和警告
  5. 其他特殊情況

其中一些問題可以輕鬆解決，而另一些問題則需要思科的協Technical Assistance Center (TAC)助。

本節的目的是提供隔離問題或確定根本原因的技術。 

FMC圖形使用者介面(GUI) 

思科建議在FMC裝置上啟動每個部署失敗的故障排除會話。

在故障通知視窗中，在6.2.3以上的所有版本上，還有其它工具可以協助處理其他可能的故障。 

利用部署記錄

步驟1.上拉FMC Web DeploymentsUI上的清單。

步驟2.選中該Deployments頁籤後，按一下Show History它。


Select Deployments Tab, Click Show History

步驟3.在框中Deployment History，您可以看到來自FMC的所有先前部署。選擇要檢視更多資料的部署。


步驟4.選擇部署元素後，該選Deployment Details擇將顯示其中所有裝置的列Transaction表。這些條目被細分為以下幾列：Device Number, Device Name, Status,和 Transcript.


Deployment Details



步驟5.選擇有問題的裝置，然後按一下transcript選項檢視單個部署指令碼，該指令碼可以通知您託管裝置上的故障和配置。

 Transcript Details



步驟6.該記錄可以指定某些故障條件，並為下一步指明一個非常重要的編號：Transaction ID.

Transcript Designates Transaction



步驟7.在中Firepower Deployment是可Transaction ID用於跟蹤策略部署的每個單獨部分的內容。這樣，您就可以在裝置的命令列上獲取此資料的更深入版本，以進行補救和分析。

提示：如果找不到事務ID，或者您使用的是列印之前的版本，則此日誌仍可用於查詢單個失敗消息。

FMC日誌故障排除

儘管與Cisco TAC合作分析日誌是合適的，但搜尋日誌有助於初步隔離問題並加快解決速度。FMC上有多個日誌檔案，顯示有關策略部署過程的詳細資訊。

兩個最常引用的日誌是policy_deployment.log和usmsharedsvcs.log。

本文檔中提到的所有檔案都可以使用多個Linux命令進行檢視，more例如less和vi。但是，確保僅對其執行操作read是非常重要的。所有檔案都需要root訪問許可權才能檢視它們。

/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log

此日誌清楚地標籤FMC上的策略部署任務的開始和每個階段的完成，這有助於確定部署發生故障的階段以及故障代碼。

日誌transactionID的JSON部分中包含的值可用於查詢與某一特定部署嘗試相關的日誌條目。

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

儘管此日誌檔案在從6.4開始的6.x版本中一直存在，但其覆蓋範圍已擴展。

現在它描述了FMC構建部署軟體包的詳細步驟，因此最好將其用於分析階段1 - 4中的故障。

每個階段的開始都標有一行，其格式為 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))
...

受管裝置故障排除

還有其他一些階段和部分，具體取決於裝置軟體包、高可用性配置，以及每個受管裝置的先前階段的結果。

如果部署問題被隔離為受管裝置上的故障，則可以在裝置上執行進一步的故障排除，該裝置上具有兩個日誌：policy_deployment.log和ngfwManager.log。

/ngfw/var/log/ngfwManager.log

此日誌檔案提供了由FMC採取的詳細步驟以及與FMC進行通Config Communication ManagerConfig Dispatcher、使用部署包以及協調Snort和LINA配置的驗證和應用。

下面是ngfwManager.log的幾個示例，它們代表主要階段的開始：

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

此日誌包含應用於的策略的詳細資訊。儘管日誌的內容大多是高級的，並且需要TAC分析，但仍可以使用以下幾個關鍵條目跟蹤該進程Snort.:

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)

範例

步驟1.部署失敗。

A Deployment Fails

 

 

 

步驟2.獲取和Deploy TranscriptURL Transaction ID.

Obtain the Deploy Transcript and Transaction ID

 

步驟3.通過SSH進入Management Center並使用Linux實用程式less讀取檔案，如FMC中所示：

範例：sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log（sudo密碼是您的ssh使用者密碼。）

Utilize the Linux Utility Less

步驟4.使用正less,斜槓時，輸入消息ID以搜尋與部署事務ID相關的日誌。 

範例：/60129547881(使用中less,n以導航到下一個結果。)

運行消息的示例

Example of Running Message

失敗消息示例

Example of Failure Message

5)將正確的故障與附加的常見故障消息表進行比較。

 即，failed_to_retrieve_running_configuration發生在兩台裝置之間的通訊失敗期間。 

常見故障消息

這些是可在前端看到的常見故障消息以及可在後端看到的錯誤代Management Center Task碼。

您可以分析這些郵件，並將其與可能解決方法的常見原因進行比較。如果看不到這些郵件，或無法解決您的問題，請聯絡TAC以獲得幫助。 

----------------------------------------------------------------------------------------

錯誤代碼

錯誤訊息

原因

device_has_changed_domain

部署失敗 — 裝置已更改域。從{SRCDOMAIN}到{DESTINATIONDOMAIN}。請稍後再試。

當裝置已經移動或從第二個域獲取時，通常會發生此錯誤。在沒有跨域資訊的情況下進行重新部署通常可以解決此問題。

device_currently_under_deployment

由於此裝置正在進行另一個部署，部署失敗。請稍後再試。

在部署中的裝置上觸發部署時，通常會報告此問題。在某些版本中，可在不發出故障通知的情況下防止發生故障；但是，此階段仍用於故障排除幫助。

device_not_member_of_container

無法在屬於群集的單個裝置上執行部署。請稍後嘗試重新部署群集。

此訊息適用於使用Firepower可擴充作業系統(FXOS)機箱管理器的裝置上的FTD。如果群集是在FXOS上而非FMC上構建的，則顯示此消息。嘗試部署之前，請在管理中心裝置上建立群集。

policy_altered_after_timestamp_for_other_devices_in_job_error

自{TIMESTAMP}以來，已更改一個或多個裝置的策略。重試部署。

如果部署作業中任何裝置的策略/對象在使用者觸發器部署後、建立CSM元素和域快照之前發生更改，將顯示此錯誤。  重新部署可以解決此問題。

當許多使用者在部署時使用同一個FMC來編輯和儲存對象時，會發生這種情況。

policy_altered_after_timestamp_error

自{Timestamp}以來，策略{Policy Name}已更改。重試部署。

如果部署作業中相關裝置的任何策略/對象發生更改，在使用者觸發器部署之後，建立CSM和域快照之前，將顯示此錯誤。  重新部署可以解決此問題。

csm_snapshot_error

由於未能收集策略和對象，部署失敗。如果反複嘗試後問題仍然存在，請聯絡Cisco TAC。

如果提供了最近的策略匯入，請等待一個小時左右，然後嘗試進行其他部署。 
如果這不允許繼續執行，請聯絡TAC，因為它是與資料庫相關的消息。 

domain_snapshot_timeout

部署失敗，因為收集策略和對象超時。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

預設情況下，域快照超時為5分鐘。如果系統負載過重或虛擬機器監控程式出現故障，則可能導致呼叫中出現不自然的延遲。

如果沒有為管理中心或裝置提供合適的記憶體資源，就可能會發生這種情況。

如果發生這種情況時沒有載入，或者以後沒有繼續，請聯絡TAC。

domain_snapshot_errors

在策略和對象集合中部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

聯絡 TAC.需要高級故障排除。

failed_to_retrieve_running_configuration

由於無法從裝置檢索運行配置資訊，部署失敗。重試部署。

當終端感測器和FMC之間的連線未按預期工作時，可能會出現此消息。檢驗裝置之間的隧道運行狀況並監控兩台裝置之間的連線。 

如果通道按預期運作，且裝置可以通訊，請聯絡TAC。

device_is_busy

部署失敗，因為裝置可以運行以前的部署或重新啟動。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

當FMC嘗試部署時，且先前部署正在FTD上執行時，會顯示此訊息。通常，當先前的部署在FTD上未完成，且FTD重新開機或FTD上的ngfwManager程式重新啟動時，會發生這種情況。20分鐘後重試以允許進程正式超時必須解決此問題。

如果在延遲之後或者延遲不可接受，請聯絡TAC。

no_response_for_show_cmd

由於裝置出現連線問題或裝置未響應，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

FMC發出某些LINA show命令，以提取用於生成配置的運行配置。

當終端感測器上的ngfwManager進程出現連線問題或問題時，可能會發生這種情況。

如果您的裝置之間沒有連線問題，請聯絡TAC。

network_latency_or_device_not_reachable

由於與裝置的通訊失敗，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

通常發生裝置之間的高網路延遲，導致策略超時。驗證裝置之間的網路延遲，以驗證它是否與使用手冊中提及的最低版本相匹配。

slave_app_sync

部署失敗，因為正在進行群集配置同步。重試部署。

這隻適用於FTD叢集設定。如果在進行應用同步（配置同步）時在FTD叢集上嘗試部署，FTD會拒絕該相同專案。配置同步後重試必須解決此問題。

在受管裝置CLISH中，可以使用此命令跟蹤當前群集狀態：

> show cluster info

asa_configuration_generation_erations

部署無法生成裝置配置。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

檢視前面提到的USMS日誌後，您可以檢視導致錯誤的配置。這些錯誤通常是可以透過Cisco Bug Tool瀏覽日誌或聯絡Cisco TAC進行進一步疑難排解的錯誤。

interface_out_of_date

部署失敗，因為裝置上的介面已過期。在介面頁上儲存配置並重試。

如果介面在部署期間或部署之前與裝置取消關聯，則會在4100或9300型號上發生這種情況。

在嘗試部署之前，驗證介面是否已完全關聯或取消關聯。

device_package_error

部署無法為裝置生成配置。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

此錯誤表示無法生成裝置的裝置配置。聯絡 TAC.

device_package_timeout

由於在生成配置期間超時，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

如果裝置之間的延遲超過正常範圍，則可能會發生這種情況。如果在延遲規範化後，仍然出現此問題，請聯絡TAC。 

device_communication_errors

由於裝置通訊失敗，部署失敗。檢查網路連線並重試部署。

此消息是裝置之間任何通訊問題的回退。由於其模糊性，它被寫為回退以表明發生了未知的連線錯誤。 

unable_to_initiate_deployment_dc

策略部署失敗。重試部署。

必須再次嘗試解決此問題。

當FMC由於臨時鎖定資料庫而無法啟動部署時，可能會發生這種情況。

device_failure_timeout

由於超時，部署到裝置失敗。重試部署。

此問題與FTD部署相關。FTD上的程式等待30分鐘，以便派遣完成部署。如果不是，則超時。

如果發生這種情況，請檢驗裝置間連通性；如果連通性符合預期，請聯絡TAC。 

device_failure_download_timeout

由於配置下載超時到裝置，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

此問題與FTD部署相關。由於連線問題，FTD無法在部署期間下載所有裝置組態檔。

請在驗證網路連線後重試。 

如果這一點已經過驗證，請聯絡TAC。

device_failure_configuration

由於配置錯誤，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

FMC為裝置生成的配置中存在任何錯誤，都必須在應用後導致此錯誤。

需要在USMS日誌中對此進行分析，以驗證發現的問題並嘗試回滾它們。

修復後，如果日誌無法與Cisco Bug Search Tool中的已知缺陷相匹配，通常需要TAC干預和錯誤建立。 

deployment_timeout_no_response_from_device

由於與裝置的通訊超時，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

如果FMC在45分鐘後仍未收到裝置的迴音，則會發≤此超時。

這是通訊錯誤。 

驗證通訊，如果驗證，請聯絡TAC。

device_failure_change_master

部署到群集失敗，因為主裝置已更改。重試部署。

對於FTD集群設定部署，如果主節點在裝置上進行部署時進行切換（發佈通知），則指示此錯誤。

在主節點穩定後重試。 

在受管裝置CLISH中，可以使用此命令跟蹤當前的集群成員狀態：

> show cluster info

device_failure_unknown_master

由於主裝置標識失敗，部署到群集失敗。重試部署。

FMC無法在部署過程中確定當前的主節點。

這通常歸因於以下可能性：連線問題或當前主節點未新增到FMC上的群集中。

必須在重新建立連線之後或者將當前主節點新增到FMC群集並且進行重試之後解決此問題。 

在受管裝置CLISH中，可以使用此命令跟蹤當前群集狀態：

> show cluster info

cd_deploy_app_sync

部署失敗，因為正在進行群集配置同步。 重試部署。

如果裝置處於應用同步，則可能會發生這種情況。應用同步完成後，請再次重試部署。 

cd_existing_deployment

由於與以前的並行部署衝突，部署失敗。如果再次嘗試後問題仍然存在，請與Cisco TAC聯絡。

如果部署在一端是併發的，而在另一端不是併發的，則可能會發生這種情況。

這通常是由裝置之間的通訊問題引起的。 

如果發生超時且您仍無法部署，請聯絡TAC。

相關資訊

修訂記錄

修訂 發佈日期 意見
4.0
02-Sep-2026
重新認證 — 更新的格式
3.0
13-May-2024
重新認證
2.0
23-Sep-2022
初始版本
1.0
17-Feb-2020
初始版本
TAC Authored

由思科工程師貢獻

  • Jeff Jackson
    Technical Consulting Engineer

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品