From Vague Network Complaint to Root Cause in Two Minutes

In network operations, the initial report is often incomplete. A statement like “some traffic works, but large transfers fail” points to a real problem, but not to a single obvious cause. Similar symptoms can come from multiple issues, including routing problems, interface instability, packet loss, ECMP path behavior, or an MTU mismatch.

In this test, Nanites was given the following prompt in the CLI:

“Large transfers between R1 and R2 seem to fail, even though some basic connectivity still works. Can you investigate?”

https://video.wixstatic.com/video/c99bea_c15d533acbc74012ad8be6dc5c8f060b/1080p/mp4/file.mp4

From that starting point, it investigated the Cisco path in read-only mode. It checked interface state, routing, and BGP status on both devices rather than assuming a cause from the symptom alone. The run included interface brief commands, full interface inspection, route checks, and BGP summary checks on both R1 and R2, and completed in 1 minute and 59 seconds.

A key aspect of the run was that it separated control-plane health from data-plane behavior. The links were up, BGP sessions were established, and routing appeared normal. That ruled out several common control-plane failure modes and narrowed the investigation toward packet-forwarding behavior instead.

The system then identified an MTU mismatch on the 10.10.2.0/30 interconnect. On R1, the interface had an IP MTU of 1500 bytes. On R2, the corresponding interface was set to 9000 bytes. That type of mismatch can produce exactly the reported symptom pattern: smaller traffic appears to work, while larger packets fail.

The run also noted other counters elsewhere in the network, including cumulative drops on interfaces not directly tied to the affected interconnect. Those were not ignored, but they were kept separate from the main hypothesis. That distinction matters because operational data often contains background noise, and not every anomaly is related to the reported issue.

What matters here is not simply that MTU was identified. What matters is the path from an incomplete symptom report to a specific, evidence-based diagnosis. The initial prompt did not mention MTU, fragmentation, or a suspected interface. The conclusion came from checking live device state and narrowing the possibilities based on what the network was actually reporting.

That is what made the result operationally useful. It gave an engineer something concrete to validate and correct. In this case, the next step would be to align MTU on both ends of the interconnect and re-test large-packet behavior. The run shortened the path from a vague complaint to an actionable diagnosis.