HowToFixMe
Hardware Failure

HPE Aruba ClearPass Policy Manager smoke smell or burned PCB: 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.

A HPE Aruba platform behaving badly is usually one of three things: a thermal/PSU issue caught by `show environment`, a transceiver problem caught by `show interface 1/1/1`, or a boot-loader hang you only see on the console. ArubaOS-CX surfaces all three differently from competitors, so the diagnostic order matters.

I will be honest: on the ClearPass Policy Manager family I have seen at least one false-positive from the on-box monitoring per quarter. Always cross-check what `show version` and `show environment` reports against the physical front-panel and a smell test of the chassis.

If this is your first HPE Aruba hardware issue, the good news is that Aruba TAC is competent and the part-replacement RMA cycle is usually under a week for a covered unit.

What this guide covers

Diagnose and recover from smoke smell or burned PCB on a HPE Aruba ClearPass Policy Manager.

Step-by-step

  1. STOP. Power off the device at the wall before touching it.
  2. Open the chassis and identify which board / module is the source of the smell.
  3. Photograph the visible damage (scorched capacitors, blackened ICs).
  4. Note the device serial number and exact model for the support case.
  5. Do not power back on, burned components fail closed and can damage adjacent boards.
  6. Open a Aruba TAC case with the photos and serial.
  7. RMA the affected component (line card, supervisor, PSU) or the full chassis if the backplane is damaged.

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.

Why this matters for your day-to-day

A HPE device that's misbehaving costs more than the fix itself: lost productivity, missed calls, security risk, even safety risk in some categories. Treating the symptom quickly with a documented procedure is cheaper than letting it persist. The steps above are written to get you back to working in under an hour where possible, and to flag clearly when escalation is the right call.

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

Are there safer alternatives for non-technical users?

Yes. the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

Should I update firmware first or last?

Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.

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.

How often should I run preventive checks?

Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.

Will this void my warranty?

Applying official firmware updates and following the user manual will not affect warranty. Opening sealed components, jumping safety circuits, or using third-party parts can void warranty in most jurisdictions.

Topology deep dive: where this box sits

The ClearPass Policy Manager I deploy is almost never a single box. It is a cluster of a publisher and two or three subscribers, usually one publisher in the Bengaluru primary DC and a standby subscriber in the Chennai DR site. RADIUS and TACACS+ requests hit a virtual IP fronted by the cluster, so a single-node fault should be survivable. Should be. The config database replicates from the publisher down, which means a publisher problem is an outage and a subscriber problem is a capacity hit. Know which node you are staring at before you reboot it.

I draw the auth path on a whiteboard for every new ClearPass install: switch or controller as the NAS, the VIP, the cluster node that actually answers, then the AD domain controllers and any external SQL or LDAP source. When 802.1X breaks, the fault is usually three hops away from where the alarm fires. The node that logs the RADIUS reject is often healthy; the AD join or the certificate behind it is what died.

Configuration walkthrough

Before I change anything I snapshot the running state so I have a rollback point. On the ClearPass Policy Manager that means copying the running-config off the box and exporting a fresh support bundle. I have been burned once by fixing a symptom and creating a worse one with no record of the original state. Now the snapshot is non-negotiable. Capture first, change second, verify third.

# Snapshot before you touch anything
copy running-config tftp://10.20.0.5/pre-change.cfg vrf mgmt
show running-config
# Confirm the change took and nothing else regressed
show interface brief
show log event | last 50

When the fault is routing, I resist the urge to clear the whole table. A hard clear bgp * on a production edge can black-hole a region for the reconvergence window. Soft-reconfigure inbound, check the specific neighbour, and only bounce the session if the soft path proves the policy is the problem. Patience here is cheaper than an incident review.

Troubleshooting commands for this platform

These are the commands I actually run, in the order I run them, when I am standing in front of a ClearPass Policy Manager that is misbehaving. Collect first, interpret second.

# ClearPass CLI (appadmin shell)
system show-version
system status
network ip
service list
# Health from Policy Manager UI:
# Monitoring > Live Monitoring > System Monitor
ad netjoin status
cluster list

India compliance and deployment notes

Procurement and compliance shape how I handle these boxes in India more than people expect. A ClearPass Policy Manager bought through a GeM tender or a reseller like Redington or Ingram Micro ships with a HPE Care Pack or a Foundation Care SLA, and the renewal line item is where budgets quietly die. A typical support renewal runs anywhere from Rs 85,000 to Rs 2 lakh (roughly $1,000 to $2,400 USD) per chassis-year depending on the response tier, and the 4-hour onsite tier costs noticeably more than next-business-day. For a BFSI client I always price the 4-hour tier into the BoQ because a trading-floor switch with NBD support is a governance finding waiting to happen.

On the compliance side, MeitY and RBI data-localisation expectations push a lot of this gear into India-resident data centres, and the DPDP Act now adds real weight to keeping auth and access logs inside the country. When I export a support bundle to send to HPE, I scrub or confirm there is no resident personal data leaving the boundary, because a diagnostic dump can carry usernames, MAC bindings, and IP allocations. For regulated clients I do the upload through an India-region case portal and note it in the change ticket. The auditors ask. Have the answer ready.

A real-world deployment I did

Last quarter I got pulled into a Chennai DR incident on a ClearPass Policy Manager that the night team had already half-fixed and made worse. The symptom they reported and the symptom I found were not the same thing, which is normal. I started where I always start: capture state, read the reset reason, diff the running config against the snapshot in our config repo. The diff told the story in about ninety seconds. Someone had pushed an emergency change at 1 a.m. without a ticket, and the rollback they thought they did never committed. I reverted to the repo copy, confirmed the neighbours and interfaces came back clean, and left the box stable. Total hands-on time was under twenty minutes once I stopped guessing and started reading. The lesson I keep relearning: the box almost always tells you what happened if you collect the evidence before you start changing things.

Extended FAQs

How long should a clean recovery actually take on this platform?

For a software-path fix on the ClearPass Policy Manager, plan 20 to 60 minutes hands-on plus a maintenance window for any reboot. A hardware RMA path is dominated by logistics, not labour: the swap is ten minutes, the courier and the Care Pack dispatch are the long pole.

Do I need to involve HPE TAC, or can I close this myself?

If the box recovers after a captured, documented change and stays stable through a 24-hour soak, close it yourself and file the evidence. Open a case the moment you suspect a hardware fault, a crashinfo with no software workaround, or a repeat failure after a clean fix. Confirm your entitlement is active before you call.

What is the one artefact I should always grab first?

The support or tech-support bundle. It freezes the state TAC will ask for and protects you if a later change muddies the evidence. Grab it even when the box looks healthy.

Will any of this differ on a different ArubaOS-CX or appliance build?

Command syntax drifts across major releases. Lean on tab-completion and the in-line ? help to confirm the exact form on your build before you paste a command into production.