簡介
本檔案將簡要概述FTD上的原則部署程式以及基本疑難排解技巧。
必要條件
需求
思科建議您瞭解以下主題:
Firewall Management Center (FMC)
Firepower Threat Defense (FTD)
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
背景資訊
使用 Cisco Firepower Threat Defense (FTD), Adaptive Security Appliances (ASA)提供的傳統狀態防火牆功能和防 Next-Gen 火牆功能(由 Snort 提供支援)現在可組合為一個產品。
由於此更改,FTD上 Policy Deployment Infrastructure 現在會處理ASA代碼(也稱為LINA)和 Snort 在一個捆綁包中的配置更改。
策略部署概述
思科FTD利用 Policy Deployments 管理和推出註冊到 Firewall Management Center FMC(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 可能是由於(但不限於):
- 組態錯誤
- FMC和FTD之間的通訊
- 資料庫和系統狀況
- 軟體缺陷與警告
- 其他特殊情況
其中有些問題可輕鬆解決,而另一些問題則需要思科 Technical Assistance Center (TAC)的幫助。
本節的目的是提供隔離問題或確定根本原因的技術。
FMC圖形使用者介面(GUI)
思科建議在FMC裝置上啟動部署失敗的每個故障排除會話。
在「故障通知」窗口中,對於6.2.3以後的所有版本,還有其他工具可以幫助處理其他可能的故障。
利用部署記錄
步驟 1.上拉FMC Web UI上的 Deployments 清單。
步驟 2.當選擇 Deployments 頁籤時,按一下 Show History。
步驟 3.在 Deployment History 框內,您可以看到來自FMC的所有先前部署。選取您想要在其中檢視更多資料的部署。
步驟 4.選擇部署元素後,選 Deployment Details 擇內容將顯示 Transaction內部的所有裝置的清單。這些條目被分為以下列: Device Number, Device Name, Status,和 Transcript。
步驟 5.選擇有問題的裝置,然後按一下記錄選項,可檢視各個部署記錄,這些記錄可以通知您故障以及位於受管裝置上的配置。
步驟 6.此記錄可指定某些故障條件,並為下一步指明一個非常重要的編號: Transaction ID。
步驟 7.在 Firepower Deployment中, Transaction ID 是可以用於跟蹤策略部署的每個獨立部分的。這樣,在裝置的命令列上,您便可獲得此資料的更深入版本,以進行修正和分析。
秘訣:如果您找不到交易ID,或者您使用的是列印前的版本,此記錄檔仍可用於找出個別的失敗訊息。
使用FMC日誌進行故障排除
儘管讓Cisco TAC參與分析日誌是合適的,但搜尋日誌有助於初步隔離問題並加快解決速度。FMC上有多個顯示策略部署過程詳細資訊的日誌檔案。
兩個最常引用的日誌是 policy_deployment.log 和 usmsharedsvcs.log。
本文檔中所有提到的檔案都可使用多個Linux命令進行檢視,例如 more、 less 和 vi。但是,確保僅對其執行操 read 作非常重要。所有檔案都需要具有根目錄存取權才能檢視。
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
此日誌清楚地標籤FMC上的策略部署任務的開始和每個階段的完成,這有助於確定部署發生故障的階段以及故障代碼。
日誌的JSON部分中包含的 transactionID 值可用於查詢與某一特定部署嘗試相關的日誌項。
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
此日誌檔案提供 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密碼是ssh的使用者密碼。)
步驟 4.使用 less時,使用正斜線並在消息ID中輸入,以搜尋與部署transactionID相關的日誌。
範例: /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
|
策略{Policy Name}自{Timestamp}以來已被更改。重試部署。 |
如果在部署作業中、使用者觸發部署之後以及建立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日誌後,您可以看到導致錯誤的配置。這些錯誤通常是可以透過思科Bug工具檢視日誌或聯絡思科TAC進行進一步故障排除的錯誤。 |
interface_out_of_date
|
部署失敗,因為裝置上的介面已過期。請儲存interfaces頁上的配置並重試。 |
如果在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為裝置生成的配置中的所有錯誤都必須導致此error post apply。 需要在USMS日誌中對此進行分析,以驗證發現的問題並嘗試回滾它們。 修復後,如果記錄無法與思科錯誤搜尋工具的已知缺陷比對,通常需要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
|
部署失敗,因為叢集設定同步處理正在進行中。 重試部署。 |
如果裝置處於App Sync中,則可能會發生這種情況。App Sync完成後,請再次重試部署。 |
cd_existing_deployment
|
部署失敗,因為與並行先前的部署衝突。如果再次嘗試後問題仍然存在,請與Cisco TAC聯絡。 |
如果部署在一端同時執行,而在另一端卻不同步,則可能會發生這種情況。 這些通常是由裝置之間的通訊問題引起的。 如果超時後仍然無法部署,請與TAC聯絡。 |
相關資訊