AVL Code
All cases
#010 · Traffic Analysis

Case study · Traffic Analysis

Network Fault Localization in a Complex Business System

An ops engineer troubleshooting a complex business system re-diagnoses a chronic network ailment on a cloud platform serving tens of millions of users — the organization’s 10G isolation gateway once nearly froze as internal-external traffic amplified almost 10x, and repeated packet captures back then never produced direct evidence of a loop. He hands the paths of 3 captures to AVL Code, and about 15 minutes later holds a root-cause localization report in both HTML and Markdown.

Target: 3 pcap captures (524MB / 629MB / 1,074MB, about 2.2GB total)· Platform: a Windows working directory· Constraint: no extra tools to install or configure· Model: Landi N2.5· Deliverable: network_fault_report.html + .md (plus an anonymized delivery version)

View session Download session archive Import into your AVL Code workspace to replay the full conversation View live result

Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model

Overview

  1. 01

    Parse the two intranet captures — localize the burst flows and the DNS full non-response

    You hand AVL Code the two captures under the flow2 directory. It pushes through sandbox limits and a sub-agent timeout, and finally delivers the first five-point fault analysis report.

  2. 02

    Review the stalls — harden the four-step method for large pcaps

    You ask whether the long task time means something went wrong, and get a list of 4 real stalls plus a four-step analysis path that no longer gets stuck.

  3. 03

    Cross-validate the external capture — confirm the root-cause chain and produce the dual-format report

    You add the third capture, the external port mirror; the intranet and internet views corroborate each other, and the final report is generated in both HTML visualization and Markdown.

  4. 04

    Topology fix and anonymization — a report ready to archive

    You supply the real topology document to correct three misjudgments, then have the report switched to a landscape layout and IPs anonymized, saved separately as an externally shareable delivery version.

Task for AVL Code

The flow2 folder in the working directory contains two traffic capture files; analyze these two files and analyze in detail the possible network fault causes

Prerequisites: Requires the 3 pcaps under the flow2 directory and 拓扑描述.md; the environment is AVL Code with the built-in sec.pcap_* security analysis tools (sandbox limit: sec.* tools only read relative paths under samples/). All IPs in this article reuse the already-anonymized "first-octet.x.x.x" form from the session export

Reproduction materials at the end of this article Try it yourself ↓

Parsing the Two Internal Captures

Two 500 MB+ pcaps first have to clear the sandbox and tool limits:

You type → AVL Code 
The flow2 folder under the working directory contains two pcap files. Analyze them and explain in detail the possible causes of the network failure
AVL Code runs → you see
copy/cmd/powershell/mklink all blocked by the sandbox → switches to Python to copy into samples/
→ sec.pcap_info (top_n=50) · sec.pcap_extract per protocol layer
→ Locates the burst traffic and DNS failing wholesale (Query Refused)
→ Sub-agent timeout self-heals → the first five-point fault analysis report

Bottleneck Retrospective

You ask whether the long runtime means something went wrong — and get a bottleneck list plus a fixed path:

You type → AVL Code 
The task took too long — did something go wrong?
AVL Code runs → you see
4 real bottlenecks listed one by one
→ Fixes the four-step big-pcap method: Python-copy into samples/ → pcap_info → pcap_extract with capped counts → skip stream_list and summarize directly

External-Capture Cross-Validation

With the third, external-port-mirror capture added, the internal and external views corroborate each other:

You type → AVL Code 
Here is the third capture from the external port mirror — cross-validate internal and external views.
AVL Code runs → you see
Internal and external views corroborate → the root-cause chain is confirmed
→ Generates the final report in two formats: network_fault_report.html (visual) + .md

Topology Correction and Anonymization

The last step before delivery: correct against the real topology, then anonymize:

You type → AVL Code 
Correct the report against the real topology document, switch it to landscape layout, anonymize the IPs, and save a deliverable copy.
AVL Code runs → you see
Fixes three misjudgments
→ Switches the report to landscape layout
→ Anonymizes IPs (keeping the "first-octet.x.x.x" form) → saves a separate external deliverable

Try it yourself

In an AVL Code environment with the same built-in sec.pcap_* security tools, reproduce this case’s large-pcap analysis with the four-step method hardened in the session:

View session Download session archive Import into your AVL Code workspace to replay the full conversation View live result 
python -c "shutil.copy('<working directory>/flow2/<capture>.pcap', 'samples/<capture>.pcap')"
sec.pcap_info(path='<capture>.pcap', top_n=50)
sec.pcap_extract(path='<capture>.pcap', aspects=<HTTP/DNS/TLS etc.>, limit_per_aspect=50)
  • Step 1: use Python to copy the large pcap into samples/ (copy/cmd/powershell/mklink/fsutil are all blocked by the sandbox; Python was verified to work).
  • Step 2: pull the pcap basics directly in the main session (top_n=50 verified stable, results in 1–2 seconds).
  • Step 3: extract protocol-level information by aspects, capping the items per aspect to avoid timeouts.
  • Step 4: skip sec.pcap_stream_list (large files tend to time out) and summarize directly from the data already gathered, outputting flow2/network_fault_report.html and flow2/network_fault_report.md.
  • Limitations: "the conclusions match the on-site observations from 5 years earlier, with near-10x amplification across the 10G isolation gateway" is recorded only in the case’s existing archive (the overview in src/lib/cases/index.ts) — no second independent source appears in the session or the report; "about 15 minutes end to end" likewise comes only from the case archive, with no timing records in the session. The actual tool-call returns of the sub-agent stage are not expanded in the session export; the process description follows the narrative text preserved in the export.

Next question: With the report in hand, the natural next step is back on the device side: check the intranet DNS server’s recursive-forwarding configuration to clear the Query Refused, and verify the routing and VLAN layout for iSCSI/Oracle traffic on the external switch.