arXiv CSopen access

SADE: Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting

SADE: Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting

arXiv:2605.04530v1 [cs.NI] 6 May 2026

Kuan-Hao Tseng*, Niruth Bogahawatta*, Yasod Ginige*, Kosta Dekic*, Arunan Sivanathan† , Suranga Seneviratne* *University of Sydney, Sydney, Australia † University of New South Wales, Sydney, Australia Email: [email protected], [email protected], [email protected], {firstname.lastname}@sydney.edu.au

Abstract—Large language model (LLM) agents are increasingly applied to network troubleshooting, but root-cause localization on public benchmarks remains well below practical deployment thresholds. We argue this is because existing agents do not encode the disciplined, layer-by-layer methodology that human network engineers use, and instead rely on free-form deliberation that conflates evidence acquisition with hypothesis commitment. We present SADE (Symptom-Aware Diagnostic Escalation), an agent that encodes the classical Cisco troubleshooting methodology as an explicit policy. SADE pairs a phase-gated diagnostic workflow, which separates evidence acquisition from hypothesis commitment, with a routed library of fault-family skills and highyield diagnostic helpers. On a held-out 523-incident slice of the public NIKA benchmark covering eleven unseen scenarios, SADE improves root-cause F1 by 37 percentage points over a ReAct + GPT-5 baseline; a model-controlled comparison against the same Claude Sonnet backend without the SADE policy attributes 22 of those points to the diagnostic policy alone, showing that the gain is not a side-effect of the model upgrade. Index Terms—Network Management, Network Troubleshooting, Large Language Models, LLM Agents, Network Diagnostics

I. I NTRODUCTION Modern computer networks fail in ways that are both costly and slow to diagnose. For instance, a single BGP misconfiguration in 2021 caused a 6-hour outage across Meta platforms, affecting billions of users [15]. Similar incidents have occurred at telcos and cloud providers, affecting not only consumers and applications but also critical emergency services [1, 32]. In each case, operator or automation errors triggered the outages, but recovery was slow: network engineers had to diagnose cascading, multi-layered symptoms under pressure, often while their own monitoring and remote-access tools were also impaired. The cost of a network fault is dominated by how long it takes operators to identify the root cause. Network operational complexity has driven automation efforts, such as Intent-based networking and zero-touch service management, aiming to reduce operator burden by translating high-level goals into low-level configurations and policy-driven workflows [9, 18]. With their advent, LLMs (Large Language Models) have also been applied to networking tasks, including intent translation, configuration generation, and network management assistance [2, 5, 16, 17, 24, 31]. While important, these efforts primarily address specifying, generating, or managing

SADE framework Specialized skills for netowork troubleshooting

NIKA execution interface

Kathará Simulator

Fig. 1: SADE system overview. An LLM agent with specialized troubleshooting skills interacts with Kathara-emulated topologies via the NIKA interface, achieving a root-cause F1 score of 0.77 compared to 0.40 achieved by ReAct. configurations during normal operation. They do not fully address diagnosing an already-failing network with incomplete, cascading symptoms. An effective diagnostic system must decide what evidence to collect next, inspect the live network, update its hypothesis as observations arrive, and localize the root cause under time and query constraints. This gap motivates a shift to agentic network fault diagnosis, where the challenge is not producing configurations from intent, but actively gathering evidence and reasoning toward a root cause. Recent work has explored the use of LLMs for network troubleshooting. NetAssistant [27] uses natural-language queries to select pre-authored workflows in data-center networks, while BiAn [25] applies a hierarchical LLM pipeline with earlystop criteria for failure localization. The NIKA benchmark [30] uses Kathara-emulated [6] topologies and the Model Context Protocol (MCP) [19] to evaluate agentic diagnosis on common network faults. While these works shift toward troubleshooting, they remain limited by predefined workflows, fixed pipelines, or basic task evaluations that do not capture how expert operators systematically narrow faults across layers. This motivates a diagnostic agent that exploits iterative evidence collection, hypothesis revision, and disciplined escalation from symptoms to root causes. To this end, we propose SADE (Symptom-Aware Diagnostic

Escalation), a methodology-grounded LLM agent for network fault diagnosis (Figure 1). SADE is based on the premise that effective troubleshooting requires more than giving an LLM access to network tools: the agent must follow a disciplined diagnostic procedure that determines what to inspect first, how to interpret symptoms, and when to escalate across layers. More specifically, we make the following contributions. We propose SADE, an LLM-based agentic framework for network fault diagnosis that follows a multi-stage troubleshooting approach comprising: (i) initial scan, (ii) deep network scan, (iii) symptom-to-fault-family matching, and (iv) network skills library-based root cause analysis. • We evaluate SADE on the public NIKA benchmark against two baselines: ReAct + GPT-5 and Claude Code. SADE achieves a root cause analysis (RCA) F1 score of 0.77, outperforming the NIKA-native ReAct + GPT-5 baseline (0.40) and Claude Code (0.55), while requiring fewer diagnostic steps. These results demonstrate improved symptom confirmation, more accurate fault-family skill selection, and reduced unnecessary tool use. • We further demonstrate that SADE can troubleshoot network faults across topologies of varying sizes, including those exceeding 100 nodes, owing to its cross-stack diagnostic capabilities. Consequently, SADE achieves a task completion rate approximately 5% higher than that of the best-performing baseline. • We release an anonymous GitHub repository containing the SADE source code, diagnostic skill library, and experiment utility scripts to support reproducibility and facilitate future research.1

•

The rest of the paper is organized as follows. Section II reviews related work. Section III presents the SADE design. Section IV describes our experimental setup. Section V reports results and ablations. Section VI discusses limitations and concludes. II. R ELATED W ORK Before the emergence of LLMs, network automation efforts focused on configuration and policy management. Intent-based networking [18] and zero-touch service management [9] translate high-level objectives into configurations and workflows. Static analysis tools like Batfish [10] verify configuration properties before deployment. Learning-based systems leverage historical data and graph neural networks for configuration recommendation [11, 12] or mobile-network tasks [21]. While these approaches help specify goals and validate configurations, they do not address open-ended fault diagnosis in live, degraded networks, where troubleshooting requires collecting evidence, invoking tools, and revising hypotheses as observations accumulate. LLMs enable new diagnostic approaches by reasoning over natural language, configurations, tool outputs, and heterogeneous operational evidence. 1 https://github.com/Overlxrd-uwu/SADE-NetworkAgent

