CliDeck
PlatformLog in
Workspace

Juniper EX Switch zeroize for Resale: Clean Config, Logs, and Key Material

ITAD & Refurbishment
#juniper-ex#zeroize#itad#network-device-wipe#virtual-chassis#ITAD & Refurbishment#runbooks#network-device-processing
← Back to Blog

Short answer

For an authorized Juniper EX resale wipe, request system zeroize is the clean-state path that removes configuration, logs, and key material. Capture identity and Virtual Chassis state first, then verify after reboot that the switch returns without prior-owner configuration.

Why zeroize Is Usually Better Than load factory-default For Resale

load factory-default loads a factory configuration candidate. It is useful for recovery or rebuilding a config, but it is not the same resale proof as zeroizing a device. It also needs a commit path and may require root authentication work before the configuration is valid.

For resale, zeroize is usually stronger because it is designed to clear the device and reboot into a factory-default state. Use it when the goal is sanitization, not just making the current configuration look default.

Pre-zeroize Intake Checklist

Before you run zeroize, capture:

  • front-panel and label photos
  • model and Junos version
  • serial number for internal asset matching
  • show chassis hardware output if CLI is available
  • show version output where available
  • show virtual-chassis status if the switch may be part of a VC
  • current boot state: normal, backup image, recovery, or shell
  • console access method and baud rate
  • operator, timestamp, and asset ID

If the switch is a Virtual Chassis member, do not assume the member is clean because the master was wiped. Treat each physical unit as its own asset until its local state is verified.

Standard zeroize Workflow

From operational mode:

request system zeroize

Confirm only after the transcript is running and the asset has been identified. The expected result is a warning, a confirmation prompt, shutdown of services, disk sync, and reboot.

For a batch process, do not send the confirmation automatically without an operator checkpoint. A mistyped target can erase the wrong unit.

Virtual Chassis Warning

EX switches can retain Virtual Chassis identity and member behavior in ways that confuse a resale bench. If the console says the chassis is operating in a non-master role, stop and document that state.

Practical checks:

  • identify whether you are on the master or a member
  • capture the warning text in the transcript
  • check VC status from the master when available
  • zeroize each physical member when processing a broken stack
  • verify that no member-specific config remains after reboot

A switch that still behaves like a VC member is not clean resale stock.

Bench Note

On an EX3300-48P running Junos 14.1X53-D25.2, our recovery transcript showed a non-master Virtual Chassis warning before cleanup. The operator entered configuration mode, ran load factory-default as a recovery step, exited without committing, and then ran request system zeroize. The switch warned that the system would reboot, accepted confirmation, reported zeroizing fpc0, synced disks, and rebooted. Afterward, the transcript showed the Amnesiac login state and a post-reset show chassis hardware check for the EX3300-48P.

What To Verify After Reboot

Capture these pass/fail signals:

  • login banner or prompt shows default state, often Amnesiac on Junos devices
  • no prior hostname appears in the prompt
  • no old management IP, route, SNMP, syslog, TACACS, RADIUS, NTP, or user configuration is visible
  • Virtual Chassis warnings are gone or documented as expected for a standalone member test
  • show chassis hardware still identifies the expected physical model
  • alarms are either clear or recorded as hardware exceptions
  • transcript is attached to the asset record

If a unit boots from a backup Junos image, document it. That may be a refurbish grade issue even if the zeroize succeeded.

Data That Should Not Go Public

Do not include raw zeroize transcripts in resale listings. They can contain serials, license identifiers, old hostnames, user names, or customer clues.

Public listing proof should be a sanitized summary:

  • device family
  • tested boot state
  • clean configuration verification
  • hardware exception notes
  • date of wipe
  • internal proof record ID

CliDeck Workflow Fit

CliDeck can guide the operator through the EX switch process: detect a VC warning, pause for a member/master decision, capture the zeroize confirmation, watch for reboot, and require post-zeroize verification before the asset can be marked ready.

That matters in EX lots because the risky cases are not always failed devices. They are devices that reset but still carry stack context, backup-image warnings, or incomplete proof.

Final Pass Criteria

Mark the EX switch as resale-ready only when:

  • zeroize command and confirmation are in the transcript
  • reboot completed
  • default or Amnesiac state is visible
  • no prior-owner config is visible
  • VC member state is cleared or explicitly documented
  • model and hardware inventory match the physical unit
  • raw evidence is stored internally and public text is sanitized

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.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

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