分析Firepower防火墙捕获以有效排除网络问题
目录
简介
本文档介绍各种旨在有效排除网络故障的数据包捕获分析技术。 本文档中介绍的所有场景均基于思科技术支持中心(TAC)中看到的真实用户案例。 本文档涵盖从思科下一代防火墙(NGFW)角度捕获的数据包，但相同的概念也适用于其他设备类型。
先决条件
要求
Cisco 建议您了解以下主题：
- Firepower平台架构
- NGFW日志
- NGFW Packet-Tracer
此外，在开始分析数据包捕获之前，最好满足以下要求：
- 了解协议操作 — 如果您不了解捕获的协议如何运行，则无法开始检查数据包捕获
- 了解拓扑 — 您必须知道中转设备。理想情况下，端到端。如果这不可能，您至少必须知道上游和下游设备
- 了解设备 — 您必须了解设备如何处理数据包、涉及的接口（即入口/出口）、设备架构以及各种捕获点
- 了解配置 — 您必须了解设备应如何处理数据包流，具体内容如下：
- 路由/出口接口
- 应用的策略
- 网络地址转换 (NAT)
- 了解可用工具 — 除捕获外，建议还准备好应用其他故障排除工具和技术（如日志记录和跟踪器），并在需要时将它们与捕获的数据包关联
使用的组件
本文档中的信息基于以下软件和硬件版本：
- 大多数场景都基于运行FTD软件6.5.x的FP4140。
- 运行软件6.5.x的FMC。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
背景信息
数据包捕获是目前最被忽略的故障排除工具之一。每天，Cisco TAC通过分析捕获的数据来解决许多客户问题。本文档的目标是帮助网络和安全工程师主要基于数据包捕获分析来识别和排除常见网络问题。
如何收集和导出NGFW产品系列的捕获信息？
对于Firepower设备(1xxx、21xx、41xx、93xx)和Firepower威胁防御(FTD)应用，可以如图所示直观地显示数据包处理。
- 数据包进入入口接口，由机箱内部交换机处理。
- 数据包进入主要执行L3/L4检查的FTD Lina引擎。
- 如果策略要求数据包由Snort引擎检查（主要是L7检查）。
- Snort引擎会为数据包返回判定。
- LINA引擎根据Snort的判定丢弃或转发数据包.
- 数据包通过内部机箱交换机离开机箱。
根据图中的架构，FTD捕获可在3个不同位置进行：
- FXOS
- FTD Lina引擎
- FTD Snort引擎
收集FXOS捕获
此过程在本文档中介绍：
FXOS捕获只能从内部交换机的入口方向捕获，如图所示。
如图所示，每个方向有两个捕获点（由于内部交换机架构）。
第2、3和4点中捕获的数据包具有虚拟网络标记(VNTag)。
启用和收集FTD Lina捕获
主要捕获点：
- Ingress 接口
- Egress 接口
- 加速安全路径(ASP)
您可以使用Firepower管理中心用户界面(FMC UI)或FTD CLI启用和收集FTD Lina捕获。
在INSIDE接口上启用从CLI捕获：
firepower# capture CAPI interface INSIDE match icmp host 192.168.103.1 host 192.168.101.1
此捕获在两个方向上匹配IP 192.168.103.1和192.168.101.1之间的流量。
启用ASP捕获，查看FTD Lina引擎丢弃的所有数据包：
firepower# capture ASP type asp-drop all
将FTD Lina捕获导出到FTP服务器：
firepower# copy /pcap capture:CAPI ftp://ftp_username:ftp_password@192.168.78.73/CAPI.pcap
将FTD Lina捕获导出到TFTP服务器：
firepower# copy /pcap capture:CAPI tftp://192.168.78.73
与FMC 6.2.x版本一样，您可以从FMC UI启用和收集FTD Lina捕获。
从FMC管理的防火墙收集FTD捕获的另一种方法是这样。
第 1 步
如果是LINA或ASP捕获，请将捕获复制到FTD磁盘，例如
firepower# copy /pcap capture:capin disk0:capin.pcap Source capture name [capin]? Destination filename [capin.pcap]? !!!!
步骤 2
导航至专家模式，找到保存的捕获，并将其复制到/ngfw/var/common位置：
firepower# Console connection detached. > expert admin@firepower:~$ sudo su Password: root@firepower:/home/admin# cd /mnt/disk0 root@firepower:/mnt/disk0# ls -al | grep pcap -rwxr-xr-x 1 root root 24 Apr 26 18:19 CAPI.pcap -rwxr-xr-x 1 root root 30110 Apr 8 14:10 capin.pcap -rwxr-xr-x 1 root root 6123 Apr 8 14:11 capin2.pcap root@firepower:/mnt/disk0# cp capin.pcap /ngfw/var/common
步骤 3
登录到管理FTD的FMC，然后导航到Devices > Device Management。找到FTD设备并选择“Troubleshoot(故障排除)”图标：
步骤 4
选择高级故障排除：
指定捕获文件名并选择 下载：
有关如何从FMC UI启用/收集捕获的更多示例，请检查本文档：
启用和收集FTD Snort捕获
此处的图中显示了捕获点。
启用Snort级捕获：
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -n host 192.168.101.1
要将捕获写入名为capture.pcap的文件，并通过FTP将其复制到远程服务器：
> capture-traffic Please choose domain to capture traffic from: 0 - br1 1 - Router Selection? 1 Please specify tcpdump options desired. (or enter '?' for a list of supported options) Options: -w capture.pcap host 192.168.101.1 CTRL + C <- to stop the capture
> file copy 10.229.22.136 ftp / capture.pcap Enter password for ftp@10.229.22.136: Copying capture.pcap Copy successful. >
有关包含不同捕获过滤器的更多Snort级捕获示例，请检查本文档：
故障排除
案例1.出口接口上没有TCP SYN
拓扑如下图所示：
问题说明:HTTP不起作用
受影响的流：
源IP:192.168.0.100
目的IP:10.10.1.100
协议：TCP 80
捕获分析
在FTD LINA引擎上启用捕获：
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
捕获 — 功能场景：
作为基准，从功能场景中捕获数据始终非常有用。
如图所示，在NGFW INSIDE接口上捕获的数据：
关键点
- TCP三次握手。
- 双向数据交换。
- 数据包之间无延迟（基于数据包之间的时间差）
- 源MAC是正确的下游设备。
在NGFW OUTSIDE接口上拍摄的捕获信息如下图所示：
关键点
- 与CAPI捕获中的数据相同。
- 目的MAC是正确的上游设备。
捕获 — 非功能方案
在设备CLI中，捕获如下所示：
firepower# show capture capture CAPI type raw-data interface INSIDE [Capturing - 484 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI内容：
firepower# show capture CAPI 6 packets captured 1: 11:47:46.911482 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 11:47:47.161902 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 11:47:49.907683 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 4: 11:47:50.162757 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 11:47:55.914640 192.168.0.100.3171 > 10.10.1.100.80: S 1089825363:1089825363(0) win 8192 <mss 1460,nop,nop,sackOK> 6: 11:47:56.164710 192.168.0.100.3172 > 10.10.1.100.80: S 3981048763:3981048763(0) win 8192 <mss 1460,nop,nop,sackOK>
firepower# show capture CAPO 0 packet captured 0 packet shown
以下是Wireshark中CAPI捕获的映像：
关键点
- 仅显示TCP SYN数据包（无TCP三次握手）。
- 有2个TCP会话（源端口3171和3172）无法建立。源客户端重新发送TCP SYN数据包。Wireshark将这些重新传输的数据包标识为TCP重新传输。
- TCP重新传输每约3秒（等于6秒）发生一次
- 源MAC地址来自正确的下游设备。
根据2个捕获结果，可以得出以下结论：
- 特定五元组（src/dst IP、src/dst端口、协议）的数据包到达预期接口(INSIDE)上的防火墙。
- 数据包不会将防火墙留在预期接口(OUTSIDE)上。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查模拟数据包的跟踪。
使用packet-tracer工具查看防火墙应如何处理数据包。如果防火墙访问策略丢弃了数据包，则模拟数据包的跟踪与以下输出类似：
firepower# packet-tracer input INSIDE tcp 192.168.0.100 11111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA
操作2.检查实时数据包的跟踪。
启用数据包跟踪以检查防火墙如何处理实际TCP SYN数据包。默认情况下，仅跟踪前50个入口数据包：
firepower# capture CAPI trace
清除捕获缓冲区：
firepower# clear capture /all
如果防火墙访问策略丢弃了数据包，跟踪将类似于以下输出：
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 12:45:36.279740 192.168.0.100.3630 > 10.10.1.100.80: S 2322685377:2322685377(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Phase: 4 Type: ACCESS-LIST Subtype: log Result: DROP Config: access-group CSM_FW_ACL_ global access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268439946 event-log flow-start access-list CSM_FW_ACL_ remark rule-id 268439946: ACCESS POLICY: FTD_Policy - Default access-list CSM_FW_ACL_ remark rule-id 268439946: L4 RULE: DEFAULT ACTION RULE Additional Information: Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x00005647a4f4b120 flow (NA)/NA 1 packet shown
操作3.检查FTD Lina日志。
要通过FMC在FTD上配置系统日志，请检查本文档：
强烈建议为FTD Lina日志配置外部系统日志服务器。如果未配置远程系统日志服务器，请在进行故障排除时在防火墙上启用本地缓冲区日志。本示例中显示的日志配置是一个良好的起点：
firepower# show run logging … logging enable logging timestamp logging buffer-size 1000000 logging buffered informational
将终端寻呼机设置为24行以控制终端寻呼机：
firepower# terminal pager 24
清除捕获缓冲区：
firepower# clear logging buffer
使用解析器过滤器测试连接并检查日志。在本示例中，防火墙访问策略丢弃数据包：
firepower# show logging | include 10.10.1.100 Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:51: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3696 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0] Oct 09 2019 12:55:54: %FTD-4-106023: Deny tcp src INSIDE:192.168.0.100/3697 dst OUTSIDE:10.10.1.100/80 by access-group "CSM_FW_ACL_" [0x97aa021a, 0x0]
操作4.检查防火墙ASP丢弃。
如果您怀疑防火墙丢弃了该数据包，则可以在软件级别查看防火墙丢弃的所有数据包的计数器：
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71 Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15 Flow drop: Last clearing: 07:51:52 UTC Oct 10 2019 by enable_15
您可以启用捕获以查看所有ASP软件级丢弃：
firepower# capture ASP type asp-drop all buffer 33554432 headers-only
要检查捕获内容，您可以使用过滤器缩小搜索范围：
firepower# show capture ASP | include 10.10.1.100 18: 07:51:57.823672 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 19: 07:51:58.074291 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 26: 07:52:00.830370 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 29: 07:52:01.080394 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 45: 07:52:06.824282 192.168.0.100.12410 > 10.10.1.100.80: S 1870382552:1870382552(0) win 8192 <mss 1460,nop,nop,sackOK> 46: 07:52:07.074230 192.168.0.100.12411 > 10.10.1.100.80: S 2006489005:2006489005(0) win 8192 <mss 1460,nop,nop,sackOK>
在这种情况下，由于数据包已在接口级别跟踪，因此ASP捕获中未提及丢弃原因。请记住，数据包只能在一个位置跟踪（入口接口或ASP丢弃）。 在这种情况下，建议采用多个ASP丢弃并设置特定ASP丢弃原因。以下是推荐的方法：
1.清除当前ASP丢弃计数器：
firepower# clear asp drop
2.通过防火墙发送故障排除的流（运行测试）。
3.再次检查ASP下拉计数器并记下增加的计数器，例如
firepower# show asp drop Frame drop: No route to host (no-route) 234 Flow is denied by configured rule (acl-drop) 71
4.为所看到的特定丢包启用ASP捕获：
firepower# capture ASP_NO_ROUTE type asp-drop no-route firepower# capture ASP_ACL_DROP type asp-drop acl-drop
5.通过防火墙发送故障排除的流（运行测试）。
6.检查ASP捕获。在这种情况下，由于缺少路由，数据包被丢弃：
firepower# show capture ASP_NO_ROUTE | include 192.168.0.100.*10.10.1.100 93: 07:53:52.381663 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 95: 07:53:52.632337 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 101: 07:53:55.375392 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 102: 07:53:55.626386 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 116: 07:54:01.376231 192.168.0.100.12417 > 10.10.1.100.80: S 3451917925:3451917925(0) win 8192 <mss 1460,nop,nop,sackOK> 117: 07:54:01.626310 192.168.0.100.12418 > 10.10.1.100.80: S 1691844448:1691844448(0) win 8192 <mss 1460,nop,nop,sackOK>
操作5.检查FTD Lina连接表。
在某些情况下，您希望数据包从接口“X”传出，但出于任何原因，它会从接口“Y”传出。 防火墙出口接口的确定基于以下操作顺序：
- 已建立连接查找
- 网络地址转换(NAT)查找 — UN-NAT（目标NAT）阶段优先于PBR和路由查找。
- 基于策略的路由 (PBR)
- 路由表查找
要检查FTD连接表，请执行以下操作：
firepower# show conn
2 in use, 4 most used
Inspect Snort:
preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 0 most in effect
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11694, idle 0:00:01, bytes 0, flags aA N1
TCP DMZ 10.10.1.100:80 INSIDE 192.168.0.100:11693, idle 0:00:01, bytes 0, flags aA N1
关键点
- 根据标志(Aa)，连接处于初期状态（半开 — 防火墙只看到TCP SYN）。
- 根据源/目标端口，入口接口为INSIDE，出口接口为DMZ。
这可以在以下图像中显示：
firepower# show interface detail | i Interface number is|Interface [P|E].*is up
...
Interface Ethernet1/2 "INSIDE", is up, line protocol is up
Interface number is 19
Interface Ethernet1/3.202 "OUTSIDE", is up, line protocol is up
Interface number is 20
Interface Ethernet1/3.203 "DMZ", is up, line protocol is up
Interface number is 22
输出1:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.200/80 (192.168.2.200/80) INSIDE: 192.168.1.100/46050 (192.168.1.100/46050), flags aA N1, idle 3s, uptime 6s, timeout 30s, bytes 0 Initiator: 192.168.1.100, Responder: 192.168.2.200 Connection lookup keyid: 228982375
输出2:
firepower# show conn detail
...
TCP OUTSIDE: 192.168.2.200/80 INSIDE: 192.168.1.100/46050,
flags aA N1, idle 4s, uptime 11s, timeout 30s, bytes 0
Initiator: 192.168.1.100, Responder: 192.168.2.200
Connection lookup keyid: 228982375
此外，show conn long在网络地址转换时，在括号中显示NATed IP:
firepower# show conn long ... TCP OUTSIDE: 192.168.2.222/80 (192.168.2.222/80) INSIDE: 192.168.1.100/34792 (192.168.2.150/34792), flags aA N1, idle 0s, uptime 0s, timeout 30s, bytes 0, xlate id 0x2b5a8a4314c0 Initiator: 192.168.1.100, Responder: 192.168.2.222 Connection lookup keyid: 262895
操作6.检查防火墙地址解析协议(ARP)缓存。
如果防火墙无法解析下一跳，防火墙会以静默方式丢弃原始数据包（本例中为TCP SYN），并持续发送ARP请求，直到解析下一跳。
要查看防火墙ARP缓存，请使用命令：
firepower# show arp
此外，要检查是否存在未解析的主机，可使用以下命令：
firepower# show arp statistics
Number of ARP entries in ASA: 0
Dropped blocks in ARP: 84
Maximum Queued blocks: 3
Queued blocks: 0
Interface collision ARPs Received: 0
ARP-defense Gratuitous ARPS sent: 0
Total ARP retries: 182 < indicates a possible issue for some hosts
Unresolved hosts: 1 < this is the current status
Maximum Unresolved hosts: 2
如果要进一步检查ARP操作，可以启用ARP特定捕获：
firepower# capture ARP ethernet-type arp interface OUTSIDE firepower# show capture ARP ... 4: 07:15:16.877914 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 5: 07:15:18.020033 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50
在此输出中，防火墙(192.168.2.50)尝试解析下一跳(192.168.2.72)，但没有ARP应答
此处的输出显示了具有正确ARP解析的功能场景：
firepower# show capture ARP 2 packets captured 1: 07:17:19.495595 802.1Q vlan#202 P0 arp who-has 192.168.2.72 tell 192.168.2.50 2: 07:17:19.495946 802.1Q vlan#202 P0 arp reply 192.168.2.72 is-at 4c:4e:35:fc:fc:d8 2 packets shown
firepower# show arp
INSIDE 192.168.1.71 4c4e.35fc.fcd8 9
OUTSIDE 192.168.2.72 4c4e.35fc.fcd8 9
如果没有ARP条目，则实时TCP SYN数据包的跟踪显示：
firepower# show capture CAPI packet-number 1 trace 6 packets captured 1: 07:03:43.270585 192.168.0.100.11997 > 10.10.1.100.80: S 4023707145:4023707145(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4814, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: allow
如输出所示，跟踪显示操作：allow，即使下一跳无法到达且防火墙以静默方式丢弃数据包！在这种情况下，还必须检查packet-tracer工具，因为它提供更准确的输出：
firepower# packet-tracer input INSIDE tcp 192.168.0.100 1111 10.10.1.100 80 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE … Phase: 14 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 4816, packet dispatched to next module … Phase: 17 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.2.72 using egress ifc OUTSIDE Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: OUTSIDE output-status: up output-line-status: up Action: drop Drop-reason: (no-v4-adjacency) No valid V4 adjacency, Drop-location: frame 0x00005647a4e86109 flow (NA)/NA
在最新的ASA/Firepower版本中，上述消息已优化为：
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: f
可能的原因和建议的操作摘要
如果在入口接口上仅看到TCP SYN数据包，但从预期出口接口发送的TCP SYN数据包有以下可能原因：
| 可能的原因 |
推荐的操作 |
| 防火墙访问策略会丢弃数据包。 |
|
| 捕获过滤器错误。 |
|
| 数据包被发送到不同的出口接口。 |
如果数据包由于与现有连接匹配而发送到错误接口，请使用命令clear conn address 并指定要清除的连接的5元组。 |
| 没有通往目的地的路由。 |
|
| 出口接口上没有ARP条目。 |
|
| 出口接口关闭。 |
检查防火墙上show interface ip brief命令的输出并验证接口状态。 |
案例2.来自客户端的TCP SYN、来自服务器的TCP RST
下图显示拓扑：
问题说明:HTTP不起作用
受影响的流：
源IP:192.168.0.100
目的IP:10.10.1.100
协议：TCP 80
捕获分析
在FTD LINA引擎上启用捕获。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
捕获 — 非功能场景：
在设备CLI中，捕获如下所示：
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 834 bytes] match ip host 192.168.0.100 host 10.10.1.100 capture CAPO type raw-data interface OUTSIDE [Capturing - 878 bytes] match ip host 192.168.0.100 host 10.10.1.100
CAPI内容：
firepower# show capture CAPI 1: 05:20:36.654217 192.168.0.100.22195 > 10.10.1.100.80: S 1397289928:1397289928(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904311 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.905043 10.10.1.100.80 > 192.168.0.100.22196: R 1850052503:1850052503(0) ack 2171673259 win 0 4: 05:20:37.414132 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414803 10.10.1.100.80 > 192.168.0.100.22196: R 31997177:31997177(0) ack 2171673259 win 0 6: 05:20:37.914183 192.168.0.100.22196 > 10.10.1.100.80: S 2171673258:2171673258(0) win 8192 <mss 1460,nop,nop,sackOK> ...
CAPO内容：
firepower# show capture CAPO 1: 05:20:36.654507 802.1Q vlan#202 P0 192.168.0.100.22195 > 10.10.1.100.80: S 2866789268:2866789268(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 05:20:36.904478 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4785344:4785344(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 05:20:36.904997 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4785345 win 0 4: 05:20:37.414269 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4235354730:4235354730(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 05:20:37.414758 802.1Q vlan#202 P0 10.10.1.100.80 > 192.168.0.100.22196: R 0:0(0) ack 4235354731 win 0 6: 05:20:37.914305 802.1Q vlan#202 P0 192.168.0.100.22196 > 10.10.1.100.80: S 4118617832:4118617832(0) win 8192 <mss 1380,nop,nop,sackOK>
此图显示了在Wireshark中捕获CAPI。
关键点
- 源发送TCP SYN数据包。
- TCP RST被发送到源。
- 源重新传输TCP SYN数据包。
- MAC地址正确（在入口数据包上，源MAC地址属于下游路由器，目的MAC地址属于防火墙INSIDE接口）。
下图显示了在Wireshark中捕获CAPO的过程：
关键点
- 源发送TCP SYN数据包。
- TCP RST到达外部接口。
- 源重新传输TCP SYN数据包。
- MAC地址正确（在出口数据包上，防火墙OUTSIDE是源MAC，上游路由器是目的MAC）。
根据2个捕获结果，可以得出以下结论：
- 客户端与服务器之间的TCP三次握手未完成
- TCP RST到达防火墙出口接口
- 防火墙与适当的上游和下游设备“对话”（基于MAC地址）
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查发送TCP RST的源MAC地址。
验证TCP SYN数据包中看到的目的MAC地址与TCP RST数据包中看到的源MAC地址相同。
此检查旨在确认以下两项：
- 验证没有非对称流。
- 检验MAC是否属于预期的上游设备。
操作2.比较入口和出口数据包。
目视比较Wireshark上的2个数据包，以验证防火墙是否未修改/损坏数据包。突出显示了一些预期差异。
关键点
- 时间戳不同。另一方面，差异必须小而合理。这取决于应用于数据包的功能和策略检查以及设备上的负载。
- 数据包的长度可能不同，特别是如果仅在一端有防火墙添加/删除的dot1Q报头。
- MAC地址不同。
- 如果捕获是在子接口上进行的，则可以有dot1Q报头。
- 如果对数据包应用NAT或端口地址转换(PAT)，则IP地址不同。
- 如果NAT或PAT应用于数据包，源或目标端口会有所不同。
- 如果禁用Wireshark相对序列号选项，则会看到由于初始序列号(ISN)随机化，防火墙修改了TCP序列号/确认号。
- 某些TCP选项可能会被覆盖。例如，防火墙默认将TCP最大段大小(MSS)更改为1380，以避免传输路径中的数据包分段。
操作3.在目的地捕获。
如果可能，在目标本身捕获。如果这不可能，请捕获尽可能靠近目的地。此处的目标是验证谁发送TCP RST（是目的服务器还是路径中的其他设备？）。
案例3.来自一个终端的TCP三次握手+ RST
下图显示拓扑：
问题说明:HTTP不起作用
受影响的流：
源IP:192.168.0.100
目的IP:10.10.1.100
协议：TCP 80
捕获分析
在FTD LINA引擎上启用捕获。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
捕获 — 非功能场景：
此问题在捕获中可以通过几种不同的方式显示。
3.1 — 来自客户端的TCP三次握手+延迟RST
如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。
关键点
- TCP三次握手通过防火墙。
- 服务器重新传输SYN/ACK。
- 客户端重新传输ACK。
- 约20秒后，客户端放弃并发送TCP RST。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.尽可能靠近两个终端捕获。
防火墙捕获表明服务器未处理客户端ACK。这基于以下事实：
- 服务器重新传输SYN/ACK。
- 客户端重新传输ACK。
- 客户端在任何数据之前发送TCP RST或FIN/ACK。
服务器上的捕获显示了问题。来自TCP三次握手的客户端ACK从未到达：
3.2 - TCP三次握手+客户端延迟FIN/ACK +服务器延迟RST
如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。
关键点
- TCP三次握手通过防火墙。
- 约5秒后，客户端发送FIN/ACK。
- 约20秒后，服务器放弃并发送TCP RST。
根据此捕获，可以得出结论，虽然有TCP三次握手通过防火墙，但它似乎从未在一个终端上实际完成（重新传输表明这一点）。
推荐的操作
与案例3.1相同
3.3 — 来自客户端的TCP三次握手+延迟RST
如图所示，防火墙捕获CAPI和CAPO包含相同的数据包。
关键点
- TCP三次握手通过防火墙。
- 约20秒后，客户端放弃并发送TCP RST。
根据这些捕获，可以得出以下结论：
- 5-20秒后，一个终端放弃并决定终止连接。
推荐的操作
与案例3.1相同
3.4 — 来自服务器的TCP三次握手+即时RST
如图所示，两个防火墙都捕获CAPI和CAPO包含这些数据包。
关键点
- TCP三次握手通过防火墙。
- 在ACK数据包发生几毫秒后，服务器就出现了TCP RST。
推荐的操作
操作：尽可能靠近服务器捕获。
来自服务器的即时TCP RST可能表示路径中的故障服务器或发送TCP RST的设备。捕获服务器本身并确定TCP RST的源。
案例4.来自客户端的TCP RST
下图显示拓扑：
问题说明：HTTP不起作用。
受影响的流：
源IP:192.168.0.100
目的IP:10.10.1.100
协议：TCP 80
捕获分析
在FTD LINA引擎上启用捕获。
firepower# capture CAPI int INSIDE match ip host 192.168.0.100 host 10.10.1.100 firepower# capture CAPO int OUTSIDE match ip host 192.168.0.100 host 10.10.1.100
捕获 — 非功能场景：
这些是CAPI内容。
firepower# show capture CAPI 14 packets captured 1: 12:32:22.860627 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111307 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112390 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 4: 12:32:25.858109 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868698 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 6: 12:32:26.108118 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109079 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 8: 12:32:26.118295 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 9: 12:32:31.859925 192.168.0.100.47078 > 10.10.1.100.80: S 4098574664:4098574664(0) win 8192 <mss 1460,nop,nop,sackOK> 10: 12:32:31.860902 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 11: 12:32:31.875229 192.168.0.100.47078 > 10.10.1.100.80: R 1386249853:1386249853(0) win 0 12: 12:32:32.140632 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 13: 12:32:32.159995 192.168.0.100.47079 > 10.10.1.100.80: S 2486945841:2486945841(0) win 8192 <mss 1460,nop,nop,sackOK> 14: 12:32:32.160956 192.168.0.100.47079 > 10.10.1.100.80: R 3000518858:3000518858(0) win 0 14 packets shown
以下是CAPO内容：
firepower# show capture CAPO 11 packets captured 1: 12:32:22.860780 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 2: 12:32:23.111429 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3000518857:3000518857(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 3: 12:32:23.112405 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 3514091874:3514091874(0) win 0 4: 12:32:25.858125 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 1386249852:1386249852(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 5: 12:32:25.868729 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 2968892337:2968892337(0) win 0 6: 12:32:26.108240 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 3822259745:3822259745(0) win 8192 <mss 1380,nop,wscale 2,nop,nop,sackOK> 7: 12:32:26.109094 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 40865466:40865466(0) win 0 8: 12:32:31.860062 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: S 4294058752:4294058752(0) win 8192 <mss 1380,nop,nop,sackOK> 9: 12:32:31.860917 802.1Q vlan#202 P0 192.168.0.100.47078 > 10.10.1.100.80: R 1581733941:1581733941(0) win 0 10: 12:32:32.160102 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: S 4284301197:4284301197(0) win 8192 <mss 1380,nop,nop,sackOK> 11: 12:32:32.160971 802.1Q vlan#202 P0 192.168.0.100.47079 > 10.10.1.100.80: R 502906918:502906918(0) win 0 11 packets shown
防火墙日志显示：
firepower# show log | i 47741 Oct 13 2019 13:57:36: %FTD-6-302013: Built inbound TCP connection 4869 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:36: %FTD-6-302014: Teardown TCP connection 4869 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:39: %FTD-6-302013: Built inbound TCP connection 4870 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:39: %FTD-6-302014: Teardown TCP connection 4870 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE Oct 13 2019 13:57:45: %FTD-6-302013: Built inbound TCP connection 4871 for INSIDE:192.168.0.100/47741 (192.168.0.100/47741) to OUTSIDE:10.10.1.100/80 (10.10.1.100/80) Oct 13 2019 13:57:45: %FTD-6-302014: Teardown TCP connection 4871 for INSIDE:192.168.0.100/47741 to OUTSIDE:10.10.1.100/80 duration 0:00:00 bytes 0 TCP Reset-O from INSIDE
这些日志表明有TCP RST到达防火墙INSIDE接口
Wireshark中的CAPI捕获：
按照图中所示的第一个TCP数据流。
在Wireshark下，导航到Edit > Preferences > Protocols > TCP，并取消选择Relative sequence numbers选项，如图所示。
下图显示CAPI捕获中第一个流的内容：
关键点
- 客户端发送TCP SYN数据包。
- 客户端发送TCP RST数据包。
- TCP SYN数据包的序列号值等于4098574664。
CAPO捕获中的相同流包含：
关键点
- 客户端发送TCP SYN数据包。防火墙随机化ISN。
- 客户端发送TCP RST数据包。
根据这两个捕获，可以得出以下结论：
- 客户端和服务器之间没有TCP三次握手。
- 有一个来自客户端的TCP RST。CAPI捕获中的TCP RST序列号值为1386249853。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.捕获客户端。
根据在防火墙上收集的捕获信息，有强烈的非对称流指示。这基于以下事实：客户端发送值为1386249853的TCP RST（随机ISN）：
关键点
- 客户端发送TCP SYN数据包。序列号为4098574664，与防火墙INSIDE接口(CAPI)上看到的序列号相同
- 存在ACK号为1386249853的TCP SYN/ACK（由于ISN随机化，预期会出现）。 防火墙捕获中未看到此数据包
- 客户端发送TCP RST，因为它预期SYN/ACK的ACK号值为4098574665，但它收到的值为1386249853
这可视化为：
操作2.检查客户端和防火墙之间的路由。
确认：
- 捕获中看到的MAC地址是预期的MAC地址。
- 确保防火墙和客户端之间的路由是对称的。
在某些情况下，RST来自位于防火墙和客户端之间的设备，而内部网络中存在非对称路由。图中显示了一个典型案例：
在这种情况下，捕获包含此内容。注意TCP SYN数据包的源MAC地址与TCP RST的源MAC地址和TCP SYN/ACK数据包的目的MAC地址之间的差异：
firepower# show capture CAPI detail
1: 13:57:36.730217 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47740 > 10.10.1.100.80: S [tcp sum ok] 3045001876:3045001876(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25661)
2: 13:57:36.981104 4c4e.35fc.fcd8 00be.75f6.1dae 0x0800 Length: 66
192.168.0.100.47741 > 10.10.1.100.80: S [tcp sum ok] 3809380540:3809380540(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) (ttl 127, id 25662)
3: 13:57:36.981776 00be.75f6.1dae a023.9f92.2a4d 0x0800 Length: 66
10.10.1.100.80 > 192.168.0.100.47741: S [tcp sum ok] 1304153587:1304153587(0) ack 3809380541 win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK> (DF) (ttl 127, id 23339)
4: 13:57:36.982126 a023.9f92.2a4d 00be.75f6.1dae 0x0800 Length: 54
192.168.0.100.47741 > 10.10.1.100.80: R [tcp sum ok] 3809380541:3809380541(0) ack 1304153588 win 8192 (ttl 255, id 48501)
...
案例5.慢速TCP传输（场景1）
问题说明:
主机10.11.4.171和10.77.19.11之间的SFTP传输速度较慢。尽管两台主机之间的最小带宽(BW)为100 Mbps，但传输速度不会超过5 Mbps。
同时，主机10.11.2.124和172.25.18.134之间的传输速度也相当高。
背景理论:
单个TCP流的最大传输速度由带宽延迟产品(BDP)确定。 使用的公式如图所示：
有关BDP的更多详细信息，请点击此处查看资源：
- 为什么您的应用程序仅使用10Mbps，即使链路为1Gbps?
- BRKSEC-3021 — 高级 — 最大化防火墙性能
场景1.传输缓慢
下图显示拓扑：
受影响的流：
源IP:10.11.4.171
目的IP:10.77.19.11
协议：SFTP(FTP over SSH)
捕获分析
在FTD LINA引擎上启用捕获：
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.4.171 host 10.77.19.11
firepower# capture CAPI type raw-data trace interface inside match icmp any any WARNING: Running packet capture can have an adverse impact on performance.
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
往返时间(RTT)计算
首先，确定传输流并遵循它：
更改Wireshark视图以显示自上次显示的数据包以来的秒数。这简化了RTT的计算：
RTT可以通过添加两个数据包交换（一个指向源，一个指向目的）之间的时间值来计算。 在这种情况下，数据包#2显示防火墙与发送SYN/ACK数据包（服务器）的设备之间的RTT。 数据包#3显示防火墙与发送ACK数据包的设备（客户端）之间的RTT。 添加2个数字可以很好地估计端到端RTT:
RTT ≈ 80毫秒
TCP窗口大小计算
展开TCP数据包，展开TCP报头，选择“计算的窗口大小”并选择“应用为列”：
检查Calculated window size value列，查看TCP会话期间的最大窗口大小值。您还可以选择列名并对值进行排序。
如果测试文件下载(服务器>客户端)，则必须检查服务器通告的值。服务器通告的最大窗口大小值确定实现的最大传输速度。
在本例中，TCP窗口大小为≈ 50000字节
根据这些值，并使用带宽延迟积公式，您可以获得在以下条件下可以获得的最大理论带宽：50000*8/0.08 = 5 Mbps最大理论带宽。
这与客户端在此情况下的体验相符。
仔细检查TCP三次握手。两端（更重要的是服务器）通告窗口缩放值0，这表示2^0 = 1（无窗口缩放）。 这会对传输速率产生负面影响：
此时，需要在服务器上捕获，确认是通告窗口缩放= 0并重新配置它的人（您可能需要检查服务器文档如何执行此操作）。
场景2.快速传输
现在，我们来了解一下好的场景（通过同一网络快速传输）：
拓扑：
兴趣流：
源IP:10.11.2.124
目的IP:172.25.18.134
协议：SFTP(FTP over SSH)
在FTD LINA引擎上启用捕获
firepower# capture CAPI int INSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134 firepower# capture CAPO int OUTSIDE buffer 33554432 match ip host 10.11.2.124 host 172.25.18.134
往返时间(RTT)计算：在本例中，RTT为≈ 300毫秒。
TCP窗口大小计算：服务器通告TCP窗口缩放系数7。
服务器的TCP窗口大小为≈ 1600000字节：
根据这些值，带宽延迟产品公式给出：
1600000*8/0.3 = 43 Mbps最大理论传输速度
案例6.慢速TCP传输（场景2）
问题说明:通过防火墙的FTP文件传输（下载）速度较慢。
下图显示拓扑：
受影响的流：
源IP:192.168.2.220
目的IP:192.168.1.220
协议：FTP
捕获分析
在FTD LINA引擎上启用捕获。
firepower# capture CAPI type raw-data buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# cap CAPO type raw-data buffer 33554432 interface OUTSIDE match tcp host 192.168.2.220 host 192.168.1.220
选择FTP-DATA数据包，然后按照FTD INSIDE捕获(CAPI)上的FTP数据通道操作：
FTP-DATA流内容：
CAPO捕获内容：
关键点
- 有TCP无序(OOO)数据包。
- 存在TCP重新传输。
- 有丢包（丢弃的数据包）的迹象。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.确定丢包位置。
在这种情况下，您必须同时捕获并使用分治法确定导致数据包丢失的网段。从防火墙的角度来看，主要有3种场景：
- 数据包丢失是由防火墙本身引起的。
- 数据包丢失会在防火墙设备（从服务器到客户端的方向）的下游导致。
- 数据包丢失是在防火墙设备（从客户端到服务器的方向）的上游导致的。
防火墙导致的数据包丢失：为了确定数据包丢失是否由防火墙引起，需要将入口捕获与出口捕获进行比较。比较2个不同捕获的方法有很多种。本节演示了执行此任务的一种方法。
比较2个捕获以识别丢包的过程
步骤1.确保2个捕获包含来自同一时间窗口的数据包。这意味着一个捕获中在另一个捕获之前或之后捕获的数据包必须不存在。有几种方法可以做到这一点：
- 检查第一个和最后一个数据包IP标识(ID)值。
- 检查第一个和最后一个数据包时间戳值。
在本示例中，您可以看到每个捕获的第一个数据包具有相同的IP ID值：
以防它们不同：
- 比较每个捕获的第一个数据包的时间戳。
- 从具有最新时间戳的捕获中获取一个过滤器，该过滤器将时间戳过滤器从==更改到>=（第一个数据包）和<=（最后一个数据包），例如：
(frame.time >= "2019年10月16日16:13:43.244692000")&(frame.time <= "2019年10月16日16:20:21.785130000")
3.将指定的数据包导出到新捕获，选择“文件”>“导出指定的数据包”，然后保存“显示的数据包”。此时，两个捕获都必须包含覆盖同一时间窗口的数据包。现在可以开始比较2个捕获。
步骤2.指定哪个数据包字段用于比较2个捕获。可用字段示例：
- IP标识
- RTP序列号
- ICMP序列号
创建每个捕获的文本版本，其中包含您在步骤1中指定的每个数据包的字段。为此，请仅保留感兴趣的列，例如，如果要根据IP标识比较数据包，请修改捕获，如图所示。
结果：
步骤3.创建捕获的文本版本(文件>导出数据包断开>为纯文本……)，如图所示：
取消选中“包括”列标题和“数据包详细信息”选项，以仅导出显示字段的值，如图所示：
步骤4.对文件中的数据包进行排序。可以使用Linux sort命令执行以下操作：
# sort CAPI_IDs > file1.sorted # sort CAPO_IDs > file2.sorted
步骤5.使用文本比较工具（例如WinMerge）或Linux diff命令查找2个捕获之间的差异。
在这种情况下，FTP数据流量的CAPI和CAPO捕获是相同的。这证明数据包丢失不是由防火墙引起的。
识别上行/下行数据包丢失。
关键点
1.此数据包是TCP重新传输。具体而言，它是从客户端发送到服务器的TCP SYN数据包，用于在被动模式下传输FTP数据。由于客户端重新发送数据包，并且您可以看到初始SYN(数据包#1)数据包在防火墙上游丢失。
在这种情况下，SYN数据包甚至有可能到达服务器，但SYN/ACK数据包在返回途中丢失：
2.有一个来自服务器的数据包，Wireshark发现之前的数据段未被看到/捕获。由于未捕获的数据包是从服务器发送到客户端的，在防火墙捕获中未发现，这意味着数据包在服务器和防火墙之间丢失。
这表示FTP服务器和防火墙之间存在数据包丢失。
操作2.执行其他捕获。
在终端上执行其他捕获和捕获。尝试应用分治法进一步隔离导致数据包丢失的有问题数据段。
关键点
- 接收方（本例中为FTP客户端）跟踪传入的TCP序列号。如果检测到数据包丢失（跳过了预期序列号），则会生成ACK数据包，其中ACK='跳过的预期序列号'。 在本例中，Ack=2224386800。
- Dup ACK触发TCP快速重传（在收到重复ACK后20毫秒内重新传输）。
重复ACK意味着什么？
- 几个重复的ACK，但没有实际的重新传输表明更有可能有数据包到达顺序混乱。
- 重复的ACK后跟实际的重新传输，表明存在一定数量的丢包。
操作3.计算传输数据包的防火墙处理时间。
在2个不同接口上应用相同的捕获：
firepower# capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.2.220 host 192.168.1.220 firepower# capture CAPI interface OUTSIDE
导出捕获检查入口数据包与出口数据包之间的时间差
案例7. TCP连接问题（数据包损坏）
问题说明:
无线客户端(192.168.21.193)尝试连接到目的服务器(192.168.14.250 - HTTP)，并且有两种不同的方案：
- 当客户端连接到接入点(AP)“A”时，HTTP连接不工作。
- 当客户端连接到接入点(AP)“B”时，HTTP连接会正常工作。
下图显示拓扑：
受影响的流：
源IP:192.168.21.193
目的IP:192.168.14.250
协议：TCP 80
捕获分析
在FTD LINA引擎上启用捕获：
firepower# capture CAPI int INSIDE match ip host 192.168.21.193 host 192.168.14.250 firepower# capture CAPO int OUTSIDE match ip host 192.168.21.193 host 192.168.14.250
捕获 — 功能场景：
作为基线，从工作场景中捕获数据始终非常有用。
此图显示了在NGFW INSIDE接口上捕获的数据
此图显示了在NGFW OUTSIDE接口上捕获的数据。
关键点
- 2个捕获几乎相同（考虑ISN随机化）。
- 没有丢包的迹象。
- 无无序(OOO)数据包
- 有3个HTTP GET请求。第一个收到404个“未找到”，第二个收到200个“确定”，第三个收到304个“未修改”重定向消息。
捕获 — 非工作场景：
入口捕获(CAPI)内容。
关键点
- 存在TCP三次握手。
- 有TCP重新传输和丢包指示。
- Wireshark将数据包(TCP ACK)标识为格式错误。
此图显示出口捕获(CAPO)内容。
关键点
2个捕获几乎相同（考虑ISN随机化）：
- 存在TCP三次握手。
- 有TCP重新传输和丢包指示。
- Wireshark将数据包(TCP ACK)标识为格式错误。
检查格式错误的数据包：
关键点
- 数据包被Wireshark识别为格式不正确。
- 其长度为2字节。
- TCP负载为2字节。
- 负载为4个额外零(00 00)。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获，包括终端捕获，如果可能，尝试应用分治法来隔离数据包损坏的源，例如
在这种情况下，交换机“A”接口驱动程序添加了额外的2个字节，解决方案是更换导致损坏的交换机。
案例8. UDP连接问题（缺少数据包）
问题说明:目标系统日志服务器上未显示系统日志(UDP 514)消息。
下图显示拓扑：
受影响的流：
源IP:192.168.1.81
目的IP:10.10.1.73
协议：UDP 514
捕获分析
在FTD LINA引擎上启用捕获：
firepower# capture CAPI int INSIDE trace match udp host 192.168.1.81 host 10.10.1.73 eq 514 firepower# capture CAPO int OUTSIDE match udp host 192.168.1.81 host 10.10.1.73 eq 514
FTD捕获显示无数据包：
firepower# show capture capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog capture CAPO type raw-data interface OUTSIDE [Capturing - 0 bytes] match udp host 192.168.1.81 host 10.10.1.73 eq syslog
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查FTD连接表。
要检查特定连接，可以使用以下语法：
firepower# show conn address 192.168.1.81 port 514
10 in use, 3627189 most used
Inspect Snort:
preserve-connection: 6 enabled, 0 in effect, 74 most enabled, 0 most in effect
UDP INSIDE 10.10.1.73:514 INSIDE 192.168.1.81:514, idle 0:00:00, bytes 480379697, flags -oN1
关键点
- 入口和出口接口相同(U-turn)。
- 字节数的值非常大(~5 GBytes)。
- 标志“o”表示流分流（硬件加速流）。 这就是FTD捕获不显示任何数据包的原因。仅41xx和93xx平台支持流分流。在本例中，设备是41xx。
操作2.执行机箱级捕获。
连接到Firepower机箱管理器，并在入口接口（本例中为E1/2）和背板接口（E1/9和E1/10）上启用捕获，如图所示：
几秒钟后：
之前：
在:
关键点
- 应用显示过滤器以删除重复的数据包并仅显示系统日志。
- 数据包之间的差异在微秒级。这表示数据包速率非常高。
- 生存时间(TTL)值持续减少。这表示数据包环路。
操作3.使用Packet Tracer。
由于数据包不会通过防火墙LINA引擎，因此您无法执行实时跟踪（捕获w/trace），但您可以使用packet-tracer跟踪模拟数据包：
firepower# packet-tracer input INSIDE udp 10.10.1.73 514 192.168.1.81 514 Phase: 1 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Phase: 2 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 3 Type: FLOW-LOOKUP Subtype: Result: ALLOW Config: Additional Information: Found flow with id 25350892, using existing flow Phase: 4 Type: SNORT Subtype: Result: ALLOW Config: Additional Information: Snort Verdict: (fast-forward) fast forward this flow Phase: 5 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 192.168.1.81 using egress ifc INSIDE Phase: 6 Type: ADJACENCY-LOOKUP Subtype: next-hop and adjacency Result: ALLOW Config: Additional Information: adjacency Active next-hop mac address a023.9f92.2a4d hits 1 reference 1 Phase: 7 Type: CAPTURE Subtype: Result: ALLOW Config: Additional Information: MAC Access list Result: input-interface: INSIDE input-status: up input-line-status: up output-interface: INSIDE output-status: up output-line-status: up Action: allow
操作4.确认FTD路由。
检查防火墙路由表，查看是否存在路由问题：
firepower# show route 10.10.1.73
Routing entry for 10.10.1.0 255.255.255.0
Known via "eigrp 1", distance 90, metric 3072, type internal
Redistributing via eigrp 1
Last update from 192.168.2.72 on OUTSIDE, 0:03:37 ago
Routing Descriptor Blocks:
* 192.168.2.72, from 192.168.2.72, 0:02:37 ago, via OUTSIDE
Route metric is 3072, traffic share count is 1
Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 29/255, Hops 1
关键点
- 该路由指向正确的出口接口。
- 该路由是几分钟前(0:02:37)获知的。
操作5.确认连接正常运行时间。
检查连接正常运行时间，查看此连接何时建立：
firepower# show conn address 192.168.1.81 port 514 detail
21 in use, 3627189 most used
Inspect Snort:
preserve-connection: 19 enabled, 0 in effect, 74 most enabled, 0 most in effect
Flags: A - awaiting responder ACK to SYN, a - awaiting initiator ACK to SYN,
b - TCP state-bypass or nailed,
C - CTIQBE media, c - cluster centralized,
D - DNS, d - dump, E - outside back connection, e - semi-distributed,
F - initiator FIN, f - responder FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - initiator data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, L - decap tunnel, M - SMTP data, m - SIP media
N - inspected by Snort (1 - preserve-connection enabled, 2 - preserve-connection in effect)
n - GUP, O - responder data, o - offloaded,
P - inside back connection, p - passenger flow
q - SQL*Net data, R - initiator acknowledged FIN,
R - UDP SUNRPC, r - responder acknowledged FIN,
T - SIP, t - SIP transient, U - up,
V - VPN orphan, v - M3UA W - WAAS,
w - secondary domain backup,
X - inspected by service module,
x - per session, Y - director stub flow, y - backup stub flow,
Z - Scansafe redirection, z - forwarding stub flow
UDP INSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 0s, uptime 3m49s, timeout 2m0s, bytes 4801148711
要点：
- 连接大约4分钟前建立（这是在路由表中安装EIGRP路由之前）
操作6.清除现有连接。
在这种情况下，数据包与已建立的连接匹配，并路由到错误的出口接口，导致环路。这是由于防火墙的操作顺序：
- 已建立连接查找（这比全局路由表查找优先）。
- 网络地址转换(NAT)查找 — UN-NAT（目标NAT）阶段优先于PBR和路由查找。
- 基于策略的路由 (PBR)
- 全局路由表查找
由于连接从不超时（Syslog客户端在UDP连接空闲超时为2分钟时持续发送数据包），因此需要手动清除连接：
firepower# clear conn address 10.10.1.73 address 192.168.1.81 protocol udp port 514 1 connection(s) deleted.
验证是否已建立新连接：
firepower# show conn address 192.168.1.81 port 514 detail | b 10.10.1.73.*192.168.1.81
UDP OUTSIDE: 10.10.1.73/514 INSIDE: 192.168.1.81/514,
flags -oN1, idle 1m15s, uptime 1m15s, timeout 2m0s, bytes 408
操作7.配置浮动连接超时。
这是解决该问题并避免次优路由（尤其是UDP流）的正确解决方案。导航至设备>平台设置>超时并设置值：
您可以在命令参考中找到有关浮动连接超时的更多详细信息：
案例9. HTTPS连接问题（场景1）
问题说明:客户端192.168.201.105和服务器192.168.202.101之间无法建立HTTPS通信
下图显示拓扑：
受影响的流：
源IP:192.168.201.111
目的IP:192.168.202.111
协议：TCP 443(HTTPS)
捕获分析
在FTD LINA引擎上启用捕获：
由于端口地址转换配置，OUTSIDE捕获中使用的IP不同。
firepower# capture CAPI int INSIDE match ip host 192.168.201.111 host 192.168.202.111 firepower# capture CAPO int OUTSIDE match ip host 192.168.202.11 host 192.168.202.111
下图显示了在NGFW INSIDE接口上捕获的数据：
关键点
- 存在TCP三次握手。
- SSL协商开始。客户端发送客户端Hello消息。
- 向客户端发送TCP ACK。
- 向客户端发送TCP RST。
此图显示了在NGFW OUTSIDE接口上捕获的数据。
关键点
- 存在TCP三次握手。
- SSL协商开始。客户端发送客户端Hello消息。
- 从防火墙向服务器发送TCP重新传输。
- 向服务器发送TCP RST。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获。
在服务器上捕获的数据显示，服务器收到TLS客户端Hello，其TCP校验和已损坏，并以静默方式丢弃它们（没有TCP RST或任何其他发往客户端的应答数据包）：
当您将一切放在一起时：
在这种情况下，要了解发生的情况，需要在Wireshark上启用Validate the TCP checksum ef posible（如果可能）选项。导航至Edit > Preferences > Protocols > TCP，如图所示。
在这种情况下，将捕获信息并排放置以获得完整图景很有帮助：
关键点
- 存在TCP三次握手。IP ID相同。这表示该流未被防火墙代理。
- TLS客户端Hello来自IP ID 12083的客户端。数据包由防火墙代理（在本例中，防火墙配置了TLS解密策略），而IP ID更改为52534。此外，数据包TCP校验和损坏（由于软件缺陷，后来修复了）。
- 防火墙处于TCP代理模式，并向客户端发送ACK（欺骗服务器）。
- 防火墙不会从服务器接收任何TCP ACK数据包并重新传输TLS客户端Hello消息。这又是由于防火墙激活的TCP代理模式。
- 约30秒后，防火墙放弃并向客户端发送TCP RST。
- 防火墙向服务器发送TCP RST。
参考：
案例10. HTTPS连接问题（场景2）
问题说明：FMC智能许可证注册失败。
下图显示拓扑：
受影响的流：
源IP:192.168.0.100
目标：tools.cisco.com
协议：TCP 443(HTTPS)
捕获分析
在FMC管理接口上启用捕获：
尝试重新注册。出现“Error（错误）”消息后，按CTRL-C停止捕获：
root@firepower:/Volume/home/admin# tcpdump -i eth0 port 443 -s 0 -w CAP.pcap HS_PACKET_BUFFER_SIZE is set to 4. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C264 packets captured <- CTRL-C 264 packets received by filter 0 packets dropped by kernel root@firepower:/Volume/home/admin#
从FMC(System > Health > Monitor)收集捕获信息，选择设备并选择Advanced Troubleshooting，如图所示：
图中显示了Wireshark上的FMC捕获：
按照其中一个TCP流(Follow > TCP Stream)，如图所示。
关键点
- 存在TCP三次握手。
- 客户端(FMC)向智能许可门户发送SSL客户端Hello消息。
- SSL会话ID为0。这表示它不是已恢复的会话。
- 目标服务器回复“服务器问候”、“证书”和“服务器问候完成”消息。
- 客户端发送SSL致命警报，抱怨“未知CA”。
- 客户端发送TCP RST以关闭会话。
- 整个TCP会话持续时间（从建立到关闭）约为0.5秒。
选择服务器证书并展开颁发者字段以查看commonName。在本例中，公用名称显示执行中间人(MITM)的设备。
此图显示如下：
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.执行其他捕获。
在传输防火墙设备上捕获：
CAPI显示：
CAPO显示：
这些捕获证明传输防火墙修改了服务器证书(MITM)
操作2.检查设备日志。
您可以收集FMC TS捆绑包，如本文档所述：
在本例中，/dir-archives/var-log/process_stdout.log文件显示如下消息：
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-ERROR: ch_pf_curl_send_msg[494],
failed to perform, err code 60, err string "SSL peer certificate or SSH remote key was not OK" ...
SOUT: 10-23 05:45:14 2019-10-23 05:45:36 sla[10068]: *Wed .967 UTC: CH-LIB-TRACE: ch_pf_curl_is_cert_issue[514],
cert issue checking, ret 60, url "https://tools.cisco.com/its/
推荐方案
禁用特定流的MITM，以便FMC能够成功注册到智能许可云。
案例11. IPv6连接问题
问题说明:内部主机（位于防火墙的INSIDE接口后）无法与外部主机（位于防火墙的OUTSIDE接口后的主机）通信。
下图显示拓扑：
受影响的流：
源IP:fc00:1:1:1::100
目的IP:fc00:1:1:2::2
协议：any
捕获分析
在FTD LINA引擎上启用捕获。
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
捕获 — 非功能场景
这些捕获与从IP fc00:1:1:1::100（内部路由器）到IP fc00:1:1:2::2（上游路由器）的ICMP连接测试并行进行。
防火墙INSIDE接口上的捕获包含：
关键点
- 路由器发送IPv6邻居请求消息，询问上游设备的MAC地址(IP fc00:1:1:1::1)。
- 防火墙回复IPv6邻居通告。
- 路由器发送ICMP回应请求。
- 防火墙发送IPv6邻居请求消息，询问下游设备的MAC地址(fc00:1:1:1::100)。
- 路由器回复IPv6邻居通告。
- 路由器发送其他IPv6 ICMP回应请求。
防火墙OUTSIDE接口上的捕获包含：
关键点
- 防火墙发送IPv6邻居请求消息，询问上游设备的MAC地址(IP fc00:1:1:2::2)。
- 路由器回复IPv6邻居通告。
- 防火墙发送IPv6 ICMP回应请求。
- 上游设备(路由器fc00:1:1:2::2)发送IPv6邻居请求消息，询问IPv6地址fc00:1:1:1::100的MAC地址。
- 防火墙会发送额外的IPv6 ICMP回应请求。
- 上游路由器发送另一条IPv6邻居请求消息，询问IPv6地址fc00:1:1:1::100的MAC地址。
第4点非常有趣。通常，上游路由器会请求防火墙外部接口(fc00:1:1:2::2)的MAC地址，但会请求fc00:1:1:1::100。这表示配置错误。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查IPv6邻居表。
防火墙IPv6邻居表已正确填充。
firepower# show ipv6 neighbor | i fc00 fc00:1:1:2::2 58 4c4e.35fc.fcd8 STALE OUTSIDE fc00:1:1:1::100 58 4c4e.35fc.fcd8 STALE INSIDE
操作2.检查IPv6配置。
这是防火墙配置。
firewall# show run int e1/2 ! interface Ethernet1/2 nameif INSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.0.1 255.255.255.0 ipv6 address fc00:1:1:1::1/64 ipv6 enable firewall# show run int e1/3.202 ! interface Ethernet1/3.202 vlan 202 nameif OUTSIDE cts manual propagate sgt preserve-untag policy static sgt disabled trusted security-level 0 ip address 192.168.103.96 255.255.255.0 ipv6 address fc00:1:1:2::1/64 ipv6 enable
上游设备配置显示配置错误：
Router# show run interface g0/0.202 ! interface GigabitEthernet0/0.202 encapsulation dot1Q 202 vrf forwarding VRF202 ip address 192.168.2.72 255.255.255.0 ipv6 address FC00:1:1:2::2/48
捕获 — 功能方案
子网掩码（从/48更改为/64）解决了此问题。这是功能场景中的CAPI捕获。
要点：
- 路由器发送IPv6邻居请求消息，询问上游设备的MAC地址(IP fc00:1:1:1::1)。
- 防火墙回复IPv6邻居通告。
- 路由器发送ICMP回应请求并获取回应应答。
CAPO内容：
关键点
- 防火墙发送IPv6邻居请求消息，询问上游设备的MAC地址(IP fc00:1:1:2::2)。
- 防火墙回复IPv6邻居通告。
- 防火墙发送ICMP回应请求。
- 路由器发送IPv6邻居请求消息，询问下游设备的MAC地址(IP fc00:1:1:1::1)。
- 防火墙回复IPv6邻居通告。
- 防火墙发送ICMP回应请求并获取回应应答。
案例12.间歇性连接问题（ARP中毒）
问题说明:内部主机(192.168.0.x/24)与同一子网中的主机存在间歇性连接问题
下图显示拓扑：
受影响的流：
源IP:192.168.0.x/24
目的IP:192.168.0.x/24
协议：any
内部主机的ARP缓存似乎被毒化：
捕获分析
在FTD LINA引擎上启用捕获
此捕获仅捕获INSIDE接口上的ARP数据包：
firepower# capture CAPI_ARP interface INSIDE ethernet-type arp
捕获 — 非功能场景：
防火墙INSIDE接口上的捕获包含。
关键点
- 防火墙在192.168.0.x/24网络中接收各种IP ARP请求
- 防火墙使用自己的MAC地址回复所有防火墙（代理ARP）
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.检查NAT配置。
根据NAT配置，有些情况下，no-proxy-arp关键字可以阻止以上行为：
firepower# show run nat nat (INSIDE,OUTSIDE) source static NET_1.1.1.0 NET_2.2.2.0 destination static NET_192.168.0.0 NET_4.4.4.0 no-proxy-arp
操作2.禁用防火墙接口上的代理ARP功能。
如果“no-proxy-arp”关键字无法解决问题，请考虑禁用接口本身的代理ARP。如果是FTD，在撰写本文时，您必须使用FlexConfig并部署以下命令（指定适当的接口名称）。
sysopt noproxyarp INSIDE
案例13.识别导致CPU丢包的SNMP对象标识符(OID)
本例演示了如何根据对SNMP第3版(SNMPv3)数据包捕获的分析，将内存轮询的某些SNMP OID确定为CPU主机（性能问题）的根本原因。
问题说明:数据接口的超限量持续增加。进一步的故障排除表明，也有CPU主机（由SNMP进程引起）是导致接口超限的根本原因。
故障排除过程的下一步是确定SNMP进程导致的CPU主机的根本原因，特别是缩小问题范围，以识别轮询可能导致CPU主机的SNMP对象标识符(OID)。
目前，FTD LINA引擎不为实时轮询的SNMP OID提供“show”命令。轮询的SNMP OID列表可从SNMP监控工具中检索，但在本例中，存在以下限制因素：
- FTD管理员无权访问SNMP监控工具
- 在FTD上配置了具有身份验证和数据加密的SNMP第3版，以保护隐私
捕获分析
由于FTD管理员拥有SNMP第3版身份验证和数据加密的凭证，因此提出了以下行动计划：
- 捕获SNMP数据包
- 保存捕获并使用Wireshark SNMP协议首选项指定SNMP第3版凭证以解密SNMP第3版数据包。解密的捕获用于分析和检索SNMP OID
在snmp-server主机配置中使用的接口上配置SNMP数据包捕获：
firepower# show run snmp-server | include host snmp-server host management 192.168.10.10 version 3 netmonv3 firepower# show ip address management System IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG Current IP Address: Interface Name IP address Subnet mask Method Management0/0 management 192.168.5.254 255.255.255.0 CONFIG firepower# capture capsnmp interface management buffer 10000000 match udp host 192.168.10.10 host 192.168.5.254 eq snmp firepower# show capture capsnmp capture capsnmp type raw-data buffer 10000000 interface outside [Capturing - 9512 bytes] match udp host 192.168.10.10 host 192.168.5.254 eq snmp
关键点
- SNMP源地址和目的地址/端口。
- 无法解码SNMP协议PDU，因为Wireshark未知privKey。
- encryptedPDU基元的值。
推荐的操作
本节中列出的操作旨在进一步缩小问题范围。
操作1.解密SNMP捕获。
保存捕获并编辑Wireshark SNMP协议首选项，以指定SNMP第3版凭证来解密数据包。
firepower# copy /pcap capture: tftp: Source capture name [capsnmp]? Address or name of remote host []? 192.168.10.253 Destination filename [capsnmp]? capsnmp.pcap !!!!!! 64 packets copied in 0.40 secs
打开Wireshark上的捕获文件，选择SNMP数据包，然后导航到Protocol Preferences > Users Table，如图所示：
在“SNMP用户”(SNMP Users)表中，指定了SNMP第3版用户名、身份验证模型、身份验证密码、隐私协议和隐私密码（实际凭据如下所示）：
应用SNMP用户设置后，Wireshark显示已解密的SNMP PDU:
关键点
- SNMP监控工具使用SNMP getBulkRequest查询和浏览父OID 1.3.6.1.4.1.9.9.221.1和相关OID。
- FTD对每个getBulkRequest做出响应，其get-response包含与1.3.6.1.4.1.9.9.221.1相关的OID。
操作2.识别SNMP OID。
SNMP对象导航器显示OID 1.3.6.1.4.1.9.9.221.1属于名为CISCO-ENHANCED-MEMPOOL-MIB的管理信息库(MIB)，如图所示：
要在Wireshark中以人可读格式显示OID，请执行以下步骤：
- 下载MIB CISCO-ENHANCED-MEMPOOL-MIB及其依赖项，如图所示：
2.在Wireshark的“编辑”>“首选项”>“名称解析”窗口中，选中了“启用OID解析”。在“SMI（MIB和PIB路径）”窗口中，指定包含下载的MIB的文件夹和在SMI（MIB和PIB模块）中。 CISCO-ENHANCED-MEMPOOL-MIB会自动添加到模块列表：
3.重新启动Wireshark后，OID解析即被激活：
根据捕获文件的解密输出，SNMP监控工具定期（10秒间隔）轮询有关FTD上内存池利用率的数据。如TechNote文章ASA SNMP Polling for Memory-Related Statistics中所述，使用SNMP轮询全局共享池(GSP)利用率会导致CPU挂起。在本例中，从捕获中可以清楚地看到，全局共享池利用率是作为SNMP getBulkRequest基元的一部分定期轮询的。
为了将SNMP进程导致的CPU主机数降至最低，建议遵循文章中提到的SNMP的CPU主机数的缓解步骤，并避免轮询与GSP相关的OID。如果没有SNMP轮询OID，则不会观察到SNMP进程导致的CPU挂起，并且溢出率显着降低。
相关信息
反馈