HowToFixMe
Hardware Failure

HPE Aruba 6300 won't boot at all: Diagnose & Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
VendorHPE Aruba
Operating systemArubaOS-CX
CategoryHardware Failure
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need Aruba TAC + RMA.

Across years of operating HPE Aruba gear I have watched the same hardware-failure pattern repeat: a unit ships fine, runs for two years, then trips on a power-event or a thermal excursion. On ArubaOS-CX the recovery path is the same whether the affected unit is from the 6300 family or something newer.

Before you touch anything, capture state. `show version` and `show environment` dumped to a file is worth more than a screen-cap because Aruba TAC will ask for the exact output when you open the case. Keep the artifact even if the box recovers on its own.

Below I walk through the on-box steps first, then the Aruba TAC escalation path. If you have spares on hand, swap-then-diagnose is usually faster than diagnose-then-swap. but only if you can afford the rack time.

What this guide covers

Real-world context. Last time I walked through this on a real machine, the budget shook out to ~Rs 0 INR under HPE Care Pack, otherwise ~Rs 3,000 to Rs 50,000 INR for parts (around $36 to $600 USD). Plan for ~20 to 60 minutes hands-on actually at the keyboard, and ~1 to 4 hours including iLO log review once you factor in the back-and-forth. Keep the server serial, an iLO export, and the latest firmware bundle within arm’s reach before you start, stopping mid-step to hunt for them is how a 30-minute job turns into an afternoon.

Diagnose and recover from won't boot at all on a HPE Aruba 6300.

Step-by-step

  1. Confirm power: PSU LED is green? Cable seated? Wall outlet live?
  2. Try a known-good power cable + outlet.
  3. If the device has multiple PSUs, try with only one PSU at a time.
  4. Connect the console cable and watch for ANY output during power-on.
  5. If completely dark (no LEDs, no console), suspect the PSU or motherboard.
  6. Confirm warranty status, open a Aruba TAC case, prepare for an RMA.

CLI / commands

# Verify hardware state
show version
show system
show environment

# Collect for Aruba TAC
show tech | redirect-to-file /tech.txt

When to RMA

Frequently asked questions

Will this work on my specific ArubaOS-CX version?

The procedure reflects current ArubaOS-CX behaviour. Older releases may need minor syntax adjustments: use the CLI help (? or tab-completion) to verify.

Should I open a Aruba TAC case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the HPE Aruba official documentation?

https://community.arubanetworks.com/, search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate against your specific ArubaOS-CX version and test in a non-production environment before applying.

Common patterns we see

When this symptom shows up on a HPE device, three patterns repeat:

1. Recent firmware update changed behavior. the symptom started within a week of an OTA push. Rollback or wait for the hotfix. 2. Environmental trigger, temperature, humidity, line voltage, network changes. Look at what changed in the environment. 3. Cumulative wear: components like batteries, gaskets, fans degrade over time. Replace the consumable rather than chasing a software fix.

Knowing which pattern applies saves time on the wrong fix.

Before you start

A few things to confirm so the HPE device fix goes cleanly:

How to confirm it's actually fixed

On a HPE device, the test is rarely "reboot and see". Use this list:

When to call HPE support instead

Escalate if:

More frequently asked questions

How long does this fix usually take?

Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.

Why is this happening on a brand-new unit?

Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

Is it safe to apply during business hours?

If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

Topology deep dive: where the 6300 sits in a real rack

On the deployments I run out of a Bengaluru colo, the HPE Aruba 6300 almost never lives alone. It sits as an access or aggregation layer inside a VSF (Virtual Switching Framework) pair, with two members wired back-to-back over 10G or 25G stacking links and uplinked north to a CX 8325 or 8360 spine. When the 6300 misbehaves, the first question I ask is never "is the switch broken" but "which member of the fabric is broken, and is the conductor still elected." A VSF split-brain looks exactly like a dead switch to the help desk, and it is a very different fix.

Map the physical layout before you touch a command. Member-1 in the bottom of the rack, member-2 two RU up, dual PSUs each fed from an A-feed and a B-feed PDU. In a BFSI data centre that A/B feed separation is not optional. it is what keeps the access layer alive when one UPS bus drops during a generator changeover. I have seen a whole trading-floor access stack go dark because both PSUs on a 6300 were lazily patched into the same rack PDU. The switch was fine. The wiring discipline was not.

Run show vsf and note the conductor, standby, and member roles. Note the link state on show vsf link. If one stacking link is down you are running on a single path, and any flap there triggers exactly the reload-loop and member-missing symptoms people panic about. Write the topology down. A two-line diagram saves twenty minutes when the TAC engineer asks you to describe the fabric.

Configuration walkthrough that survives a reload

Half the 6300 cases I get pulled into are not hardware at all. They are a config that was never committed, or one that drifted between the conductor and a member after an out-of-band edit. ArubaOS-CX uses a checkpoint-and-commit model, and people coming from old ProCurve or Cisco IOS habits forget it. Make a checkpoint before any change:

copy running-config checkpoint pre-change-2026
show checkpoint
checkpoint auto 10
copy running-config startup-config

The checkpoint auto 10 line is the one that has saved my evenings more than once. It auto-rolls back if you do not confirm the change within ten minutes, so a fat-fingered VLAN prune on a remote 6300 undoes itself instead of leaving you locked out and driving to the site. After any real change, show running-config against your golden template and diff it. I keep golden configs per-site in a Git repo so a rebuild after an RMA is a paste, not an archaeology project.

