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

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 for ICX platform specifics.

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.

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

Tip

When you ask for switch config, name the firmware: “generate the config for VLAN 200 tagged on 1/1/1-1/1/8 on a switch running 10.0.20”. It removes the guesswork entirely.

Syntax is always verified

The rule inside R1-MCP is that FastIron CLI is never emitted from memory — it’s verified against the indexed documentation first, and the section it came from is recorded. 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:

1. Verify syntax against the FastIron docs for the switch’s train.
2. Back up the running configuration.
3. Apply through a held device_cli session — the same live console the R1 web UI gives you.
4. Read back and verify against the backup.

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.

Related

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