ICX switches and FastIron docs

The ICX feature adds full-text search over the RUCKUS FastIron documentation set and an end-to-end workflow for configuring ICX switches.

Enable it under Features in the dashboard.

What’s indexed

The release-tagged FastIron documentation set — the command reference plus the configuration guides:

commandref · l2guide · l3guide · securityguide · managementguide · monitoringguide · dhcpguide · ipmulticastguide · trafficguide · switchstackingguide · debugcommand · featuresupportmatrix · licensing · mibreference · upgradeguide

The 10.0.10 train also includes fipscc-config and scalingguide.

Results come in two kinds:

command — one section per CLI command: syntax, parameters, modes, examples.
concept — configuration-guide prose.

There’s also a hardware documentation search, search_icx_hw_docs, over the install guides and technical specifications for ICX 7150, 7250, 7450, 7550, 7650, 7750, 7850, 8100, and 8200 — port counts, PoE budgets, power supplies, stacking limits, and other physical facts.

Firmware trains matter

FastIron syntax differs between trains, and this is the single most important thing to get right.

R1-MCP scopes every search to one release. By default it uses the newest train, but the correct behavior is to search against the target switch’s firmware train — read switchFirmwareVersion from R1, or run show version live, and search that.

The minor matters: 10.0.10 versus 10.0.20.
The patch level does not — 10.0.20b_cd1 normalizes to the 10.0.20 train.
Do not mix trains within one switch’s configuration.
A train that isn’t indexed (anything other than 10.0.10 or 10.0.20 today) silently falls back to the newest train. Every result names the release it searched, so check it.

BGP-EVPN, for example, exists only on 10.0.20. Asking against the wrong train produces syntactically wrong CLI that looks plausible.

Syntax is checked against the docs

R1-MCP instructs Claude to verify FastIron CLI against the indexed documentation before emitting it, rather than writing it from memory, and to record the section it came from. That is an instruction to the model, not something the server can enforce — which is why the export marks what wasn’t checked. When a configuration is exported as a MOP, each step carries a citation of the form:

validated against [doc] [release] — [section title] (p*[page]*)

A step with no such provenance is exported marked as not validated against documentation. That’s deliberate: an unverifiable config change is worth less than an honest “I didn’t check this.”

The configuration workflow

For a multi-command job, the default path is:

Verify syntax against the FastIron docs for the switch’s train.
Back up the running configuration.
Apply through a held device_cli session — the same live console the R1 web UI gives you.
Read back — take a post-apply backup and compare it with the first. R1’s backup comparison returns both full configs, not a diff, so the comparison is done client-side; on a captured test bed, config_diff gives you the diff directly.

The alternative apply path is CLI templates, for unattended or staged pushes. Both verify the same way — via config backups plus a device_cli read-back.

BGP-EVPN fabrics

There’s a dedicated workflow prompt — ICX BGP-EVPN fabric build / validate — that runs the build or validation end to end. It’s the fastest way in for fabric work.

The feature also unlocks ICX reference docs Claude reads on demand: icx-workflow, icx-bgp-evpn, icx-evpn-playbook, icx-static-vxlan, icx-ops-playbook, icx-troubleshooting, and the DISA STIG validation docs stig-icx-l2s and stig-icx-router.

Live CLI and MOPs — running commands on the device
Test beds — swapping lab hardware between config sets
Write Guard — confirm before anything changes