Ruckus ICX / FastIron Factory Reset for ITAD: Version-Safe Wipe and Verification Checklist

Short answer

For an owner-authorized Ruckus ICX or FastIron switch, check the installed software version and stack role before choosing an erase command. Use erase system factory-default only when the exact installed release documents and accepts it. On older releases that do not support that command, use the release-supported erase startup-config workflow from the correct standalone or controller context, then reload and verify the clean state.

A successful erase message is only one evidence point. The ITAD work order should also prove the pre-reset image and license state, the chosen version branch, the reload result, and the absence of prior-owner configuration after boot.

Scope: This checklist applies only to switches your organization owns or is explicitly authorized to process. It is a configuration reset and verification workflow, not a claim of certified media sanitization. Follow the customer contract and your approved destruction policy for any storage that requires a stronger method.

Version gate: decide before you erase

FastIron command availability changes across release trains. Do not infer support from the ICX model name alone.

Installed context	Safe decision
The exact release documents and CLI help accepts erase system factory-default	Use the documented factory-default path and follow its prompts
The command returns Invalid input or is absent from release documentation	Stop retrying it; use the older release-supported startup-config path
Device is a stack member without Active or Standby authority	Do not force a controller command from the member; resolve stack ownership first
Version, role, or boot image cannot be confirmed	Pause and escalate instead of guessing

Field note: In a sanitized owner-provided ICX7450-48P bench session, the running image reported FastIron 08.0.70d while an 08.0.80f image was also present. On the 08.0.70d runtime, erase system factory-default returned Invalid input. That is why this guide uses a version gate instead of presenting the newer command as universal.

The presence of a newer secondary image does not change the commands accepted by the currently running image. Record which image is active before acting.

Pre-reset checklist

• Match the device to an owner-approved work order.
• Isolate the switch from production and customer networks.
• Establish stable console access and capture the full session internally.
• Record the running FastIron version and active boot image.
• Record primary and secondary image inventory.
• Determine whether the unit is standalone, Active, Standby, or a stack member.
• Preserve the customer-approved configuration evidence before erasing it.
• Record license and entitlement state using the procedure for that release.
• Select the reset branch supported by the running image.
• Confirm that reload downtime and power stability are acceptable.
• Execute the erase and reload with an operator confirmation gate.
• Verify the post-boot state before connecting any network cable.
• Attach sanitized pass/fail evidence to the asset record.

For a comparable multi-member ownership problem, review the Juniper Virtual Chassis wipe checklist. The commands differ, but the core rule is the same: a controller-level success does not automatically prove that every physical member is clean.

1. Capture version, image, and stack context

Begin with non-destructive commands:

show version
show flash
show stack
show running-config

Command output varies by train and stack state. Keep the full transcript restricted, then extract only the approved evidence fields: model family, running release, boot image choice, stack role, collection timestamp, and result.

Do not copy customer hostnames, serial numbers, MAC addresses, IP addresses, usernames, SNMP communities, authentication data, license identifiers, VLAN names, routing neighbors, or configuration blocks into a public resale record.

Boot images and licenses are separate decisions

A configuration erase should not be treated as permission to delete firmware images, boot files, licenses, or entitlement data. Record the primary and secondary images before reset. Preserve or remove licensed features only according to the asset contract and vendor entitlement policy.

If image selection is inconsistent, an expected image is missing, or the switch is booting an unapproved train, stop the wipe workflow and route the unit to repair or engineering. Do not turn a reset task into an unplanned firmware change.

2. Branch A: factory-default command supported

Use this branch only when the running release's approved documentation and CLI context confirm the command:

erase system factory-default

Read every prompt before confirming. Capture the command, confirmation, device response, and any reload requirement in the transcript. Do not assume the operation completed merely because the console returned to a prompt.

After the erase, reload only as required by the documented workflow and continue to the post-boot verification section. If the command is rejected, do not try guessed variations. Return to the version gate and use the older-release branch if it is supported.

3. Branch B: older-release startup-config path

When the running image does not support the factory-default command but does support the older reset workflow, use:

erase startup-config
reload

The device may report that the startup configuration is already empty. Some FastIron contexts also report removal of related DHCP lease or stack/SPX PE state. Preserve that response in the internal transcript; it helps distinguish an already-clean unit from a command that failed for another reason.

During reload, the CLI can present more than one confirmation, including a warning that it could not determine whether running configuration changed. Answer affirmatively only when all of these are true:

• the work order authorizes the reset;
• the pre-reset evidence has been captured;
• the selected branch matches the running release;
• the device is isolated;
• the console transcript is active;
• no unsaved configuration must be retained.

If the reload begins, keep capturing until the switch finishes booting or reaches a documented exception. A disconnected terminal, power loss, boot loop, or unexpected boot monitor is a failed verification—not a completed wipe.

4. Stack and member limitations

FastIron stack roles change what a local console can erase. A member without Active or Standby authority may reject erase startup-config because it does not own the stack configuration.

Do not work around that rejection by guessing commands. Choose one authorized path:

1. Run the stack-wide procedure from the Active or supported Standby context.
2. If the work order requires dismantling the stack, use the release-documented member-removal procedure.
3. Use stack unconfigure me only when the exact release documents it, the console is on the intended member, and the work order explicitly authorizes removal of that member's stack identity.
4. Power and verify members one at a time when the contract requires per-chassis proof.

Record every physical member as a separate asset. A clean controller record must not be copied to unverified members.

5. Reload and verify the clean state

Keep the switch isolated after boot. Re-run non-destructive checks:

show version
show flash
show stack
show running-config

Use the release-supported display command to confirm the stored startup configuration is absent or at the expected factory baseline. Then verify:

