目錄

簡介

背景資訊

必要條件

採用元件

策略部署概述

示例概述

疑難排解

FMC圖形使用者介面(GUI)

利用部署記錄

使用FMC日誌進行故障排除

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

/var/log/sf/policy_deployment.log

受管裝置故障排除

/ngfw/var/log/ngfwManager.log

/ngfw/var/log/sf/policy_deployment.log

範例

常見故障消息

聯絡TAC以取得協助

簡介

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

背景資訊

使用 Cisco Firepower Threat Defense  (FTD)，傳統狀態防火牆功能由 Adaptive Security Appliances (ASA)和 Next-Gen 防火牆功能(由 Snort)現在組合成一種產品。

由於此更改， Policy Deployment Infrastructure 現在，在FTD上處理ASA代碼（也稱為LINA）的配置更改，以及 Snort 一個捆綁包。

必要條件

思科建議瞭解以下產品：

- Firepower Management Center (FMC)

- Firepower Threat Defense (FTD)

採用元件

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

策略部署概述

Cisco FTD利用 Policy Deployments 管理並推送註冊到 Firepower Management Center (FMC)本身。

在部署中，有一系列步驟被劃分為「階段」。

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.如果兩者都有 Snort 並且LINA包成功，受管裝置發出訊號 Snort 重新啟動或重新載入，以便載入新配置並儲存所有當前配置。

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

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

疑難排解

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

1. 組態錯誤

2. FMC和FTD之間的通訊

3. 資料庫和系統運行狀況

4. 軟體缺陷和警告

5. 其他特殊情況

其中一些問題可能很容易解決，而另一些問題可能需要思科的協助 Technical Assistance Center (TAC).

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

FMC圖形使用者介面(GUI)

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

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

利用部署記錄

步驟1.向上拉 Deployments FMC Web UI上的清單。

步驟2.當 Deployments 頁籤，按一下 Show History.

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

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

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

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

步驟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部分中包含的值可用於查詢與某一特定部署嘗試相關的日誌條目。

22-Nov-2019 01:28:52.844,[INFO],(DefenseCenterServiceImpl.java:1372)

com.cisco.nm.vms.api.dc.DefenseCenterServiceImpl, ajp-nio-127.0.0.1-9009-exec-4

** REST Request [ CSM ]

** ID : e1c84364-0966-42eb-9356-d2914be2b4a3

** URL: Broadcast message.send.deployment

{

"body" : {

"property" : "deployment:deployment_initiated_for_the_device",

"argumentList" : [ {

"key" : "PHASE",

"value" : "Phase-0"

} ]

},

"user" : "68d03c42-d9bd-11dc-89f2-b7961d42c462",

"type" : "deployment",

"status" : "running",

"progress" : 5,

"silent" : true,

"restart" : true,

"transactionId" : 12884916552,

"devices" : [ "93a2089a-fa82-11e9-8219-e1abeec81dc9" ]

}

/var/log/sf/policy_deployment.log

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

現在它描述了FMC構建部署包時採取的詳細步驟，因此最好使用它來分析階段1-4的故障。

每個階段的開始都標有「INFO start.. ":

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO starting populateGlobalSnapshot - sqlite = /var/cisco/umpd/8589938337/DC_policy_deployment.db, transaction = 8589938337, time = 1563470402, running as (memory = 56.35 MB) (Framework 3950<196 <- CSMTasks 223<10 <- SF::ActionQueue 2457)

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO deployment threading: disabled (Framework 198 <- CSMTasks 223<10 <- SF::ActionQueue 2457)

Jul 18 17:20:03 firepower ActionQueueScrape.pl[17287]: INFO -> calling SF::UMPD::Plugins::Correlation::Manager::getPluginDependencies (Plugin 298<90 <- Framework 3579<3566<216 <- CSMTasks 223)

...

受管裝置故障排除

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

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

/ngfw/var/log/ngfwManager.log

此日誌檔案提供了採取的詳細步驟， Config Communication Manager 和 Config Dispatcher 要與FMC通訊，請使用部署包，並協調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

此日誌包含應用於的策略的詳細資訊 Snort.雖然日誌內容大多是高級的，需要由TAC進行分析，但仍可以使用幾個關鍵條目跟蹤該進程：

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.部署失敗

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

步驟3.通過SSH連線到 Management Center 並使用Linux實用程式 less 要閱讀FMC上顯示的檔案：

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

步驟4.當您進入 less，使用正斜槓並在消息ID中輸入以搜尋與部署事務ID相關的日誌。

示例："/60129547881"(在 less，使用n導航到下一個結果)

運行消息的示例：

失敗消息示例：

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_errors

部署無法生成裝置配置。如果再次嘗試後問題仍然存在，請聯絡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

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

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

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。

聯絡TAC以取得協助

如果以上資訊不允許繼續策略部署，或者如果問題似乎與預先存在的已記錄行為無關，請使用下一個連結中提供的步驟生成故障排除檔案，並聯絡TAC進行分析和錯誤建立。

https://www.cisco.com/c/en/us/support/docs/security/sourcefire-defense-center/117663-technote-SourceFire-00.html