A. LLM-Based Network Configuration Management LLNet [2] demonstrates that even a small language model, paired with an intermediate JSON representation, can compile natural-language intents into deployable programs across heterogeneous SDN data and control planes. Mekrache and Ksentini [17] adopt the same paradigm for a 5G testbed, with explicit extensions toward 6G, embedding the LLM into an end-to-end intent lifecycle spanning decomposition, translation, and activation. Lira et al. [16] situate the approach within zero-touch service management, while GeNet [14] broadens the input modality by using a multimodal LLM to interpret topology diagrams alongside textual intent. At production scale, Confucius [29] reports the experience of deploying a multi-agent management framework at Meta, modelling workflows as directed acyclic graphs over specialised agents and gating mission-critical actions through validation and human approval. NetLLM [31] adapts general-purpose models to networking prediction through lightweight fine-tuning, while NetConfEval [24] benchmarks configuration-translation performance across model families and intent complexities. Recent surveys consolidate this emerging direction and identify open challenges [5, 13]. What unifies this work is that the desired outcome is known upfront and the LLM translates intent into correct configurations. In contrast, SADE targets the inverse problem: troubleshooting with an unknown cause, where the agent must probe the network interactively under incomplete evidence. B. LLMs for Network Troubleshooting NetAssistant [27] routes natural-language diagnosis queries to pre-authored workflows in data-center networks and has been deployed in production. BiAn [25] applies a hierarchical LLM pipeline to production-scale failure localization with early-stop criteria. Donadel et al. [8] evaluate zero-shot LLMs on Katharaemulated topologies. Most directly related, the NIKA benchmark [30] provides a public platform for evaluating agentic LLMs on classical network troubleshooting tasks. The majority of existing LLM-based root-cause-analysis literature [7, 23, 28] focuses on cloud and microservice environments rather than L2/L3 networks. While these systems demonstrate the promise of LLM-assisted diagnosis, they do not explicitly address how to structure an agent’s diagnostic process to move from surface-level symptoms to deeper fault reasoning when initial observations are insufficient. C. Tool-Using Agents and Reusable Skill Libraries Two recent general-purpose agentic paradigms inform the design of SADE. The ReAct paradigm [33] interleaves reasoning, tool invocation, and observation in a single decision loop and now underpins most modern tool-using agents, including those deployed in networking. Voyager [26] introduced the idea of incrementally constructing a reusable skill library from past experience, allowing an agent to accumulate procedural competence across episodes rather than re-deriving it from scratch. More recently, Anthropic’s Agent Skills convention [3] operationalises this idea for production deployment: reusable

System prompt: You are a network diagnosis agent. Identify the root cause of observed network anomalies and call submit() with the result. You should complete the following steps: <SADE framework steps>. You can use tools and skills as follows. <MCP tools, Skills guidelines>. You need to adhere to the following rules when making decisions: <Symptom identification, Decision and reasoning,... >

Initial scan: get_reachability ⇒ all hosts reachable, no device flagged ⇒ no symptoms identified

Initial scan

1

get_reachability() Symptom identification Symptom 3

No

Symptom found? Yes

Symptom Fault family Symptom Mapping

4

Deep Network Scan: Step A: infra_sweep, l2_scan ⇒ clean: no nftables drops, no MAC dup, no flap ⇒ escalate to manual Phase B

Deep Network Scan

2 (A)

(B)

Infrastructure sweep & L2 layer scan

OSPF scan & Traffic control scan

(C)

(D)

Host path analysis & DHCP scan

Service path check & Resource pressure

Symptom: OSPF neighbor missing on spine_router_2

Skills Bank - Fault Specific Skills

Fault detection Device localization Skill driven process Outcome

ospf

bgp

acl

tc

host-ip

link host-crash dns

Agent manual

Deep Network Scan: Step B: ospf_scan ⇒ Neighbor table empty on spine_router_2 ⇒ Fault-Index match → ospf-fault-skill

load-bal dhcp mac-conf

Fault index: OSPF/FRR adjacency symptom → ospf-fault-skill

res-cont

Claude Code backend

Fig. 2: SADE framework. Actions that interact with the Kathará simulation are marked in red text.

procedural knowledge is authored as SKILL.md files and dispatched through a central index, so that only the skills relevant to the current task are loaded into the agent’s working context. SADE builds on these foundations but targets structured network troubleshooting: it separates general diagnostic methodology from fault-specific expertise, enforces their interaction through multi-stage escalation, and demonstrates on NIKA that this yields more reliable root-cause localisation than generic tool-using approaches. III. SADE F RAMEWORK The SADE (Symptom-Aware Diagnostic Escalation) framework follows the Cisco network troubleshooting methodology [22] by encoding it into an agent-driven process through agent policy. As illustrated in Figure 2, the framework comprises four primary stages: (i) an initial scan that performs a basic reachability test to identify observable symptoms; (ii) a deep network scan that inspects the system from the datalink layer up to the application layer in four ordered phases (L2/infrastructure → control plane → host-local → service), when the initial scan fails to reveal issues; (iii) a symptom-tofault-family mapping stage that associates detected symptoms with high-level fault categories; and (iv) a Claude skill-driven fault detection and localization process. The Deep Network Scan uses multiple Python helper scripts to perform specific scans to diagnose issues in different layers of the network, including infrastructure-level checks (e.g., routing, ARP, and ACL inspection) and Layer 2 anomaly detection, such as identifying duplicate MAC addresses. The identified symptoms are first mapped to the appropriate fault family using the Fault-Index, after which the Skill Bank, consisting of 15 Claude Skills, carries out the subsequent in-depth inspection to pinpoint the exact fault and accurately localize the responsible device through systematic, evidence-based reasoning. To perform the exact fault detection and localization, we use a

Fault Detection using Skills: • The skill defines four fingerprints (frr_service_down, ospf_neighbor_missing, ospf_area_misconfiguration, ospf_acl_block). • The agent runs the skill’s probes (show ip ospf neighbor, show running-config, FRR process check, nft list ruleset) on each candidate router and matches the evidence against the fingerprints. • The matching fingerprint identifies the fault label and the faulty device on which it surfaces. Decision: matching evidence on spine_router_2 → submit canonical OSPF fault and faulty device

Fig. 3: Example workflow for troubleshooting an OSPF error. Skills Bank that contains 15 Claude Skills, which guide the agent through systematic fault detection and localization. When executing actions on the simulator, SADE invokes the MCP tools exposed by the NIKA execution interface, which mediates all communication with the underlying Kathará simulator. The experiment setup is further discussed in Section IV. Below, we discuss each SADE step in detail. A. Deep Network Scan B. Initial Scan The initial scan stage calls get_reachability(), a prebuilt MCP function from NIKA to scan the network Kathará simulator. It returns the complete ping results from each host to all other hosts in the network, returning a matrix of allpairs. Each reachability entry records the source, destination, transmitted and received packets, loss percentage, status, and destination IP information. SADE uses this output to determine whether a genuine symptom is immediately observable. This classification is performed based on criteria defined in SADE’s system prompt: entries with non-zero packet loss, timeouts, refused connections, or ICMP unreachable responses are treated as candidate symptoms and forwarded to Step 3, while all other cases proceed to Deep Network Scan (Step 2). We note that get_reachability() can produce ambiguous outputs when name resolution fails at the source, resulting in rows with status = “unknown” and null transmission. This typically occurs due to missing or incorrect DNS entries, even if the underlying L3 path is functional. To resolve this ambiguity,