Check	Pass signal	Fail signal
Boot	Normal boot completes on an approved image	Boot loop, monitor prompt, missing image, or filesystem error
Startup state	No prior-owner startup configuration remains	Customer configuration or unexplained stored state persists
Running state	Only expected factory/default state is present	Prior VLANs, routes, users, SNMP, AAA, or management settings remain
Stack state	Matches the work order for standalone or member disposition	Old stack identity or unverified members remain
Images	Expected primary and secondary images are still readable	Image missing, corrupt, or unexpectedly changed
Licenses	Internal entitlement record matches the approved disposition	License state is unknown or sensitive identifiers were exposed
Evidence	Transcript includes version gate, erase result, reload, and final checks	Only a screenshot or unverified operator note exists

Do not attach the reset switch to a production network just to see whether it receives an address. Use an isolated bench network only when the approved verification procedure requires network testing.

Pass, conditional pass, and fail

• Pass: correct version branch used, erase completed, reload was normal, prior-owner configuration is absent, expected images remain readable, and stack state matches the work order.
• Conditional pass: the unit is clean but needs an approved firmware normalization, license review, PoE test, or additional member verification before resale.
• Fail or repair: command path cannot be validated, storage or boot errors appear, the switch will not reload cleanly, or configuration persists.
• Stop and escalate: ownership is unclear, stack scope is ambiguous, entitlement handling is unresolved, or customer-sensitive data appears outside approved evidence storage.

For switch-specific verification patterns, compare the FortiSwitch factory-reset checklist and the Cisco Catalyst ITAD reset workflow.

Evidence artifacts to retain

Keep these artifacts in the approved internal system:

• work order and authorization reference;
• asset identifier mapped to the physical chassis;
• sanitized console transcript with timestamps;
• running FastIron release and active boot image;
• primary and secondary image inventory;
• pre-reset stack role and member mapping;
• selected reset branch and why it was valid;
• erase response and reload confirmations;
• post-boot configuration and stack verification;
• license-handling decision without public entitlement identifiers;
• final disposition and reviewer.

A public resale note should be limited to the allowed summary, for example: authorized configuration reset completed on a version-supported path; isolated reboot and clean-state checks passed; restricted evidence retained under the asset record.

CliDeck workflow

CliDeck can turn the version gate into an operator-safe workflow:

1. Scan the chassis and require the authorized work order.
2. Start the console transcript before any destructive command.
3. Capture show version, image inventory, and stack role.
4. Branch the checklist by the running release and CLI support.
5. Require a second confirmation before erase and reload.
6. Keep the console attached through the complete boot.
7. Run the clean-state checks before enabling any network connection.
8. Store sanitized pass/fail results per physical member.
9. Route exceptions to firmware, license, repair, or ownership review.

The final evidence should answer four questions: Which software context was running? Why was this erase path valid? Did the device reload normally? What proves the prior-owner state is gone? If any answer is missing, the workflow is not complete.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.

Who this is for

This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.

When to use this

Use this guide when:

• Your team owns or is authorized to process the device.
• You need to reset, zeroize, recover, reimage, verify, or document a network device.
• The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.

When not to use this

Do not use this guide when:

• You do not own or have authorization to work on the device.
• The device is outside your approved change, recovery, or processing scope.
• The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
• You need a certified data destruction procedure and your organization has not provided one.

Workflow

• Confirm ownership, processing scope, device identity, and approved procedure.
• Connect through the console or approved management path and capture the session context.
• Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
• Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
• Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.

Verification checklist

• Device identity matches the asset record.
• Console or session log is attached to the asset.
• The reset, zeroize, recovery, or reimage method is recorded.
• The post-reboot state matches the expected clean or recovered state.
• Verification commands and outputs are captured.
• Exceptions or failures are quarantined instead of marked ready.

Resale and evidence checklist

Before marking the device ready for resale, capture:

• Device model and serial number
• Console transcript or session log
• Reset, zeroize, reimage, or recovery method used
• Any confirmation prompts and operator decisions
• Post-reboot state
• Visible default or clean-state prompt
• Verification commands and outputs
• Hardware alarms or boot errors
• License, entitlement, or customer identifiers handled according to policy
• Exceptions, failures, or quarantine decisions
• Final pass/fail/exception status attached to the asset record

What not to publish

Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.

Common mistakes

• Processing a device without owner authorization or the correct asset record.
• Treating a factory reset as certified data destruction.
• Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
• Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.

CliDeck workflow fit

CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.

Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.

FAQ

Is this a certified data destruction procedure?

No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.

Does CliDeck provide vendor OS images?

No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.

Should I publish the full console log?

Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.

Can CliDeck help with this workflow?

Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.

Related guides

• Brocade FastIron Factory Reset for ITAD: Config, Keys, and Boot-State Verification - Use this authorized FastIron ITAD checklist to distinguish factory-default from config erase and verify a clean boot state.
• ExtremeXOS Factory Defaults for ITAD: unconfigure switch vs unconfigure switch all - Choose the safe ExtremeXOS unconfigure switch path for resale. Covers NVRAM versus full erase, stack limits, reboot behavior, and clean-state verification.
• Ubiquiti UniFi Factory Reset: Adoption Cleanup and Resale Verification - Reset an owned UniFi switch safely, distinguish local factory defaults from controller-side adoption cleanup, and verify the device before resale.
• Palo Alto Panorama-Managed Firewall Reset: Detect and Clear Managed Remnants Before Resale - Use this authorized ITAD checklist to separate PAN-OS factory-reset proof from Panorama-release verification before firewall resale.
• Check Point Appliance Factory Reset and Gaia Clean-State Checklist for ITAD - Use this release-aware ITAD checklist to select a Gaia recovery target safely, verify factory reset completion, and document a clean-state handoff.