On this page
In the last post I built two VXLAN EVPN sites, an ISN and one stretched network in Nexus Dashboard, click by click. The natural question after a build like that is not "can I add another VLAN". It is the one you get at two in the morning: why can't 192.168.100.11 talk to 192.168.100.21, and what changed. This two-part series is about answering that question with an agent that works with Nexus Dashboard rather than around it.
I called it FabricSRE. Part 1 covers the ground rules, what Nexus Dashboard 4.3.1 actually gives you over its API, the fabric twin, and the ten-hypothesis investigation, including the harness that proves the investigation names the right failure. Part 2 covers incident triage from Nexus Dashboard's own anomaly export, change assurance with an approval bound to the exact config a human saw, the change timeline, and driving all of it from Claude Code over MCP. The code is public at github.com/aramidetosin/fabricsre.
Three rules before any code
The design has three rules, and every module in the repository can be read against them.
- The model reasons. It writes intents, orders hypotheses and narrates results. It never types configuration.
- Deterministic code acts. Every hypothesis in an investigation is a Python predicate over real data. Every write goes through a state machine that a model cannot skip.
- Nexus Dashboard and NX-OS stay the source of truth. The twin is a cache with a timestamp on every row, never an authority. An answer that uses it quotes the age of the rows.
One consequence I want to call out early: there is no "confidence: 94%" anywhere in this tool. A percentage from a language model is a number it made up. What you get instead is a ledger, each hypothesis confirmed or refuted or untested, each with the device, the command, the timestamp and a hash of the output that decided it. Confidence is something you can count.
The fabric it runs against
Same environment as the last post, now on Nexus Dashboard 4.3.1.175 with NDFC 12.6.0.267: DC1 and DC2 with two spines, two leaves and two border gateways each, all eBGP Multi-AS, two core routers as an NDFC managed ISN, a Multi-Site fabric group, and one network, NET-A, VLAN 2300, VNI 30000, stretched across both sites with a single-homed host on every leaf. Fourteen N9K-C9300v switches under containerlab.
