I tried it on Switch Engine (EXOS) and Claude Code
I'm preparing a hands-on workshop for the Extreme Control Professional (ECP) track, built on GNS3 with Switch Engine (EXOS) virtual switches. I sat the ECP Switching exam myself, and in my judgment this lab is a faithful replica of it in format and difficulty. (I'm describing my own lab here, not exam content.) Before putting real students in front of it I gave it to an AI agent, with the same brief a student gets and only the official documentation to read, and measured what happened.
The setup
A small campus pod: two distribution switches (A and B) and one access switch (C), with two PCs and a simulated upstream router.
Phase 1 – design and build from the brief
I selected a mix of content from the I&C and Advanced Conf labs, a mix of L2, LAG/MLAG, Routing, ACLs and the like. I created high level requirements that the students have to design and deploy in the setup above.
Phase 2 – troubleshooting
When the design is completed and saved, I insert three faults from the Tbshoot lab. I don't tell the students which ones, it can be a disabled port, or a mismatched vlan, or a routing issue . . . The symptom is that the gateway is not reachable and Internet access is lost.
The agent and its constraints
- Model: Claude Opus 5.5, run non-interactively, with no memory or custom instructions
- Material: only the official Student and Lab Guides (Installation & Configuration, Advanced Configuration, Troubleshooting, v26.2.0) and the Switch Engine 33.1.1 User Guide and Command Reference, plus the EXOS 31.6 User Guide. The switches run 32.6.3, and the agent was told so.
- Sandbox: no internet, no access to my files or to the reference solution, no sub-agents. It could only run three commands: one for the switch consoles, one for commands on the PCs, and one to read the exam clock. A broker restricted it to a single pod and logged every command.
- Limits: a 4-hour exam clock and a 100 USD API budget.
- Grading: done by my own verification scripts, not by the agent.
Result
| Phase 1 (design) | 30.6 min. 42/42 requirements, 22/22 behavior checks, 8/8 hygiene checks. 23/23 checks with a WAN cut. |
| Phase 2 (3 faults) | 8.1 min. All three fixed, configuration saved. |
| Total | 38.7 min of 240 (16 %) |
| Cost | About 5 USD of API usage |
Activity: 213 commands sent to the pod, 46 of them configuration. 107 model turns. 7.77 M tokens, almost all of it cached reads.
What it did well
- It read the documentation selectively with text search instead of loading whole manuals.
- It built a complete, correct design with no dead ends.
- It added robustness we did not ask for: `lacp timeout short` on the LAGs, for instance.
- It stress-tested its own design.
- It noticed that one `save` had been cancelled by accident (the next command answered the prompt) and saved again on all three switches.
Takeaway
With the documentation in hand, an AI agent can design and troubleshoot a lab at ECP exam level, end to end, in under 40 minutes. The skills involved are fast reading of technical documentation, reasoning about root causes and verifying your own fix. The lab trains those same skills, and a human takes much longer to exercise them, just because we are slower finding and researching written documentation, and converting it in actual actions.
I'm happy to share the harness design or the fault list in more detail. If you are running similar labs, I would be interested to hear if you are running similar tests or your own experience using AI to configure your networks.