SADE performs a direct-IP probe by re-running ping from the same source using the destination IP provided in the original get_reachability output. By bypassing DNS, this step distinguishes between a resolver issue and an actual network path failure before assigning the symptom to a fault family. At the end of the scan, the identified symptoms are forwarded to the next stage when present; if no symptoms are detected, a “symptoms not found” message is passed instead. In cases where the Initial Scan (Step 1) fails to identify any fault symptoms, we conduct a systematic network scan, following the instructions in the agent manual as shown in Appendix A. This step is necessary because we observed that many faults do not appear as simple host-to-host reachability failures. For example, routing control-plane issues can be masked by redundant paths, services can remain operational while their ports are filtered, and apparent host disconnections can be caused by underlying ARP or DNS-related behavior. As illustrated in Figure 3, the scan starts with L2 and infrastructure evidence, then moves to control-plane and routing evidence, host-local evidence, and finally service and resource-pressure evidence. Table I summarizes the main helper scripts used in this process. An example is discussed in the Appendix A. This bottom-up ordering follows from the observability behaviour described above and is guided by Cisco’s structured troubleshooting methodology [22]. Because lower-layer faults often surface as higher-layer symptoms, the scan first confirms L2 and routing evidence, so a healthy-looking service or host reading is not accepted while an underlying ACL, routing, or ARP fault remains uninspected. The identified symptoms will be passed to Step 3 to map to a fault family.

D. Fault Detection and Localization After the fault family is selected, SADE fetches the corresponding fault-specific Claude skill using the Skill tool. Each skill is a declarative SKILL.md document — written in Markdown and supplied to the agent as in-context instructions at fetch time — that names the canonical failure modes in that family, the leading signals that distinguish them, the exact probes used to confirm each one, helper scripts, guardrails, and stop conditions. The mapping from probe output to fingerprint is performed by the agent at run time by reasoning over the returned evidence against the skill’s textual descriptions, rather than by a fixed dispatch table, so the same skill applies to any topology and any device on which the family’s symptom surfaces. We discuss the content of a skill file further in the Appendix D. The agent then executes the probes specified by the selected skill and compares the collected evidence against the skill’s fault fingerprints. Here, a probe is a targeted shell command or MCP call, such as a firewall-rule listing via nft, an OSPF-neighbour query through vtysh, or a daemon-presence check via pgrep, designed to gather structured evidence from a suspected device, allowing direct matching against the skill’s description. Once a fingerprint matches, the faulty device is identified as the one on which the decisive probe yields a positive fingerprint. The system then submits the corresponding canonical fault label, defined by the fingerprint itself, as the final result. For instance, in Figure 3, the discovered symptom is missing OSPF neighbour, and it is mapped to the OSPF fault skill, whose four fingerprints and matching probes confirm the affected spine router as the faulty device. We present the algorithmic summarization of the SADE agent in Algorithm 1 in the Appendix. IV. E XPERIMENT S ETTINGS

C. Symptom to Fault Family Mapping SADE uses a fault index that maps the found symptoms to high-level fault categories (fault families) using a well-defined rule set and then decides the fault-relevant skill to be used for further exploration from the Skills Bank. The agent uses the rule set and the examples given to map the symptoms to the fault family and the skill through logical reasoning. The index also includes disambiguation logic for cases where a single symptom may originate from multiple layers. For example (Figure 3), an OSPF neighbor missing on a router could indicate either a link fault or a routing-layer fault (where the link is up but the control plane is broken). SADE’s index disambiguates by first checking the interface state via infra_sweep: if the interface is DOWN, the symptom routes to link-fault-skill, which works through its checklist and escalates if the pattern is not resolved there; if the interface is UP and the OSPF neighbor table is vacant, the decision is routed to ospf-fault-skill, which narrows down the possible root cause among its fingerprints. The idea is that the symptom index does not statically map a symptom to a family — it routes the agent only after evidence on the suspected layer supports the choice.

We evaluate SADE on the public NIKA benchmark [30]. The evaluation compares SADE against two baselines: the published ReAct baseline from NIKA and Anthropic’s recent Claude Code agent, which has demonstrated excellent command-line and automation skills. A. Experimental Setup a) NIKA dataset and evaluation split: NIKA is built on Kathará [6], a Docker container-based network emulator, and exposes each topology to an LLM agent through the Model Context Protocol (MCP) [19]. The dataset contains 640 incidents covering 54 network issues across 12 scenario configurations, grouped into five network scenarios: data-centre CLOS, three-tier campus, ISP backbone, SDN, and P4. Each scalable scenario configuration is instantiated at up to three topology sizes: small, medium, and large. Since NIKA does not provide a predefined training/test split, we reserve one scenario configuration, ospf_dhcp, for SADE development (training set). We choose this configuration because it appears at all three topology sizes and covers 36 of the 54 network issues, yielding 108 development incidents across the three topology sizes. The remaining four network scenarios contain 532 held-out incidents across topology sizes

TABLE I: Helper scripts used in SADE’s deep network scan. Scan phase

Helper script

Functionality / output

L2 / infrastructure

infra_sweep.py

L2 / infrastructure

l2_snapshot.py

Control plane / routing

ospf_snapshot.py, bgp_snapshot.py

Traffic behavior

tc_snapshot.py

Host-local

host_path_snapshot.py, dhcp_link_history.py, safe_reachability.py

Service / resource

service_snapshot.py, pressure_sweep.py

Runs nft list ruleset, ip -br addr, ip route, arp -n, and /etc/resolv.conf on every device. Returns flagged devices and the failure: firewall drop, missing IP / route / gateway, ARP-cache mismatch, or broken resolver. Reads interface state, MAC, and bridge membership on every device. Returns any interface pair sharing a link/ether address (duplicate-MAC fault, invisible to reachability checks). Queries the FRR (FRRouting) daemon on every router for OSPF / BGP state. Returns per router: daemon status, advertised networks, neighbor adjacency, route counts, and a convergence verdict. Runs tc qdisc show on every active interface. Returns only interfaces with a non-default qdisc (shaping or rate-limiting), each with a tc -s stats summary. On a chosen host, checks the kernel path to the target (ip route get + next-hop ARP), parses recent DHCP / link events from logs, and runs a fallback reachability sweep when MCP get_reachability() fails. Returns the outbound path, link-flap history, and a partial reachability matrix. Checks DNS, hostname resolution, per-URL HTTP timing on the host; samples CPU and socket spikes, daemon presence, and stress processes on every device. Returns service-side health and per-device contention signals separating load-induced from configuration faults.

TABLE II: Test-set composition (N = 523 matched triples). By scenario × topology size Size

dc_clos dc_clos ospf_ent. rip_small sdn sdn P4 Total _bgp _service _static _int_vpn _clos _star

s m l single

22 22 22 –

33 33 33 –

26 26 26 –

23 23 24 –

18 19 19 –

19 – 19 – 18 – – 98

141 142 142 98

Total

66

99

78

70

56

56 98

523

By NIKA root-cause category End-host Misconfig. Link fail. Resource cont. Node error Under attack Total 124

123

99

82

60

35

523