For VSF members specifically, confirm the vsf member 2 type and link assignment match the surviving member before you bring a replacement online. A type mismatch is the single most common reason a swapped-in 6300 refuses to join the fabric and shows up as a missing member.

Troubleshooting commands by platform state

ArubaOS-CX hides most of its truth in the service OS and the boot history, not the friendly show output. When a 6300 is cranky, walk this ladder in order. Each rung tells you whether to keep going on-box or to raise a TAC case.

# Is it a thermal trip masquerading as a crash?
show environment temperature
show environment fan
# Look for "OVER_TEMP" or a fan tray reading 0 RPM

# Is a member self-resetting?
show boot-history all
# "Reboot Cause: Hardware reset" vs "User reboot" changes everything

# Did the image fail verification on the last load?
show images
diag utilities boot-history

# Capture once, attach once
show tech > /tmp/tech-6300.txt
show core-dump

The codes that actually show up on a 6300: OVER_TEMP on the environment readout when a Bengaluru CRAC unit trips and the cold aisle climbs past 45C; PSU_FAULT / PSU_INPUT_FAULT when a B-feed PDU drops; and the dreaded Reboot Cause: Kernel Panic in the boot history, which is the line that converts a "let me reload it" into "let me open a TAC case." Do not clear the core dump before TAC pulls it. I have watched an RMA get denied because someone wiped the only crash artefact that proved the fault.

More commands worth keeping in the runbook

The block below is the one I paste into every 6300 runbook. Capture it once at a known-good state so you have a baseline to diff against when something drifts.

# ArubaOS-CX operational state on the 6300
show version
show system
show module
show environment temperature
show environment fan
show environment power-supply
show led-locator

# Stacking / VSF fabric health (6300/6400 VSF, 6200F front-plane)
show vsf
show vsf detail
show vsf link

# Boot and image state
show boot-history
show images

# Logs and crash artefacts for HPE Aruba TAC
show logging -r
show core-dump
show tech > /tmp/tech.txt

India deployment and compliance notes

Procurement reality first. A 6300 refresh for a public-sector or BFSI buyer almost always lands through a GeM tender or a BoQ-driven RFP, and the HPE Care Pack / Aruba Foundation Care line item is where the long-term money sits. Budget roughly INR 85,000 to INR 2,00,000 (about $1,000 to $2,400 USD) per year for next-business-day foundation care on a chassis-class 6300, and read the SLA fine print. "NBD" in a Tier-2 town is not the same NBD you get inside the Mumbai or Bengaluru metro, where HPE keeps spares depots. For a colo at NSE/BSE or a bank DR site, I push the buyer toward 4-hour onsite even though it costs more, because a dead access stack on a trading floor is measured in lakhs per minute, not in switch price.

On the compliance side, MeitY and the DPDP Act push two habits onto every switch I commission. First, logging has to go off-box to a hardened syslog or SIEM collector so the audit trail survives a device wipe. configure logging 10.20.0.5 vrf mgmt and prove it lands. Second, the management plane must be segregated: keep the 6300 OOBM port in a dedicated mgmt VRF, never the default VRF, and gate it behind the MeitY-cleared jump host. For BFSI clients the RBI cyber-security framework also wants firmware currency evidence, so keep the show version and the upgrade ticket together. an auditor will ask for both.

A 6300 fault I worked through last quarter

Three months ago I got a 2 a.m. call from a Hyderabad data-centre tech: one member of a 6300 VSF pair was "dead." It was not. show vsf from the surviving member showed the second unit cycling between Booting and Hardware reset in show boot-history. The cold aisle had crept up because one CRAC compressor had tripped, and the 6300 had hit OVER_TEMP and was protecting itself with repeated reloads. We did not RMA anything. We restored airflow, watched show environment temperature drop back under threshold, and the member rejoined the fabric on its own inside four minutes. Total cost: zero, because nothing was broken except the room. I logged the temperature curve in the maintenance record, because the next time someone blames the switch I want the receipt. Hardware-failure symptoms and environment faults wear the same mask. always check the room before you blame the box.

Extended FAQs

How do I tell a real 6300 hardware fault from a VSF fabric issue?

Run show vsf from a member that is up. If the fabric reports a missing or rebooting member but the member's own console shows clean POST, it is a stacking-link or role-election problem, not a dead board. Genuine hardware death gives you a dark unit with no console output at all.

Will swapping in a spare 6300 keep my config?

Only if you restore startup-config to it or let VSF push the member config from the conductor. A bare replacement boots with factory defaults. Keep a golden config per site and verify the vsf member type matches before you cable the stacking links.

Does opening the chassis void HPE Aruba support?

Field-replaceable units (PSUs, fan trays) are designed to be swapped without voiding Foundation Care. Cracking sealed boards or the management module is not, and an RMA can be refused if there is evidence of unauthorised entry. When in doubt, let TAC drive the swap.

What firmware train should a BFSI 6300 sit on?

Stay on the latest ArubaOS-CX LTS for production, not the bleeding-edge feature release. Auditors want a supported, patched train with a clear advisory record, and LTS gives you that without the churn of monthly feature builds.