Juniper RSI Collection Before Reset: Asset Grading Diagnostic Checklist

Short answer

Collect Juniper RSI before an authorized reset when the device is stable enough to provide diagnostic evidence for grading or refurbishment. Save the RSI privately, capture the key hardware and alarm state, and then proceed with the reset; the file may contain configuration and other sensitive details.

When This Applies

Collect RSI when a Juniper switch, router, firewall, or Virtual Chassis member arrives at the bench and you need grading evidence before wiping it. It is especially useful when the buyer or internal policy cares about software version, alarms, storage health, interface state, optics, chassis inventory, or crash/core information.

Skip or shorten RSI collection when the device is unstable, repeatedly rebooting, or contains data that your policy says must be destroyed immediately. In those cases, record the exception and move to the approved wipe path.

What RSI Proves For Resale

Evidence area	Why it helps grading
Model and software	Confirms platform and Junos release before reset
Chassis hardware	Documents FRUs, modules, routing engines, and inventory
Alarms and environment	Separates sellable hardware from exception stock
Interface state	Shows ports, optics, link patterns, or missing modules
Storage and core files	Flags disk problems or crash history
Virtual Chassis state	Captures member roles before stack disassembly
Configuration context	Helps explain why a device was wiped or quarantined

Because RSI can include configuration data, treat it like a private evidence package, not a public artifact.

Minimal Command Set

set cli screen-length 0
show version
show chassis hardware
show chassis alarms
show system storage
show interfaces terse
show virtual-chassis status
request support information | save /var/tmp/rsi-<asset-id>.txt
file list /var/tmp/rsi-<asset-id>.txt detail

Use an internal asset ID in the filename. Avoid customer names, external ticket numbers, or serial numbers that should not travel outside the evidence system.

Optional Logs Archive

If the device is being graded for diagnostics, not just wiped, archive logs before reset:

file archive compress source /var/log/* destination /var/tmp/logs-<asset-id>.tgz
file list /var/tmp/logs-<asset-id>.tgz detail

Keep the RSI file and logs archive inside your approved evidence storage. Do not attach them to a public listing and do not paste raw output into an article, marketplace page, or customer email without review.

Bench Note: Why Pre-Reset RSI Matters

In real Juniper bench transcripts, an EX3400-48P running Junos 21.4R3-S2.4 returned to a clean post-zeroize state and displayed auto-image-upgrade and phone-home style boot messages after reset. That post-reset capture was useful, but it could not recover the previous alarms, configuration context, or operating state that would have been present before the wipe.

That is the reason RSI belongs before reset: once the device is zeroized, the best evidence about the old state is gone.

What To Review Before Saving The Device As Ready

• RSI file exists and has non-zero size.
• Model and Junos version are recorded separately in the asset ticket.
• Chassis inventory matches the photographed labels and modules.
• Hardware alarms are marked pass, warning, fail, or not tested.
• Virtual Chassis state is captured when the device was part of a stack.
• Logs archive exists when grading requires it.
• Sensitive output is stored internally and not exposed publicly.
• Reset/wipe status is recorded separately from diagnostic status.

What Not To Do

• Do not treat RSI as a sanitization step. It collects evidence; it does not wipe the device.
• Do not leave RSI files on the device when the unit is shipped.
• Do not publish RSI output because it can include hidden or sensitive configuration data.
• Do not let a failed RSI block urgent sanitization when policy says the device must be wiped immediately.
• Do not use customer names in filenames.

CliDeck Workflow Fit

A CliDeck workflow should turn RSI collection into a predictable pre-wipe stage: collect console transcript, run the evidence commands, save file names and sizes, tag sensitive artifacts, then require the operator to choose wipe, quarantine, or exception. The operator should not have to remember which proof belongs before reset and which proof belongs after reset.

Related CliDeck Field Guides

• Juniper EX Switch zeroize for Resale
• Juniper SRX Factory Reset vs request system zeroize

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.

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

• Palo Alto Tech Support File Before Wipe: What an ITAD Bench Should Record - A practical Palo Alto tech support file checklist for ITAD teams collecting diagnostics before wipe, factory reset, refurbish grading, or resale.
• Juniper Virtual Chassis Wipe for ITAD: Zeroize Each Member Without Leaving VC Config Behind - A Juniper Virtual Chassis wipe and zeroize checklist for ITAD teams preparing owned EX and QFX members for resale without leaving member configuration behind.
• FortiGate TAC Report Before Wipe: What to Capture for Refurbish Grading - A practical FortiGate TAC report and pre-wipe diagnostic checklist for ITAD, refurbish, and resale teams preparing owned FortiGate units for reset.
• NIST SP 800-88 Rev. 2: A Defensible Media Sanitization Process - Build an asset-level sanitization workflow with method selection, execution evidence, verification, validation and clear exception handling.
• Aruba Instant AP Factory Reset: Isolate the Device and Verify the Fresh Baseline - For an owned Aruba Instant AOS-8 access point, use the supported factory-reset procedure for the exact model and software.