and network issues. During execution, however, nine of these incidents were skipped at deployment time by the NIKA injector. We therefore report results on the 523 held-out incidents for which all three systems produced complete runs, ensuring that SADE, CC-Baseline, and ReAct+GPT-5 are compared on the same workload. Table II summarizes these 523 matched test cases, broken down by scenario configuration, topology size, and NIKA root-cause category. b) SADE implementation and Baselines: SADE is implemented as an agentic diagnostic system on top of the Claude Agent SDK, using Claude Sonnet 4.6 [4] as the underlying LLM. The implementation consists of a four-step method, described in Section III. For each test incident, SADE interacts with the topology only through the MCP tools provided by NIKA. The agent is given a fixed budget of 20 API turns, after which it must submit its diagnosis in the NIKA submission format. A turn is one LLM API call; the agent may issue multiple (parallel) tool calls within a single turn before yielding back to the runner. We adopt the 20-step cap from NIKA’s released ReAct agent (its LangGraph recursion_limit), applied as a 20-turn cap on SADE and CC-Baseline so all three systems share the same per-incident reasoning budget. For comparison, we use two baselines. The first is NIKA’s published ReAct baseline, which uses a two-agent LangGraph workflow: one agent investigates the incident and another pro-

duces the final submission. We use the strongest configuration reported in NIKA, based on GPT-5 [20]. The second baseline is a Claude Code agent using Claude Sonnet 4.6, the same model backend as SADE. This baseline does not use SADE’s extra features such as the skill library or helper scripts, and therefore measures how much of SADE’s performance comes from the proposed diagnostic design rather than from the underlying Claude model alone. In our comparison, all systems are run on the same 523 test incidents, use the same 20-turn limit, and submit their answers in the NIKA submission format. B. Evaluation Metrics We use the same evaluation measures as NIKA. Detection performance is measured by accuracy on the binary is_anomaly field, which indicates whether the agent correctly identifies the presence of an anomaly. Root-cause performance is measured using F1 over the set of predicted root-cause labels, since an incident may involve more than one relevant label. In addition to these automatic metrics, we use NIKA’s LLM-as-judge protocol with gpt-5-mini [20]. The judge assigns scores from 1 to 5 across five rubric axes, relevance (localization), correctness (diagnostic actions), efficiency (tool usage), clarity (reasoning trace), and final outcome (match against ground truth), and also returns an aggregate overall score based on the judge’s own reasoning over these axes. If an agent does not produce a valid submission within the turn limit, we treat the incident as an unsuccessful diagnosis and assign F1 = 0 for root-cause evaluation. To measure efficiency, we also record input and tokens, and the number of tool calls made during each run. V. R ESULTS This section evaluates SADE against two baselines on the NIKA fault-diagnosis benchmark: ReAct with GPT-5 and a Claude-Code baseline using the same Claude Sonnet 4.6 backbone as SADE. We first report overall diagnostic correctness on 523 test cases, then examine why the gains arise by analyzing cross-stack diagnostic behavior, submission reliability, tool-call efficiency, and robustness across topology sizes.

Fig. 4: Overall score, RCA F1, and detection accuracy on the matched test cases Figure 4 reports the main results on the 523 matched NIKA test cases, where each case contains the same fault type, network scenario, and topology size across all three systems. SADE achieves the highest score on every reported correctness metric. Its mean overall judge score is 4.32, compared with 3.93 for the Claude-Code baseline and 3.80 for ReAct. SADE also improves diagnostic-specific metrics, reaching an RCA F1 of 0.77 compared to 0.55 for the same-backbone Claude-Code baseline and 0.44 for ReAct, and a detection accuracy of 0.85 compared to 0.67 and 0.68, respectively. Since SADE and the Claude-Code baseline use the same Claude Sonnet backbone, this gap shows that the improvement is not due to the model alone, but to SADE’s structured diagnostic workflow. These results support the central claim of the framework: guiding the agent through symptom-driven evidence collection improves both anomaly detection and root-cause identification, particularly in cases where the observed symptoms span multiple layers of the network stack. Next, we examine which diagnostic cases benefit most from this structured workflow. A. Cross-stack Diagnostics To make the multi-layer nature of these cases concrete, we first focus on cross-stack diagnostics: faults where the visible symptom appears in one part of the network, but the root cause is exposed only by checking another part of the stack. In such cases, no single observation is sufficient. Reachability, routing state, filtering rules, host state, and service behavior may each provide partial evidence, but the diagnosis becomes clear only when these observations are connected. Table III summarizes representative examples from the matched NIKA test cases. These examples are a subset of the evaluated cases. For each case, the table reports the fault family, scenario/topology, ambiguity introduced by the fault, and diagnostic checks that expose the root cause. The corresponding ground truth, agent submissions, judge scores, and trace evidence are provided in Appendix C. The cases in Table III illustrate how this ambiguity arises in practice. In bgp_acl_block, which appears in the dc_clos_service/l topology, the fault is misleading because the network is not simply unreachable. Basic reachability checks may still succeed, making the system appear healthy if diagnosis stops at whether hosts or routers respond. The affected traffic, however, is more specific. BGP messages are

Fig. 5: Sensitivity to topology size. (a) Mean overall judge score and (b) mean input-token budget by topology size, for the three sized scenario classes (averaging 11, 27, and 101 nodes from s to l). Single-size (P4/SDN) labs are excluded. carried over TCP/179, and in this case they are silently dropped by an ACL on a spine router. The root cause is therefore not exposed by broad connectivity tests alone. It becomes visible only by connecting evidence across layers: baseline reachability shows that the network is not entirely down, the failed BGP session shows that routing-state exchange is affected, and router-level filtering rules identify the ACL entry blocking BGP traffic. A similar structure appears in dns_port_blocked, however, at the service boundary rather than in the routing control plane. The DNS pod can appear reachable, and the DNS daemon may be running, so the failure is not explained by a crashed service or unavailable pod. DNS resolution nevertheless fails because the required traffic, TCP/UDP port 53, is filtered at the pod boundary. The service exists and the pod is reachable in a general sense, yet the specific requests needed to use the service cannot enter. Both cases show why cross-stack diagnosis is difficult: a healthy observation at one layer does not rule out a fault in the protocol, port, or filtering mechanism required by the failing operation. The cross-stack analysis shows where SADE differs from ReAct and Claude-Code baselines. SADE succeeds because it does not treat initial reachability or service-level checks as sufficient. Instead, it continues the investigation until the symptom is connected to the relevant routing or filtering mechanism, allowing it to submit the correct root-cause family. By contrast, ReAct and Claude-Code fail because their diagnoses stop too close to the symptom: they either accept a broad but incomplete explanation, miss the protocol-specific anomaly, or fail to produce a valid final submission. The difference is therefore not simply that SADE observes more signals, but that it connects the symptom layer to the layer where the fault is introduced. Both rows in Table III share the same pattern: the decisive evidence is not available from the first symptom alone, and correct RCA requires tracing the failure from the visible behavior to the specific routing or filtering mechanism that explains it. This explains why SADE’s gains in detection accuracy and RCA F1 are aligned with its higher judge scores on cross-stack tasks. Agents that stop at the symptom layer can miss the fault or assign it to the wrong subsystem, whereas SADE continues the diagnostic process until the trace exposes the actual root cause.

