AVL Code
全部案例
#010 · 流量封包分析

案例研究 · 流量封包分析

複雜業務系統網路故障分析定位

一位要排查複雜業務系統網路故障的維運工程師，重新診斷某單位服務數千萬使用者的雲平台網路沉痾——該單位 10G 網閘曾因內外網流量放大近 10 倍近乎當機，當年反覆擷取封包也未找到迴圈直接證據。他把 3 個流量包的路徑交給 AVL Code，約 15 分鐘後手裡多了一份 HTML + Markdown 雙格式的根因定位報告。

對象：3 個 pcap 流量包（524MB / 629MB / 1,074MB，共約 2.2GB）· 平台：Windows 工作目錄· 約束：無需安裝配置任何額外工具· 模型：瀾砥 N2.5· 交付：network_fault_report.html + .md（另含匿名化交付版）

檢視會話內容 下載會話存檔 可匯入 AVL Code 工作區重播完整對話 線上檢視成果

會話回放與報告為簡體中文原始記錄 · 生成依據：AVL Code + 瀾砥大模型

概覽

  1. 01

    解析內網雙包 — 定位突發流與 DNS 全量無回應

    你把 flow2 目錄下兩個流量包交給 AVL Code。它會穿越沙箱限制與子 Agent 逾時，最終交出第一版五條故障分析報告。

  2. 02

    複盤卡點 — 固化大 pcap 四步分析法

    你追問「任務時間過長是否出錯」，得到 4 個真實卡點清單，以及後續不再卡住的四步分析路徑。

  3. 03

    外網包交叉驗證 — 坐實根因鏈並產出雙格式報告

    你補上外網連接埠鏡像的第三包，內外網視角互相印證，生成 HTML 視覺化與 Markdown 雙格式最終報告。

  4. 04

    拓撲校正與匿名化 — 交付可歸檔報告

    你補充真實拓撲文件修正三處誤判，再把報告改為橫向佈局並做 IP 匿名化，另存為可對外的交付版。

向 AVL Code 發布任務

工作目錄下的flow2資料夾下是兩個流量包檔案，分析這兩個檔案，詳細分析其網路中可能的故障原因

前提：需要 flow2 目錄下的 3 個 pcap 與拓撲描述.md；環境為內建 sec.pcap_* 安全分析工具的 AVL Code（沙箱限制：sec.* 工具只讀取 samples/ 下的相對路徑）。文中 IP 均沿用會話匯出中已匿名化的「首段.x.x.x」形式

復現材料見文末 親自檢測 ↓

解析內網雙包

兩個 500MB+ 的流量包，先過沙箱與工具限制這一關：

你輸入 → AVL Code 
工作目錄下的flow2資料夾下是兩個流量包檔案，分析這兩個檔案，詳細分析其網路中可能的故障原因
AVL Code 執行 → 你會看到
copy/cmd/powershell/mklink 均被沙箱攔截 → 改用 Python 複製進 samples/
→ sec.pcap_info（top_n=50）· sec.pcap_extract 按協定層擷取
→ 定位突發流與 DNS 全量無回應（Query Refused）
→ 子 Agent 逾時自癒 → 第一版五條故障分析報告

復盤卡點

你追問「任務時間過長是否出錯」，得到的是一份卡點清單和一條固化路徑：

你輸入 → AVL Code 
任務時間過長，是不是出錯了？
AVL Code 執行 → 你會看到
4 個真實卡點逐條列出
→ 固化大 pcap 四步分析法：Python 複製進 samples/ → pcap_info → pcap_extract 限條數 → 跳過 stream_list 直接彙整

外網包交叉驗證

外網埠映像的第三包補上後，內外網視角互相印證：

你輸入 → AVL Code 
補上外網埠映像的第三包，做內外網交叉驗證。
AVL Code 執行 → 你會看到
內外網視角互證 → 坐實根因鏈
→ 產生 network_fault_report.html 視覺化 + .md 雙格式最終報告

拓撲校正與匿名化

交付前最後一道工序：按真實拓撲糾偏，再脫敏：

你輸入 → AVL Code 
按真實拓撲文件修正報告，改為橫向版面並做 IP 匿名化，另存交付版。
AVL Code 執行 → 你會看到
修正三處誤判
→ 報告改橫向版面
→ IP 匿名化（沿用「首段.x.x.x」形式）→ 另存可對外交付版

親自檢測

在同樣內建 sec.pcap_* 安全工具的 AVL Code 環境中，按會話固化的四步方案重現本案例的大 pcap 分析：

檢視會話內容 下載會話存檔 可匯入 AVL Code 工作區重播完整對話 線上檢視成果 
python -c "shutil.copy('<工作目錄>/flow2/<流量包>.pcap', 'samples/<流量包>.pcap')"
sec.pcap_info(path='<流量包>.pcap', top_n=50)
sec.pcap_extract(path='<流量包>.pcap', aspects=<HTTP/DNS/TLS 等>, limit_per_aspect=50)
  • 第 1 步：用 Python 把大 pcap 複製進 samples/（copy/cmd/powershell/mklink/fsutil 均被沙箱攔截，Python 已驗證可行）。
  • 第 2 步：主會話直接取 pcap 基本資訊（top_n=50 已驗證穩定，1-2 秒出結果）。
  • 第 3 步：按 aspects 提取協定層資訊，限制每類條數防止逾時。
  • 第 4 步：跳過 sec.pcap_stream_list（大檔案易逾時），基於已有資料直接彙總，輸出 flow2/network_fault_report.html 與 flow2/network_fault_report.md。
  • 局限說明：「結論與 5 年前現場觀察一致、10G 網閘放大近 10 倍」僅記錄於案例既有檔案（src/lib/cases/index.ts overview），會話與報告中未出現第二獨立來源；「全流程約 15 分鐘」同樣僅來自案例檔案，會話內無計時記錄。子 Agent 環節的實際工具呼叫回傳未在會話匯出中展開，過程描述以匯出中保留的敘述文字為準。

下一個問題： 拿到報告後，下一步自然是回到設備側驗證：檢查內網 DNS 伺服器的遞迴轉發配置消除 Query Refused，並核查外網交換器上 iSCSI/Oracle 流量的路由與 VLAN 劃分。