分析 Firepower 防火牆擷取，以有效針對網路問題進行疑難排解
目錄
簡介
本文件說明各種封包擷取分析技術，旨在有效對網路問題進行疑難排解。
必要條件
需求
思科建議您瞭解以下主題：
- Firepower平台架構
- NGFW日誌
- NGFW Packet Tracer
此外，開始分析資料包捕獲之前，強烈建議滿足以下要求：
- 瞭解協定操作 — 如果您不瞭解捕獲的協定如何運行，請不要開始檢查資料包捕獲。
- 瞭解拓撲 — 您必須瞭解端對端的傳輸裝置。如果這不可能，您至少必須知道上游和下游裝置。
- 瞭解設備 — 您必須瞭解裝置如何處理資料包、涉及的介面（入口/出口）、裝置架構是什麼，以及各種捕獲點。
- 瞭解組態 — 您必須知道裝置應該如何根據以下條件處理封包流：
- 路由/輸出介面
- 應用的策略
- 網路位址轉譯(NAT)
- 瞭解可用工具 — 除了捕獲之外，建議準備好應用其他工具和技術（如日誌記錄和跟蹤程式），並在需要時將其與捕獲的資料包相關聯
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- 大多數場景基於運行FTD軟體6.5.x的FP4140。
- FMC運行軟體6.5.x。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
資料包捕獲是當今最被忽視的故障排除工具之一。每天，Cisco TAC都可在分析捕獲的資料時解決許多問題。
本文檔的目標是幫助網路和安全工程師主要基於資料包捕獲分析來識別和排除常見網路問題。
本文提供的所有情境均基於思科技術協助中心(TAC)中可見的實際使用者案例。
本檔案從思科新世代防火牆(NGFW)的角度介紹封包擷取，但相同的概念同樣適用於其他裝置型別。
如何收集和匯出NGFW產品系列中的捕獲？
若是Firepower裝置(1xxx、21xx、41xx、93xx)和Firepower威脅防禦(FTD)應用程式，資料包處理視覺化，如下圖所示。
- 封包進入輸入介面，並由機箱內部交換器處理。
- 封包進入FTD Lina引擎，主要執行L3/L4檢查。
- 如果策略要求封包由Snort引擎檢查（主要是L7檢查）。
- Snort引擎傳回封包的判定結果。
- LINA 引擎根據 Snort 的判定結果捨棄或轉送封包.
- 封包透過內部機箱交換器離開機箱。
根據所示架構，FTD擷取可以在三(3)個不同地方進行：
- FXOS
- FTD Lina引擎
- FTD Snort引擎
收集FXOS捕獲
本檔案將說明此程式：
FXOS擷取只能從內部交換器視點沿輸入方向擷取，如下圖所示。
此處顯示，每個方向有兩個擷取點（由於內部交換器架構）。
點2、3和4中捕獲的資料包具有虛擬網路標籤(VNTag)。
啟用和收集FTD Lina擷取
主要捕獲點：
- 輸入介面
- 輸出介面
- 加速安全路徑(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
選擇Advanced Troubleshooting:
指定捕獲檔名並選擇 下載：
有關如何從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
Dst 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
這是CAPI捕獲在Wireshark中的影象：
重點：
- 只看到TCP SYN封包（無TCP三次握手）。
- 2個TCP會話（源埠3171和3172）無法建立。來源使用者端會重新傳送TCP SYN封包。這些重新傳輸的資料包由Wireshark識別為TCP重新傳輸。
- TCP重新傳輸每~3秒、每6秒進行一次。
- 源MAC地址來自正確的下游裝置。
根據2個擷取可得出以下結論：
- 特定5元組(src/dst IP、src/dst port、protocol)的資料包到達預期介面(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 IPs（在網路地址轉換的情況下）：
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
從輸出中可看出，追蹤軌跡顯示Action: 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
Dst 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>
此圖顯示CAPI在Wireshark中的捕獲。
重點：
- 來源傳送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上的兩個資料包，驗證防火牆沒有修改/損壞這些資料包。一些預期差異被突出顯示。
重點：
- 時間戳不同。另一方面，這種差異必須小而合理。這取決於應用於資料包的功能和策略檢查以及裝置上的負載。
- 資料包的長度可能會有所不同，尤其是如果防火牆僅在一端新增/刪除了dot1Q報頭。
- MAC地址不同。
- 如果捕獲是在子介面上進行的，則可以使用dot1Q報頭。
- 在將NAT或埠地址轉換(PAT)應用於資料包時，IP地址是不同的。
- 如果將NAT或PAT應用於資料包，則源埠或目標埠不同。
- 如果禁用Wireshark Relative Sequence Number選項，就會看到由於初始序列號(ISN)隨機化，防火牆修改了TCP序列號/確認號。
- 某些TCP選項可能被覆蓋。例如，防火牆預設會將TCP最大區段大小(MSS)變更為1380，以避免傳輸路徑中的封包分段。
行動3.在目標處執行捕獲。
如果可能，在目的地本身進行捕獲。如果無法實現，則使捕獲儘可能靠近目標。這裡的目標是驗證誰傳送了TCP RST（是目的地伺服器還是路徑中的其他裝置？）。
案例3.來自一個終端的TCP三次握手+ RST
下圖顯示拓撲：
問題說明：HTTP無法正常工作
受影響的流：
源IP:192.168.0.100
Dst 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，而CAPI包含這些封包，如下圖所示。
重點：
- TCP三次握手會通過防火牆。
- 在ACK封包過後幾毫秒時，伺服器會產生TCP RST。
建議的操作
操作：儘可能在靠近伺服器的位置捕獲捕獲。
來自伺服器的立即TCP RST可能表示伺服器故障或傳送TCP RST的路徑中的裝置。在伺服器本身進行捕獲，確定TCP RST的來源。
案例4.來自使用者端的TCP RST
下圖顯示拓撲：
問題說明：HTTP無法正常工作。
受影響的流：
源IP:192.168.0.100
Dst 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
這些日誌指示存在到達防火牆INSIDE介面的TCP RST
Wireshark中的CAPI捕獲：
如圖所示，跟隨第一個TCP資料流。
在Wireshark下，導航到編輯>首選項>協定> 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的更多詳細資訊，請在此處檢視資源：
- 為什麼即使鏈路為1Gbps，您的應用程式也只使用10Mbps?
- BRKSEC-3021 — 高級 — 最大化防火牆效能
案例 1.傳輸緩慢
下圖顯示拓撲：
受影響的流：
源IP:10.11.4.171
Dst IP:10.77.19.11
協定：SFTP（使用SSH的FTP）
捕獲分析
在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個封包交換（一個朝向來源，一個朝向目的地）之間加上時間值來計算。在這種情況下，封#2連線會顯示防火牆與傳送SYN/ACK封包的裝置（伺服器）之間的RTT。Packet #3顯示防火牆與傳送ACK封包的裝置（使用者端）之間的RTT。將兩個數字相加可很好地估計端到端RTT:
RTT ≈ 80毫秒
TCP視窗大小計算
展開TCP資料包，展開TCP報頭，選擇Calculated window size，然後選擇Apply as Column:
檢查Calculated window size value列，檢視TCP會話期間的最大視窗大小值。也可以選擇列名並對值排序。
如果測試檔案下載(server > client)，則必須檢查伺服器通告的值。伺服器通告的最大視窗大小值確定實現的最大傳輸速度。
在這種情況下，TCP視窗大小為≈ 50000 Bytes
基於這些值，並使用「頻寬延遲乘積」公式，您可以獲得在這些情況下可達到的最大理論頻寬：50000*8/0.08 = 5 Mbps的最大理論頻寬。
這與客戶端在此案例中的體驗相符。
仔細檢查TCP三次握手。兩端（更重要的是伺服器）都通告視窗縮放值0，這意味著2^0 = 1（無視窗縮放）。這會對傳輸速率產生負面影響：
此時，需要在伺服器上執行捕獲，確認是通告視窗比例= 0的捕獲者並重新配置它（有關如何執行此操作的資訊，請檢視伺服器文檔）。
案例 2.快速傳輸
現在來瞭解一下理想情況（透過同一個網路快速傳輸）：
拓撲：
利息流：
源IP:10.11.2.124
Dst IP:172.25.18.134
協定：SFTP（使用SSH的FTP）
在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為≈毫秒。
TCP視窗大小計算：伺服器通告TCP視窗比例因子7。
伺服器的TCP視窗大小為≈ 1600000位元組：
基於這些值，頻寬延遲產品公式可提供：
1600000*8/0.3 = 43 Mbps最大理論傳輸速度
案例6.TCP傳輸緩慢（案例2）
問題描述：通過防火牆的FTP檔案傳輸（下載）速度緩慢。
此圖顯示拓撲：
受影響的流：
源IP:192.168.2.220
Dst 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 capture(CAPI)上的FTP資料通道操作：
FTP-DATA流內容：
CAPO捕獲內容：
重點：
- 存在TCP亂序(OOO)封包。
- 存在TCP重新傳輸。
- 存在資料包丟失（丟棄的資料包）的指示。
建議的操作
本節所列的行動旨在進一步縮小問題範圍。
操作1.確定資料包丟失位置。
在這種情況下，您必須採用同時捕獲並使用「分治法」來識別導致資料包丟失的網路段。從防火牆的角度來看，主要有3種情況：
- 封包遺失是由防火牆本身造成的。
- 封包遺失會在防火牆裝置的下游（從伺服器到使用者端的方向）引起。
- 封包遺失是在防火牆裝置的上游（從使用者端到伺服器的方向）造成的。
防火牆導致的資料包丟失：為了確定資料包丟失是否由防火牆引起，需要將入口捕獲與出口捕獲進行比較。有很多方法可以比較兩種不同的捕獲。本節演示一種執行此任務的方法。
比較2個擷取以識別封包遺失的程式
步驟 1.確保2個捕獲包含來自同一時間視窗的資料包。這表示一個擷取中一定沒有封包是在另一個擷取之前或之後擷取。有幾種方法可以做到這一點：
- 檢查第一個和最後一個封包IP識別(ID)值。
- 檢查第一個和最後一個資料包的時間戳值。
在此範例中，您可以看到每個擷取的第一個封包具有相同的IP ID值：
如果它們不同，那麼：
- 比較每個捕獲的第一個資料包的時間戳。
- 從具有最新時間戳的捕獲獲取過濾器，從中將Timestamp過濾器從==更改為>=（第一個資料包）和<=（最後一個資料包）更改，例如：
(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.建立擷取的文字版本(「檔案」>「匯出封包分段」>「以純文本……」)，如下圖所示：
取消選中Include column headings和Packet details選項，以僅匯出所顯示欄位的值，如下圖所示：
步驟 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
Dst 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重新傳輸和資料包丟失指示。
- 有一個封包(TCP ACK)被Wireshark識別為Malformed。
此圖顯示輸出擷取(CAPO)內容。
重點：
2個捕獲幾乎完全相同（考慮ISN隨機化）：
- 有一個TCP三次握手。
- 存在TCP重新傳輸和資料包丟失指示。
- 有一個封包(TCP ACK)被Wireshark識別為Malformed。
檢查格式錯誤的資料包：
重點：
- 資料包被識別為Wireshark的Malformed。
- 長度為2個位元組。
- 有2個位元組的TCP負載。
- 負載是額外的4個0(00 00)。
建議的操作
本節所列的行動旨在進一步縮小問題範圍。
操作1.獲取其他捕獲。包括終端上的捕獲，如果可能，請嘗試應用分治法來隔離資料包損壞的來源，例如：
在這種情況下，交換器「A」介面驅動程式增加了額外的2位元組，解決方式是取代導致損毀的交換器。
案例8.UDP連線問題（缺少資料包）
問題描述：在目標Syslog伺服器上看不到系統日誌(UDP 514)消息。
下圖顯示拓撲：
受影響的流：
源IP:192.168.1.81
Dst 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擷取show no packets:
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 GB)。
- 標誌「o」表示流量分流（硬體加速流量）。這就是為什麼FTD擷取不顯示任何封包。僅41xx和93xx平台支援流量分流。在本例中，裝置是41xx。
行動2.獲取機箱級捕獲。
連線到Firepower機箱管理器，並在入口介面（本例中為E1/2）和背板介面（E1/9和E1/10）上啟用捕獲，如下圖所示：
幾秒鐘後：
之前：
之後：
重點：
- 應用顯示過濾器可刪除資料包重複項並僅顯示系統日誌。
- 資料包之間的差異處於微秒級別。這表示封包速率非常高。
- 生存時間(TTL)值持續減小。這表示封包回圈。
行動3.使用Packet Tracer。
由於封包沒有經過防火牆LINA引擎，因此您無法執行即時追蹤（擷取/追蹤），但可以使用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資料流尤其如此。導覽至Devices > Platform Settings > Timeouts，然後設定值：
有關浮動連線埠逾時的詳細資訊，請參閱命令參考：
案例9.HTTPS連線問題（場景1）
問題描述：無法建立客戶端192.168.201.105和伺服器192.168.202.101之間的HTTPS通訊
下圖顯示拓撲：
受影響的流：
源IP:192.168.201.111
Dst 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 if possible選項。導覽至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
Dst:tools.cisco.com
協定：TCP 443(HTTPS)
捕獲分析
在FMC管理介面上啟用捕獲：
再次嘗試註冊。出現錯誤資訊後，按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。這意味著它不是續會。
- 目標伺服器會使用Server Hello、Certificate和Server Hello Done消息進行回覆。
- 客戶端傳送有關「未知CA」的SSL致命警報。
- 使用者端傳送TCP RST以關閉作業階段。
- 整個TCP會話持續時間（從建立到關閉）約為0.5秒。
選擇Server Certificate，然後展開issuer欄位以檢視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
Dst IP:fc00:1:1:2::2
協定：任意
捕獲分析
在FTD LINA引擎上啟用擷取。
firepower# capture CAPI int INSIDE match ip any6 any6 firepower# capture CAPO int OUTSIDE match ip any6 any6
捕獲 — 非功能場景
這些捕獲與ICMP連線測試並行進行，ICMP連線測試從IP fc00:1:1:1::100（內部路由器）到IP fc00:1:1:2::2（上游路由器）。
防火牆INSIDE介面上的捕獲包含：
重點：
- 路由器傳送IPv6 Neighbor Solicitation消息並請求上游裝置的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
Dst IP:192.168.0.x/24
協定：任意
內部主機的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.在防火牆介面上停用proxy-arp功能。
如果「no-proxy-arp」關鍵字不能解決問題，請嘗試在介面本身上停用代理ARP。如果是FTD，則在撰寫本文時，您必須使用FlexConfig並部署命令（指定適當的介面名稱）。
sysopt noproxyarp INSIDE
案例13.標識導致CPU佔用的SNMP對象識別符號(OID)
此案例展示，如何根據對SNMP第3版(SNMPv3)封包擷取的分析，將某些用於記憶體輪詢的SNMP OID識別為CPU存取（效能問題）的根本原因。
問題描述：資料介面上的超限持續增加。進一步的研究表明，也有CPU存取（由SNMP進程引起）是介面超載的根本原因。
故障排除過程的下一步是確定由SNMP進程引起的CPU佔用問題的根本原因，尤其是縮小問題的範圍，以確定SNMP對象識別符號(OID)，在輪詢時，OID可能會導致CPU佔用問題。
目前，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 host配置的介面上配置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，因為privKey對Wireshark未知。
- 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 Users表中，指定了SNMP版本3使用者名稱、身份驗證模型、身份驗證密碼、隱私協定和隱私密碼（下面未顯示實際憑據）：
應用SNMP使用者設定後，Wireshark顯示已解密的SNMP PDU:
重點：
- SNMP監控工具使用SNMP getBulkRequest查詢和遍歷父OID 1.3.6.1.4.1.9.9.221.1和相關OID。
- FTD透過包含與1.3.6.1.4.1.9.9.221.1相關的OID的get-response回應每個getBulkRequest。
行動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。如果不對與GSP相關的OID進行SNMP輪詢，則不會觀察到由SNMP進程導致的CPU佔用，並且超支率顯著降低。
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
2.0 |
02-Jun-2023 |
重新認證 |
1.0 |
21-Nov-2019 |
初始版本 |
意見