A10 Networks Thunder 實戰課程

故障排除 (Troubleshooting)

本章節將深入探討 A10 ACOS 系統中的進階故障排除工具。我們將重點放在 axdebug 封包側錄分析,以及如何有效解讀 show tech-support 與系統日誌,讓您能像外科醫生一樣精準診斷網路疑難雜症。

一、核心概念 (Concept)

一句話定義

axdebug 是 A10 專用的「硬體感知」封包擷取工具,能捕捉經過 FPGA/ASIC 加速的流量;而 Tech-Support 則是設備的「全身健康檢查報告」。

生活化比喻

想像高速公路 (網路流量) 上有裝設 ETC (ASIC 加速)。

一般的 Linux tcpdump 就像是「路邊的警察」,他只能看到走慢車道 (CPU) 的車,對於走 ETC 快速通道 (ASIC) 呼嘯而過的賽車完全看不到。

axdebug 就像是「高速攝影機」,不管車速多快、是否走 ETC 通道,都能精準拍下每一台車的照片。

二、運作原理 (Mechanism)

1. axdebug 的技術細節

  • 控制層面 vs. 數據層面: 標準的 tcpdump 只能抓取 Control Plane (CPU) 的封包。ACOS 架構中,大部分流量由 Data Plane (FPGA/ASIC) 處理。axdebug 指令會下達過濾規則給硬體晶片,將符合條件的封包「鏡像 (Mirror)」一份給 CPU 紀錄,因此能看到完整的流量。
  • 過濾器 (Filter) 的重要性: 因為硬體流量巨大,必須設定精確的 Filter (如 IP, Port),否則大量的 Debug 封包瞬間湧入 CPU 會導致設備效能下降 (High CPU Usage)。
  • 輸出格式: 支援將結果輸出為 .pcap 檔案,可直接下載並透過 Wireshark 分析。

2. 關鍵指令與參數

# 設定過濾條件 (抓取來自 192.168.1.50 的所有流量)
A10(config)# axdebug filter config 1 ip 192.168.1.50 /32

# 設定輸出到檔案 (儲存 3000 個封包)
A10(config)# axdebug capture save-config file my-capture.pcap count 3000

# 啟用 Debug
A10(config)# axdebug enable

# 停止並匯出
A10(config)# no axdebug enable
A10# export axdebug my-capture.pcap tftp://10.0.0.1/

3. 廠商對照 (Competitor View)

Feature A10 Networks F5 Networks Cisco (IOS)
封包側錄指令 axdebug tcpdump (需加 -nnni 0.0:nnnp) monitor capture
硬體加速流量 可直接抓取 需停用 PVA 或使用特定參數 需使用 Embedded Packet Capture
全系統檢測 show tech-support qkview show tech-support

三、架構視覺化 (Visuals)

以下展示 ACOS 系統中封包處理與 Debug 流程的垂直架構。

圖表 1: ACOS 封包處理與 axdebug 介入點

flowchart TD subgraph Client_Side User[使用者] end subgraph ACOS_Device Ingress[介面進站 Ingress] subgraph Hardware_ASIC [Data Plane / ASIC] L2L3[L2/L3 解析] Filter_Check{符合 axdebug Filter?} SLB_Logic[SLB 負載平衡決策] NAT[NAT 轉換] end subgraph Software_CPU [Control Plane / CPU] Debug_Engine[axdebug 引擎] Storage[(pcap 檔案)] end Egress[介面出站 Egress] end subgraph Server_Side Server[後端伺服器] end User -->|原始封包| Ingress Ingress --> L2L3 L2L3 --> Filter_Check Filter_Check -- 是 (Mirror Copy) --> Debug_Engine Debug_Engine -->|寫入| Storage Filter_Check -- 否 (原本路徑) --> SLB_Logic SLB_Logic --> NAT NAT --> Egress Egress -->|轉換後封包| Server style Filter_Check fill:#FF8200,stroke:#333,stroke-width:2px,color:white style Debug_Engine fill:#E6007E,stroke:#333,stroke-width:2px,color:white style Hardware_ASIC fill:#f0f9ff,stroke:#0047BB,stroke-dasharray: 5 5

圖表 2: 標準故障排除流程 (Sequence Diagram)

sequenceDiagram participant Admin as 管理員 participant ACOS as A10 Thunder participant Log as System Log participant Debug as axdebug Admin->>ACOS: 1. 接獲報修 (連線異常) Admin->>ACOS: show log (檢查歷史紀錄) ACOS-->>Admin: 回傳 Warning/Error Logs alt Log 資訊不足 Admin->>ACOS: 2. 設定 axdebug filter (IP/Port) Admin->>ACOS: 3. axdebug enable (開始側錄) Note over ACOS: 等待異常流量發生... Admin->>ACOS: 4. no axdebug enable (停止側錄) Admin->>ACOS: export axdebug (匯出 pcap) else Log 已有明確錯誤 (如 Pool Down) Admin->>ACOS: 直接修復配置 end Admin->>Admin: 5. 使用 Wireshark 分析 pcap Admin->>Admin: 6. 確認 3-Way Handshake 斷在哪

四、實務應用場景 (Use Case)

案例:電商平台偶發性結帳失敗

情境描述:
某電商平台在促銷期間,部分使用者反應點擊「結帳」後畫面轉圈圈,最後顯示連線逾時。但監控系統顯示伺服器綠燈,CPU 使用率正常。

處理步驟:

  1. 詢問受影響客戶的 Public IP (例如 203.66.x.x)。
  2. 登入 A10,設定 Filter:axdebug filter config 1 ip 203.66.x.x
  3. 設定抓取後端伺服器回應:同時監控 VIP 與 Real Server 的通訊。
  4. 啟用 axdebug 並請客戶重試結帳。
  5. 分析 pcap 發現:Client 送出 HTTP POST,A10 轉送給 Server,但 Server 回應了 RST (Reset) 封包,而非 ACK
  6. 結論: 問題出在後端應用程式崩潰主動斷線,而非網路不通。

優點與缺點分析

優點

證據確鑿,責任歸屬明確 (證明是 Server 端 Reset 連線,A10 網路層正常)。

缺點

需精確設定 Filter,若設定錯誤 (如抓取 any),可能導致 log 檔案過大或短暫影響效能。

五、隨堂測驗 (Quiz)

請回答下列問題以檢視學習成果。