TABLE III: Two cross-stack diagnostic cases from the matched test set: topology and fault label, the diagnostic ambiguity, the canonical (ground-truth) detection sequence, and the SADE traces from the session log. Both SADE runs submit the correct root cause with judge final-outcome and overall both 5/5; comparison between baseline submissions are in Appendix C. Topology / Fault

Diagnostic ambiguity

Ground-truth steps

SADE log audit

dc_clos_service/l bgp_acl_block

Reachability looks healthy because the Clos has redundant spines, but BGP control-plane traffic is silently dropped by an ACL on one spine.

Step 1. Verify reachability. Step 2. Check BGP session. Step 3. List nft ruleset on spine. Step 4. Identify drop on TCP/179.

dc_clos_service/l dns_port_blocked

The DNS pod and named daemon look healthy, but TCP/UDP port 53 is silently filtered at the pod boundary.

Step 1. Confirm DNS daemon up. Step 2. Probe TCP/UDP 53 to pod. Step 3. Inspect pod nft ruleset. Step 4. Identify filter on port 53.

P1. 70/70 paths at 0% loss; no symptom. P4. infra_sweep flags spine_router_2_3 alone (BGP-ACL fingerprint). Confirm. acl-skill → nft list ruleset: tcp dport/sport 179 drop in input/forward/output chains. Submit. bgp_acl_block / spine_router_2_3; 16 turns. P1. All paths at 0% loss; no symptom. P4. infra_sweep flags dns_pod2 (tcp/udp dport 53 drop). Confirm. dns-fault-skill → ps+ss+nft on dns_pod2: named (PID 29) listening on 10.2.0.2:53; nft drops port 53. Submit. dns_port_blocked / dns_pod2.

B. Sensitivity to topology size Figure 5 examines whether SADE’s diagnostic advantage persists as topology size grows. NIKA contains small (s), medium (m), and large (l) instances of the same scenario classes, with average topology sizes of approximately 11, 27, and 101 nodes, respectively. We exclude the single-size P4/SDN cases so that the comparison reflects only scenarios that appear across multiple topology sizes. SADE achieves the highest mean overall judge score at every topology size, indicating that its advantage is preserved as the network grows. Larger topologies contain more devices, links, routing states, and filtering rules, expanding both the set of plausible fault locations and the volume of irrelevant evidence available to the agent. The Claude-Code baseline, which uses the same Claude Sonnet backbone as SADE, declines on larger topologies, whereas SADE retains a high score across the small, medium, and large settings. This gap reflects SADE’s investigation procedure rather than model capability: SADE uses observed symptoms to narrow the search to a small set of fault families and protocol layers, instead of checking the topology uniformly. This focus allows SADE to identify the correct root cause as topology size, and the number of candidate explanations grows. A natural concern is whether this accuracy advantage on large topologies comes at the cost of an inflated diagnostic context. Figure 5b shows otherwise. SADE consumes more tokens (input + output) than either baseline in absolute terms, reflecting more systematic evidence collection, but its token usage grows at a similar rate as topology size increases: SADE scales from 316k to 504k total tokens between small and large topologies (1.6×), compared to 1.7× for Claude-Code (189k to 318k) and 1.9× for ReAct (62k to 116k). The additional tokens are therefore spent on targeted evidence collection rather than uncontrolled context growth. Together with the accuracy results in Figure 5a, this indicates that SADE’s structured workflow sustains diagnostic accuracy on larger topologies without scal-

ing context usage faster than the baselines, supporting the same conclusion as the cross-stack analysis: SADE’s gains are not confined to small or easily localized faults. C. Tool-call Efficiency and Submission reliability The previous subsections show that SADE improves diagnostic correctness on cross-stack faults and preserves this advantage as topology size increases. We next examine whether these gains are achieved reliably within the diagnostic budget (i.e., 20 turns). Table IV reports two complementary measures on the test set: the rate at which each agent reaches the 20-turn budget without producing a parseable final submission, and the number of tool calls issued per correctly submitted test case. No-submission cases are distinct from incorrect diagnoses: the agent may have collected useful evidence, but failed to convert it into a valid root-cause decision. In the evaluation, these runs receive no localization or root-cause credit, so submission reliability directly affects the aggregate diagnostic scores. SADE has the lowest no-submission rate, failing to submit in 4.2% of matched sessions, compared with 8.8% for ReAct and 15.3% for the Claude-Code baseline. The difference is largest against the Claude-Code baseline, where SADE reduces nosubmission failures from 80 cases to 22 cases. This indicates that the structured diagnostic workflow does not only improve the final answer when a submission is made; it also makes the agent more likely to terminate with a valid diagnosis TABLE IV: Submission reliability and tool-call efficiency on the test set (N = 523). Metric Submission reliability No-submissions (of 523) ↓ No-submission rate (%) ↓ Tool-call efficiency Mean tool calls per session ↓ Total tool calls ↓ Correct submissions ↑ Tool calls per correct submission ↓

ReAct

CC-Base

SADE

46 8.8

80 15.3

22 4.2

25.4 13,266 268 49.5

26.7 13,962 271 51.5

19.9 10,393 382 27.2

under the benchmark budget. The audited traces further show that the baselines fail in different ways: Claude-Code often continues investigating until the budget is exhausted without calling submit(), whereas ReAct more often terminates with an incorrect fault family or faulty-device set. SADE reduces the first failure mode through its Phase 3 stop-and-submit rule, which turns a matched fault-family fingerprint into an explicit termination point rather than allowing the investigation to continue indefinitely. The tool-call rows of Table IV show that SADE’s higher submission reliability is accompanied by lower diagnostic action cost. SADE averages 19.9 tool calls per session, compared with 25.4 for ReAct and 26.7 for Claude-Code, while producing substantially more correct submissions. Normalizing by successful outcomes makes the difference clearer: SADE requires 27.2 tool calls per correct submission, whereas ReAct and ClaudeCode require 49.5 and 51.5, respectively. Thus, SADE does not obtain its accuracy by spending more commands within the fixed turn budget; it obtains more correct diagnoses from fewer active probes. This result is consistent with the crossstack analysis in Section V-A. In those cases, the decisive step is not broad exploration, but the selection of the check that exposes the layer at which the fault mechanism occurs, such as a routing-state query, a filtering-rule inspection, a serviceport probe, or a host-local configuration check. SADE’s phase gates and skill-index library bias the investigation toward these decisive tests once the symptom pattern has narrowed the plausible fault families. The combined results therefore provide a cost-side explanation for the earlier accuracy gains: SADE spends fewer commands on irrelevant evidence, reaches the evidence needed for a valid submission more often, and does so without expanding the diagnostic search as topology size grows.

TABLE V: NIKA injector audit: SADE plus verified injection. Injection regime

n

1 2 3 4

5

Stock (train_obs) 39 17 3 0 0 19 Verified (manual_injection) 39 0 0 0 0 39

TABLE VI: Per-session token budget on the test slice (N = 523). Input and output tokens are reported separately because they are billed at different rates. Values in thousands of tokens. Statistic

ReAct (GPT-5)

CC-Base

