Juniper Virtual Chassis Wipe for ITAD: Zeroize Each Member Without Leaving VC Config Behind

Short answer

For an authorized Juniper Virtual Chassis wipe, process every physical member separately. Identify and isolate each switch, zeroize it through its own console session, and verify that no former Virtual Chassis configuration remains before marking any member ready for resale.

Why Virtual Chassis Needs Extra Care

A standalone EX switch is usually straightforward: collect proof, zeroize, reboot, verify. A Virtual Chassis has a different risk: the operator may be logged into one member while the stack state, member IDs, and configuration history involve several physical units.

For ITAD and resale, the failure mode is simple. One member looks clean, but another member still carries old VC state, old member identity, logs, or customer-specific configuration remnants. That is why the work order should track members individually instead of treating the stack as one black box.

Pre-Wipe Intake Checklist

Capture	Command or method	Why it matters
Stack status	show virtual-chassis status	Identifies master, backup, line-card roles, and member IDs
Hardware identity	show chassis hardware	Ties member inventory to physical labels
Junos version	show version	Documents software state before reset
VC configuration	show configuration virtual-chassis where available	Finds preprovisioning and member-specific config
Alarms	show chassis alarms	Separates wipe failures from hardware problems
Photos	Front/back labels and stack cabling	Preserves proof after the stack is disassembled

If the device is still cabled as a production stack, disconnect customer uplinks first. Leave only the console and the power path required for bench work.

Recommended ITAD Workflow

1. Photograph the full stack and each member label.
2. Capture Virtual Chassis status from the active management context if available.
3. Record which physical member is master, backup, or line-card.
4. Power down and separate the members so each switch is processed as an individual unit.
5. Connect serial console to one member at a time.
6. Run request system zeroize or the stronger approved variant required by policy.
7. Let the member reboot naturally.
8. Log in from console after the reset and capture identity and default-state evidence.
9. Repeat the same steps for every former member.

Do not mark the stack complete until every physical member has a pass, fail, or exception result in the asset record.

Commands To Capture Before Zeroize

set cli screen-length 0
show version
show chassis hardware
show virtual-chassis status
show chassis alarms
show system storage
show configuration virtual-chassis

Some recovered or partially reset members may not have every command available from the current role. If a member reports that full CLI access belongs on the VC master, capture that warning and process the member individually from console instead of relying on the old stack control plane.

Zeroize Decision Table

Situation	Preferred action	Evidence to keep
Normal member, console works	request system zeroize	Prompt, confirmation, reboot, post-reset login
Policy requires stronger media scrub	request system zeroize media when supported and approved	Start/end time, long-running scrub notes, reboot proof
Member is still in line-card role	Isolate it and process from local console	Role warning plus post-isolation wipe proof
Member will not boot normally	Quarantine for recovery workflow	Boot log, errors, asset exception
Mixed models or mixed Junos releases	Process one unit at a time	Per-member version and result record

Bench Note: EX3400 Virtual Chassis Behavior

In a real EX3400-48P bench transcript running Junos 21.4R3-S2.4, the console warned that the chassis was operating in a non-master role as part of a Virtual Chassis. The CLI also showed request system zeroize options including local and media. When the zeroize was confirmed, the device warned that the system would reboot and might not boot without configuration, then printed a zeroizing message for the local FPC before rebooting.

The practical takeaway is direct: a VC member is not just a port group in a stack diagram. It is a physical switch with its own reset result. Treat each member as its own resale asset.

Post-Wipe Verification Checklist

• Console login returns to a default or clean state expected for the platform.
• Model and Junos version are captured after reboot.
• No old hostname, customer text, SNMP community, TACACS/RADIUS server, management IP, or VC preprovisioning remains visible.
• Former member ID and role are not still presented as a customer stack configuration.
• Hardware alarms are recorded separately from wipe status.
• Transcript includes command, confirmation, reboot, and post-reset checks.
• The asset ticket records each former member individually.

Common Mistakes

• Zeroizing only the master member and assuming the stack is clean.
• Shipping separated members without proving each member was reset.
• Leaving old VC preprovisioning or member notes in the resale record.
• Treating a role warning as a harmless message instead of an indication that the operator may be on the wrong member.
• Publishing raw transcripts with serial numbers, licenses, or customer hostnames.

CliDeck Workflow Fit

A good CliDeck workflow for this job should force member-by-member processing: scan asset label, connect console, capture pre-wipe identity, run the approved zeroize path, wait through reboot, capture post-wipe identity, and require a pass/fail/exception status before the technician can move to the next switch.

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.

Quick checklist

• Identify the device and console connector
• Use the correct console cable or adapter
• Find the correct serial port or COM port
• Start with the expected baud rate and 8N1 settings
• Press Enter to confirm the prompt
• If output is unreadable, check baud rate and line settings
• If the port will not open, check permissions, drivers, and whether another program is holding the port
• Save useful session notes or logs when the work matters

Traditional cable vs CliDeck workflow

A traditional USB serial cable is still the simplest option for quick local work. CliDeck becomes useful when the console session needs browser access, notes, runbooks, sharing, logs, remote hands support, or a portable controller workflow.

Console Server Go can work like a wired USB serial adapter when connected by USB, but it also adds SSH Console on SSH-enabled firmware builds, browser Workspace, live sharing, 24h+ battery operation, OLED status, and magnetic rack mounting.

Net Controller is the larger 12-port option for teams that need to process many network devices with approved workflows, barcode/API tracking, provisioning files, and evidence-style logs.

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.

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

• Juniper EX Switch zeroize for Resale: Clean Config, Logs, and Key Material - A Juniper EX zeroize and clean-state verification checklist for ITAD and resale teams clearing owned EX switches before shipment.
• FortiGate USB Auto-Install Before Resale: Prevent Old Configuration from Returning - Remove unreviewed USB media before resetting an owned FortiGate and inspect USB auto-install settings on supported models.
• A Technician Bench Workflow for Console Capture, Reset, and Exception Handling - Build the bench process around explicit checkpoints: identify the asset, confirm authorization, capture the permitted starting state, select the...
• pfSense and Netgate Reinstall for Resale: Console, config.xml, and Storage Scope - A pfSense configuration reset restores settings but does not remove arbitrary filesystem changes.
• EdgeRouter Reset and TFTP Recovery: A Console-Friendly Resale Workflow - Use a normal factory reset when an owned EdgeRouter boots correctly and only needs a default configuration.