Firepower威胁防御策略部署故障排除
目录
简介
借助思科Firepower威胁防御(FTD)，自适应安全设备(ASA)提供的传统状态防火墙功能和下一代防火墙功能（由Snort提供支持）现已整合到一个产品中。由于此更改，FTD上的策略部署基础设施现在在一个捆绑包中处理ASA代码（也称为LINA）和Snort的配置更改。本文档简要概述了FTD上的策略部署过程以及基本的故障排除技术。
先决条件
思科建议您了解以下产品：
- Firepower管理中心(FMC)
- Firepower威胁防御(FTD)
策略部署概述
思科FTD利用策略部署来管理和推出注册到Firepower管理中心(FMC)自身的设备的配置。在部署中，有一系列步骤分为“阶段”。
FMC阶段可在以下列表中汇总。
| 第 0 阶段 | 部署初始化 |
| 第 1 阶段 | 数据库对象集合 |
| 第 2 阶段 | 策略和对象集合 |
| 第 3 阶段 | NGFW命令行配置生成 |
| 第 4 阶段 | 设备部署包生成 |
| 第 5 阶段 | 发送和接收部署包 |
| 第 6 阶段 | 挂起的部署、部署操作和部署成功消息 |
了解各个阶段并了解故障在流程中的位置有助于排除Firepower系统面临的故障。在某些情况下，它可能是由于以前的配置或缺少高级Flex配置关键字而导致的冲突，这可能导致设备报告未明确说明的故障。
示例概述
步骤1.用户点击“部署”按钮，指定用户要选择的设备。
步骤2.提交设备部署后，FMC开始收集与设备相关的所有配置。
步骤3.收集配置后，FMC会创建软件包并通过其称为SFTunnel的通信机制将其发送到传感器。
步骤4.然后，FMC通知传感器使用提供的策略启动部署过程，同时侦听各个响应。
步骤5.受管设备解压存档并开始应用各个配置和软件包。
答：部署的前半部分是Snort配置，在该配置中对Snort配置进行本地测试以确保其有效性。新配置一旦被证明有效，即会移至Snort的生产目录。如果验证失败，则策略部署在此步骤中失败。
B.部署包加载的后半部分用于LINA配置，在LINA配置中，ngfwManager进程直接将其应用到LINA进程。如果发生故障，则会回滚更改并发生策略部署故障。
步骤6.如果Snort和LINA包都成功，受管设备会发出信号，要求Snort重新启动或重新加载，以加载新配置并保存所有当前配置。
步骤7.如果所有消息都成功，传感器将发送成功消息并等待管理中心确认。
步骤8.收到后，FMC将任务标记为成功，并允许策略捆绑完成。
故障排除
策略部署期间遇到的问题可能是由于以下原因造成的，但不限于：
- 配置错误
- FMC与FTD之间的通信
- 数据库和系统运行状况
- 软件缺陷和警告
- 其他独特情况
其中一些问题可以轻松解决，而其他问题则可能需要思科技术支持中心(TAC)的帮助。
本部分的目标是提供故障排除工具和技术，以隔离问题或确定根本原因。
FMC图形用户界面(GUI)故障排除
思科建议在FMC设备上启动每个故障排除会话，以便部署失败。
在故障通知窗口中，在6.2.3以上的所有版本上，都有其他故障排除工具可帮助您解决可能遇到的故障。
利用部署记录
步骤1.在FMC Web UI上拉出Deployments（部署）列表。
步骤2.选择“部署”选项卡时，选择“显示历史记录”选项。
步骤3.在“部署历史记录”框内，您可以从FMC查看所有以前的部署。选择要查看更多数据的部署。
步骤4.一旦选择了部署元素，您将进入“部署详细信息”选择，其中显示事务中所有设备的列表。这些条目分为以下几列：设备编号、设备名称、状态和记录。
步骤5.您可以选择相关设备，然后点击脚本选项查看单个部署脚本，该脚本可通知您受管设备上的故障和配置。
步骤6.此记录可以指定某些故障情况，并为下一步指明一个非常重要的数字：事务 ID.
步骤7.在Firepower部署中，事务ID可用于跟踪策略部署的每个单独部分。这样，在设备的命令行上，您可以获取更深入的此数据版本，以便进行故障排除和分析。
使用FMC日志进行故障排除
尽管与思科TAC接洽以分析日志是合适的，但查看日志可能有助于初始问题隔离和加快解决速度。FMC上有多个日志文件，可显示有关策略部署过程的详细信息。最常引用的两个日志是policy_deployment.log和usmsharedsvcs.log。
使用多个Linux命令（如more、less和vi）可查看本文档中提及的所有文件。但是，必须确保只对其执行读取操作。所有文件都需要根访问权限才能查看。
/var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log
此日志清楚地标记FMC上策略部署任务的开始和每个阶段的完成，这有助于确定部署发生故障的阶段以及故障代码。日志的JSON部分中包含的“transactionID”值可用于查找与某个特定部署尝试相关的日志条目。
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 Starting XYZ”：
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
此日志文件提供配置通信管理器和配置调度程序与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连接到管理中心，并减少使用Linux实用程序读取文件的次数，如FMC中所示：
示例："sudo less /var/opt/CSCOpx/MDC/log/operation/usmsharedsvcs.log"（sudo密码是您的ssh用户密码）
步骤4.在较少时，使用正斜杠并输入消息ID以搜索与部署事务ID相关的日志。
示例："/60129547881" {在较少时，使用n导航到下一个结果}
运行消息的示例：
故障消息示例：
5)将正确的故障与附加的常见故障消息表进行比较。
即，在两台设备之间的通信失败期间，会发生failed_to_retrieve_running_configuration。
常见故障消息
以下是在管理中心任务前端可以看到的常见故障消息以及在后端可以看到的错误代码。可以分析这些消息并将其与可能解决的常见原因进行比较。
如果未看到这些信息，或者无法解决您的问题，请联系TAC寻求帮助。
| 错误代码 |
错误消息 |
原因 |
| device_has_changed_domain |
部署失败 — 设备已将域从{SRCDOMAIN}更改为{DESTINATIONDOMAIN}。请稍后再试。 |
当设备正在移动或正在从第二个域获取时，通常会发生此错误。在不发生跨域信息的情况下重新部署通常会解决此问题。 |
| device_current_under_deployment |
部署失败，因为此设备正在进行其他部署。请稍后再试。 |
当在正在部署的设备上触发部署时，通常会报告此情况。在某些版本中，在不发出故障通知的情况下，可防止出现此情况；但是，此阶段仍然存在，用于故障排除帮助。 |
| device_not_member_of_container |
无法在作为集群成员的单个设备上执行部署。请稍后重试，部署群集。 |
此消息适用于具有Firepower可扩展操作系统(FXOS)机箱管理器的设备上的FTD。如果集群是在FXOS上构建，而不是在FMC上构建，则显示此消息。在尝试部署之前，请先在管理中心设备上创建群集。 |
| policy_acttered_after_timestamp_for_other_devices_in_job_error |
自{TIMESTAMP}以来，一个或多个设备的策略已更改。重试部署。 |
如果在用户触发部署后和创建CSM元素和域快照之前，部署作业中任何设备的任何策略/对象都发生了更改，则显示此错误。 重新部署可解决此问题。 当许多用户使用相同的FMC编辑对象并在点击部署时保存时，可能会发生这种情况。 |
| policy_acttered_after_timestamp_error |
策略{策略名称}自{Timestamp}以来已更改。重试部署。 |
此错误显示如果部署作业中相关设备的任何策略/对象发生更改，则用户触发部署后，以及创建CSM和域快照前，会显示此错误。 重新部署可解决此问题。 |
| csm_snapshot_error |
由于收集策略和对象失败，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
如果提供了最近的策略导入，请等待一小时左右，然后尝试进行其他部署。 |
| domain_snapshot_timeout |
由于收集策略和对象超时，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
默认情况下，域快照的超时时间为5分钟。如果系统负载过高，或者虚拟机监控程序出现故障或虚拟负载过低，则可能导致呼叫中出现非自然的延迟。 如果管理中心或设备未提供适当数量的内存资源，则可能会发生这种情况。 如果此操作在未加载的情况下发生，或以后不继续，请联系TAC。 |
| domain_snapshot_errors |
策略和对象集合中的部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
联系 TAC.需要进行高级故障排除。 |
| failed_to_retrieve_running_configuration |
由于从设备检索运行配置信息失败，部署失败。重试部署。 |
当终端传感器和FMC之间的连接未按预期工作时，可能会出现此消息。检验设备之间的隧道运行状况并监控两台设备之间的连接。 |
| device_is_busy |
部署失败，因为设备可能正在运行以前的部署或重新启动。如果稍后重试后问题仍然存在，请联系思科TAC。 |
当FMC尝试部署时，当FTD上正在进行以前的部署时，会显示此消息。通常，当FTD上以前的部署未完成且FTD重新启动或FTD上的ngfwManager进程重新启动时。在20分钟后重试以允许进程正式超时应解决此问题。 如果延迟后或延迟不可接受，请联系TAC。 |
| no_response_for_show_cmd |
由于设备或设备未响应的连接问题，部署失败。如果稍后重试后问题仍然存在，请联系思科TAC。 |
FMC发出某些LINA“show”命令，以获取用于生成配置的运行配置。 当终端传感器上的ngfwManager进程出现连接问题或问题时，可能会发生这种情况。 如果您未在设备之间遇到连接问题，请联系TAC。 |
| network_latency_or_device_not_reachable |
由于设备通信失败，部署失败。如果稍后重试后问题仍然存在，请联系思科TAC。 |
通常在设备之间存在高网络延迟，导致策略超时。验证设备之间的网络延迟，以验证其是否与用户指南中提到的版本的最小值相匹配。 |
| slave_app_sync |
部署失败，因为正在进行集群配置同步。 重试部署。 |
这仅适用于FTD集群设置。如果在应用同步（配置同步）进行期间尝试在FTD群集上部署，则FTD会拒绝此部署。配置同步后重试应能解决此问题。 在受管设备CLISH中，可使用以下命令跟踪当前集群状态： > show cluster info |
| asa_configuration_generation_errors |
由于生成设备配置失败，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
浏览上述USMS日志后，您可能可以看到导致错误的配置。这些通常是错误，在这些错误中，日志可通过思科漏洞工具浏览或联系思科TAC进一步排除故障。 |
| interface_out_of_date |
部署失败，因为设备上的接口已过时。在接口页面上保存配置，然后重试。 |
如果接口在部署期间或在部署之前未与设备关联，则4100或9300型号会发生这种情况。 在尝试部署之前，验证接口是否完全关联或未关联。 |
| device_package_error |
由于为设备生成配置失败，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
这是指示无法为设备生成设备配置的错误。联系 TAC. |
| device_package_timeout |
由于在配置生成期间超时，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
如果设备之间的延迟超出正常范围，则会发生这种情况。如果延迟规范化后仍然出现此问题，请与TAC联系。 |
| device_communication_errors |
由于与设备通信失败，部署失败。检查网络连接并重试部署。 |
此消息是设备之间任何通信问题的回退。由于其Vague性质，它被写为回退到出现未知连接错误的状态。 |
| unable_to_initiate_deployment_dc |
部署失败，因为无法将策略部署到设备。重试部署。 |
重试应能解决此问题。 当FMC由于数据库上的临时锁而无法启动部署时，可能会发生这种情况。 |
| device_failure_timeout |
由于超时，设备部署失败。重试部署。 |
这与FTD部署相关。FTD上的进程等待30分钟，以便派单完成部署。如果没有，就会超时。 如果发生这种情况，请验证设备间连接，如果连接符合预期，请联系TAC。 |
| device_failure_download_timeout |
由于将配置下载到设备时超时，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
这与FTD部署相关。由于连接问题，FTD在部署期间无法下载所有设备配置文件。 请在验证网络连接后重试。 如果已验证，请联系TAC。 |
| device_failure_configuration |
由于配置错误，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
FMC为设备生成的配置中的任何错误都应导致应用后出现此错误。 需要在USMS日志中分析此问题，以验证发现了哪些问题并尝试将其回滚。 修复后，如果日志无法与思科漏洞搜索工具中的已知缺陷匹配，通常需要TAC干预和漏洞创建。 |
| deployment_timeout_no_response_from_device |
由于与设备通信超时，部署失败。如果重试后问题仍然存在，请联系思科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 | 由于与当前以前的部署冲突，部署失败。如果重试后问题仍然存在，请联系思科TAC。 |
如果部署仍在一端进行，但在另一端不进行，则可能会发生这种情况。 这通常是由设备之间的通信问题引起的。 如果超时后仍无法部署，请与TAC联系。 |
联系TAC寻求帮助
如果上述信息不允许继续策略部署，或者如果问题似乎与先前存在的已记录行为无关，请使用下一链接中提供的步骤生成故障排除文件，并联系TAC进行分析和漏洞创建。
反馈