SADE

Input tokens (k) Min (lower whisker) Q1 (25th percentile) Median Q3 (75th percentile) Max (upper whisker)

8 31 55 89 173

34 101 189 334 659

86 246 344 483 838

Output tokens (k) Min (lower whisker) Q1 (25th percentile) Median Q3 (75th percentile) Max (upper whisker)

2 8 10 13 22

1 4 6 13 26

3 5 8 18 36

VI. D ISCUSSION AND C ONCLUDING R EMARKS

network may not contain the corresponding failure condition. This makes absolute scores difficult to interpret, because a low score may reflect either an incorrect diagnosis or an unsuccessful injection. To address this, we implemented a perfault rescue-and-verify pipeline, run_nika_break, which checks that the intended fault is present before scoring. Table V reports these numbers on the training set, where we manually verified each test case. Under the stock injector, SADE receives 17 score-1 outcomes and 19 score-5 outcomes out of the 39 runs. After verified injection, the same set receives a score of 5 in all 39 cases, indicating that part of the low-score mass under stock injection is caused by failed fault installation rather than SADE’s diagnostic procedure. Given the impracticality of manually verifying all 523 fault injection cases on the test set, some failures may remain undetected. However, correcting such cases would only improve the reported performance metrics.

We presented SADE, an LLM-based framework for network fault diagnosis that separates general diagnostic procedure from fault-family-specific expertise. SADE enforces this separation through a multi-stage workflow and a skill library that guides the agent from symptom observation to targeted evidence collection and final root-cause submission. On the NIKA benchmark, SADE achieves higher diagnostic performance than both ReAct and the Claude-Code baselines. SADE improves rootcause F1 by 36.9 percentage points over the NIKA-native ReAct + GPT-5 baseline, and by 21.5 percentage points over the same-backbone Claude-Code baseline. SADE also reduces no-submission failures by 3.6× relative to the same-backbone baseline. Our results show that SADE’s gains are not only a consequence of the underlying language model but also of the diagnostic workflow imposed on it. Next, we discuss additional relevant findings about the NIKA benchmark, limitations of SADE, and possible future extensions. a) Fault-injection validity: During development, we observed that NIKA’s stock injector does not always inject the intended fault for some fault families. In such cases, the benchmark label records the fault as present, but the emulated

b) Skill Library and LLM Backbone: The current SADE skill index is manually authored, making it inspectable and easy to update. However, it is dependent on expert effort. Future work could explore automatic skill construction and updates from incident corpora, operator playbooks, and diagnostic history knowledge bases. In our experiments, we use Claude Sonnet 4.6 for cost reasons. Recent Claude Opus models have demonstrated increased performance in other domains, and using such a backbone would likely further improve results. c) Per-session token budget and dollar cost: As discussed in Section V-B SADE consumes more tokens than the baselines. Table VI reports input and output distributions separately, which are billed at different rates by Anthropic. The median token consumption for SADE is 344k input and 8k output, compared to 189k/6k for the Claude-Code baseline and 55k/10k for ReAct + GPT-5. Output is priced at 5× the input rate, so it still contributes significantly to the cost. At publicly listed rates (GPT-5: $1.25/$10 per 1M input/output tokens; Claude Sonnet 4.6: $3/$15), an average mid-size topology session costs $0.20 for ReAct, $0.83 for the Claude-Code baseline, and $1.44 for SADE.

d) Towards live networks: NIKA runs on Kathar’a, a container-based network emulator that provides a controlled setting for evaluating routing, filtering, host-state, and servicelevel faults. However, it does not capture several factors that shape production troubleshooting, including hardware forwarding behavior, NIC offloads, ASIC-level queueing, telemetry delay, and monitoring-pipeline failures. Since operational networks typically expose state through controlled telemetry and configuration systems, a deployment-ready SADE would require operator-specific wrappers over routing collectors, configuration databases, monitoring platforms, and serviceobservability tools.

R EFERENCES [1] Amazon Web Services, “Summary of the Amazon DynamoDB service disruption in the Northern Virginia (USEAST-1) region,” AWS post-event summary, https://aws. amazon.com/message/101925/, 2025. [2] A. Angi, A. Sacco, and G. Marchetto, “Llnet: An intentdriven approach to instructing softwarized network devices using a small language model,” IEEE Transactions on Network and Service Management, vol. 22, no. 4, pp. 3403–3418, 2025. [3] Anthropic, “Agent skills,” https://docs.claude.com/en/ docs/agents-and-tools/agent-skills, 2025. [4] Anthropic, PBC, “Claude Sonnet 4.6,” https://www. anthropic.com/news/claude-sonnet-4-6, 2025. [5] G. O. Boateng, H. Sami, A. Alagha, H. Elmekki, A. Hammoud, R. Mizouni, A. Mourad, H. Otrok, J. Bentahar, S. Muhaidat, C. Talhi, Z. Dziong, and M. Guizani, “A survey on large language models for communication, network, and service management: Application insights, challenges, and future directions,” IEEE Communications Surveys & Tutorials, vol. 28, pp. 527–566, 2026. [6] G. Bonofiglio, V. Iovinella, G. Lospoto, and G. Di Battista, “Kathará: A container-based framework for implementing network function virtualization and software defined networks,” in NOMS 2018 - 2018 IEEE/IFIP Network Operations and Management Symposium, 2018, pp. 1–9. [7] Y. Chen, H. Xie, M. Ma, Y. Kang, X. Gao, L. Shi, Y. Cao, X. Gao, H. Fan, M. Wen et al., “Automatic root cause analysis via large language models for cloud incidents,” in Proceedings of the Nineteenth European Conference on Computer Systems, 2024, pp. 674–688. [8] D. Donadel, F. Marchiori, L. Pajola, and M. Conti, “Can llms understand computer networks? towards a virtual system administrator,” in 2024 IEEE 49th Conference on Local Computer Networks (LCN), 2024, pp. 1–10. [9] I. ETSI, “Zero touch network & service management (zsm) standards,” ETSI, Tech. Rep, Tech. Rep., 2018. [10] A. Fogel, S. Fung, L. Pedrosa, M. Walraed-Sullivan, R. Govindan, R. Mahajan, and T. Millstein, “A general approach to network configuration analysis,” in 12th

USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), 2015, pp. 469–483. [11] Z. Guo, F. Li, J. Shen, T. Xie, S. Jiang, and X. Wang, “Configreco: Network configuration recommendation with graph neural networks,” IEEE Network, vol. 38, no. 1, pp. 7–14, 2023. [12] Z. Guo, F. Li, T. Xie, X. Wang, and J. Cao, “Netgenius: Routing configuration recommendation based on graph neural network,” IEEE Transactions on Networking, 2025. [13] Y. Huang, H. Du, X. Zhang, D. Niyato, J. Kang, Z. Xiong, S. Wang, and T. Huang, “Large language models for networking: Applications, enabling techniques, and challenges,” IEEE Network, vol. 39, no. 1, pp. 235–242, 2024. [14] B. Ifland, R. Krief, A. Zilberman, E. Duani, M. Ohana, A. Murillo, O. Manor, O. Lavi, K. Hikichi, A. Shabtai et al., “Genet: A multimodal llm-based co-pilot for network topology and configuration,” in 2025 IEEE 45th International Conference on Distributed Computing Systems Workshops (ICDCSW). IEEE, 2025, pp. 117–122. [15] S. Janardhan, “Update about the October 4th outage,” Engineering at Meta blog, https://engineering.fb.com/2021/ 10/04/networking-traffic/outage/, 2021. [16] O. G. Lira, O. M. Caicedo, and N. L. S. da Fonseca, “Large language models for zero touch network configuration management,” IEEE Communications Magazine, vol. 63, no. 7, pp. 146–153, 2025. [17] A. Mekrache and A. Ksentini, “Llm-enabled intent-driven service configuration for next generation networks,” in 2024 IEEE 10th International Conference on Network Softwarization (NetSoft), 2024, pp. 253–257. [18] S. Minhas, R. Jaswal, A. Sharma, and S. Singla, “Revolutionizing networking: A comprehensive overview of intent-based networking,” in 2024 International Conference on Emerging Innovations and Advanced Computing (INNOCOMP), 2024, pp. 463–468. [19] Model Context Protocol Project, “Model context protocol specification,” https://modelcontextprotocol.io, 2024. [20] OpenAI, “Introducing GPT-5,” https://openai.com/index/ introducing-gpt-5/, 2025. [21] S. Piroti, A. Chawla, and T. Zanouda, “Mobile network configuration recommendation using deep generative graph neural network,” IEEE Networking Letters, vol. 6, no. 3, pp. 179–182, 2024. [22] A. Ranjbar, “Troubleshooting methods for Cisco IP networks,” https://www.ciscopress.com/articles/article. asp?p=2273070, Jan. 2015, sample chapter from Troubleshooting and Maintaining Cisco IP Networks (TSHOOT) Foundation Learning Guide (CCNP TSHOOT 300-135). [23] D. Roy, X. Zhang, R. Bhave, C. Bansal, P. Las-Casas, R. Fonseca, and S. Rajmohan, “Exploring llm-based agents for root cause analysis,” in Companion proceedings of the 32nd ACM international conference on the foundations of software engineering, 2024, pp. 208–219. [24] C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kostić, and M. Chiesa, “Netconfeval: Can llms facilitate network

configuration?” Proceedings of the ACM on Networking, vol. 2, no. CoNEXT2, pp. 1–25, 2024. [25] C. Wang, X. Zhang, R. Lu, X. Lin, X. Zeng, X. Zhang, Z. An, G. Wu, J. Gao, C. Tian et al., “Towards llmbased failure localization in production-scale networks,” in Proceedings of the ACM SIGCOMM 2025 Conference, 2025, pp. 496–511. [26] G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar, “Voyager: An openended embodied agent with large language models,” arXiv preprint arXiv:2305.16291, 2023. [27] H. Wang, A. Abhashkumar, C. Lin, T. Zhang, X. Gu, N. Ma, C. Wu, S. Liu, W. Zhou, Y. Dong et al., “{NetAssistant}: Dialogue based network diagnosis in data center networks,” in 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), 2024, pp. 2011–2024. [28] Z. Wang, Z. Liu, Y. Zhang, A. Zhong, J. Wang, F. Yin, L. Fan, L. Wu, and Q. Wen, “Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models,” in Proceedings of the 33rd ACM international conference on information and knowledge management, 2024, pp. 4966–4974. [29] Z. Wang, S. Lin, G. Yan, S. Ghorbani, M. Yu, J. Zhou, N. Hu, L. Baruah, S. Peters, S. Kamath, J. Yang, and Y. Zhang, “Intent-driven network management with multiagent LLMs: The Confucius framework,” in Proc. ACM SIGCOMM, 2025. [30] Z. Wang, A. Cornacchia, A. Sacco, F. Galante, M. Canini, and D. Jiang, “A network arena for benchmarking ai agents on network troubleshooting,” arXiv preprint arXiv:2512.16381, 2025. [31] D. Wu, X. Wang, Y. Qiao, Z. Wang, J. Jiang, S. Cui, and F. Wang, “Netllm: Adapting large language models for networking,” in Proceedings of the ACM SIGCOMM 2024 Conference, 2024, pp. 661–678. [32] Xona Partners Inc., “Assessment of Rogers networks for resiliency and reliability following the 8 July 2022 outage,” Canadian Radio-television and Telecommunications Commission, Independent assessment report BC92-130/1-2024E-PDF, Nov. 2024, https://crtc.gc. ca/eng/publications/reports/xonarp2023.htm. [33] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “React: Synergizing reasoning and acting in language models,” arXiv preprint arXiv:2210.03629, 2022.

A PPENDIX A S KILL AND H ELPER -S CRIPT E XAMPLES Two examples illustrate the SADE library (Figure 6): a faultfamily skill book (ospf-fault-skill) loaded on demand when the Fault Index routes a symptom, and a helper script (infra_sweep) the diagnosis manual runs as a Phase-A triage probe. Skill books are declarative decision tables; helper scripts emit typed Flag records keyed to fault families. The remaining 14 skills and 11 helper scripts follow the same patterns; the full library is in the artefact release.

SKILL: ospf-fault-skill failure modes frr_service_down ospf_neighbor_missing ospf_area_misconfiguration

routing daemon stack not running router not in OSPF adjacency link in wrong area vs. peer/topology

leading signals one router or routed segment loses paths while interfaces remain present exact probes ps aux | grep ’zebra|ospfd|watchfrr’ vtysh -c ’show ip ospf neighbor’ vtysh -c ’show running-config’ one-pass coverage python scripts/ospf_snapshot.py stop-and-submit when direct evidence on a router (process, OSPF config, or area assignment) matches one of the three failure modes

(a) Fault-family skill book.

procedure infra_sweep(lab): flags = [] for each device in lab.all_devices(): nft = device.run("nft list ruleset") addr = device.run("ip -br addr") route = device.run("ip route") arp = device.run("arp -n") resolv = device.read("/etc/resolv.conf") # 1. ACL fingerprint dispatch (first match wins) for fault, pattern in ACL_FINGERPRINTS: if pattern matches nft: emit Flag(device, fault); break # 2. Host-config checks if no default gateway in route: emit Flag(device, host_missing_route) if access iface has no IP in addr: emit Flag(device, host_missing_ip) if arp has duplicate MAC for one IP: emit Flag(device, mac_address_conflict) if resolv has malformed nameserver: emit Flag(device, host_incorrect_dns) return flags ACL_FINGERPRINTS: table arp filter -> arp_acl_block ip protocol ospf | proto 89 -> ospf_acl_block tcp dport 179 -> bgp_acl_block tcp dport 80 -> http_acl_block (tcp|udp) dport 53 -> dns_port_blocked icmp type -> icmp_acl_block

(b) Phase-A helper script.

Fig. 6: SADE library examples: a fault-family skill book (a) and a Phase-A helper script (b).

A PPENDIX B SADE D IAGNOSIS A LGORITHM Algorithm 1 formalises SADE’s symptom-to-fault-family diagnosis loop for a single incident. The agent first gathers initial evidence via L IST P ROBLEMS and G ET R EACHABILITY and confirms any visible symptoms (Step 1); if none are found or the picture is ambiguous, it triggers a Step 2 deep network scan using the helper-script set H . Algorithm 1 SADE diagnosis loop for one incident. F is the symptom-to-fault-family index; H is the deep-scan helperscript set. Require: Active simulated incident I 1: Load fault index F and helper set H 2: Step 1: Initial scan 3: (L , R) ← L IST P ROBLEMS() ∥ G ET R EACHABILITY() 4: S ← C ONFIRM(R EACH S YMPTOMS(R)) 5: if S is empty or still ambiguous then 6: Step 2: Deep network scan 7: S ← C ONFIRM(S ∪ D EEP S CAN(I, H )) 8: end if 9: if S is empty then 10: return S UBMIT(is_anomaly=False) 11: end if 12: while S contains an unresolved confirmed symptom do 13: s ← S ELECT L EAD S YMPTOM(S) 14: Step 3: Symptom-to-fault-family mapping 15: f ← F [s] 16: Step 4: Skill-driven detection and localization 17: K f ← F ETCH S KILL( f ) 18: E f ← S KILL P ROBES(K f , I, s) 19: if E f matches a fault fingerprint in K f then 20: (ℓ, D) ← C ANONICALIZE(E f , K f , L ) 21: return S UBMIT(ℓ, D) 22: else 23: S ← U PDATE S YMPTOMS(S, E f ); mark s checked 24: end if 25: end while 26: return S UBMIT(is_anomaly=False)

Each confirmed symptom is then routed through F to its owning skill (Step 3), which probes for fingerprints and submits the canonical fault label on a full match (Step 4); otherwise the loop updates the symptom set and continues until either a fingerprint matches or every symptom has been checked. The negative-anomaly return is reachable only after the deep scan completes, so a clean Phase-1 reachability snapshot never triggers a no-anomaly submission alone. A PPENDIX C R EPRESENTATIVE C ASE E VIDENCE Table VII reports per-agent diagnostic outcomes for two cross-stack faults, showing where SADE’s structured workflow recovers the correct root cause while both baselines fail. Case 1 is presented as a worked example: SADE’s Phase-1 reachability scan returns 70/70 paths at 0% loss with no symptom, so it escalates to a Phase-2 infra_sweep that flags the affected spine alone via the BGP-ACL fingerprint, and the acl-skill confirms the spine nft drop on TCP/179 in 16 turns. Both failure modes reveal the same gap: lacking an explicit symptom-to-fault-family routing step, the baselines either anchor on the first lead and never falsify it (ReAct) or widen

probes without a stop condition (CC-B). SADE’s skill index forces a commitment to one fault family per symptom, and the skill’s stop-and-submit rule prevents the budget-exhaustion failure mode entirely. TABLE VII: Two cross-stack faults: SADE recovers the root cause; both baselines fail. F = final outcome score, O = overall score. Case 1: bgp_acl_block

Case 2: dns_port_blocked

Fault

nft on a spine drops TCP/179.

GT

spine_router_2_3

nft on the DNS pod filters TCP/UDP 53. dns_pod2

SADE

P1 clean (70/70 paths, 0% loss) → infra_sweep flags spine_router_2_3 → acl-skill confirms TCP/179 drop. 16 turns. F=5, O=5. No router probe; submitted host_incorrect_dns on client_0. F=1, O=2. 21 turns of broad probes; never inspected a spine ACL. Budget exhausted. F=1, O=3.

ReAct

CC-B

Why Re- Anchored on DNS, never falsified; no Act router probe, so the BGP-ACL fingerprint stays invisible. Why No termination rule; probing widened CC-B instead of narrowing, exhausting the budget before any spine nft ruleset was inspected.

Pod reachability → direct port-53 probe → pod nft confirms dns_port_blocked. F=5, O=5.

Read mixed DNS as healthy; submitted is_anomaly=False. F=1, O=2. Drifted to BGP control plane; submitted bgp_asn_misconfig. F=1, O=2. Never probed the pod’s port-53 path; partial DNS reads were read as a transient resolver issue. Drifted to the BGP control plane after the DNS symptom and never returned to the pod.

A PPENDIX D S KILLS OVERVIEW TABLE VIII: SADE skills bank: one broad-search skill, two shared utilities, and twelve fault-family skills. Grp Skill Util.

diagnosis-method baseline-behavior big-return

Fault families

link-fault mac-conflict host-ip

acl

tc-fault

ospf-fault bgp-fault

dhcp-fault dns-fault load-balancer resource-cont.

host-crash

Role / fingerprints Drives Step 2 deep scan: L2 → control-plane → host → service. Compares live signal against known-normal patterns; gates symptom commitment. Parses oversized tool output for diagnostically relevant fields. link_detach, link_down, link_flap mac_address_conflict host_ip_conflict, host_wrong_ip, host_wrong_gateway, host_wrong_netmask, host_missing_ip, host_incorrect_dns, host_static_arp arp_acl_block, icmp_acl_block, http_acl_block, dns_port_blocked, bgp_acl_block, ospf_acl_block, link_fragmentation_disabled link_bandwidth_throttling, link_high_packet_corruption, incast_traffic_network_limitation ospf_neighbor_missing, frr_service_down, ospf_area_misconfiguration bgp_asn_misconfig, bgp_missing_route_advertisement, bgp_hijacking, bgp_blackhole_route_leak, host_static_blackhole dhcp_service_down, dhcp_missing_subnet, dhcp_spoofed_subnet, dhcp_spoofed_dns dns_service_down, dns_record_error, dns_port_blocked, dns_lookup_latency load_balancer_overload sender_resource_contention, receiver_resource_contention, sender_application_delay, web_dos_attack host_crash

The Skills Bank comprises 15 SKILL.md files in three groups, summarised in Table VIII: a broad-search skill that drives the Step 2 deep scan, two cross-cutting utilities consulted before symptom commitment, and twelve fault-family skills invoked at Step 4 once a symptom has been mapped to its owning family. The implementation -skill suffix is omitted from the cells. Diagnosis manual excerpt. The diagnosis manual defines the broad-search behavior used when the initial reachability scan does not expose a confirmed symptom. In this case, the agent enters the diagnosis-methodology-skill rather than committing directly to a fault-family skill. The manual orders the deep scan into four phases. Phase A inspects L2 and infrastructure state using infra_sweep.py and l2_snapshot.py; Phase B inspects routing, control-plane, and traffic-control state using ospf_snapshot.py, bgp_snapshot.py, and tc_snapshot.py; Phase C inspects host-local behavior using host_path_snapshot.py, dhcp_link_history.py, and safe_reachability.py; and Phase D inspects service and resource-pressure behavior using service_snapshot.py, pressure_sweep.py, dns_client_snapshot.py, and http_client_snapshot.py. The agent returns to the Fault Index only after this broad search surfaces a confirmed symptom, preventing speculative entry into a fault-family skill.