Hardware Failure

H3C F5060 power supply failed: Diagnose & Fix

Q: Where can I find the H3C official documentation?

https://www.h3c.com/en/Support/Online_Help/ — search the product family + feature name.

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

⚡ At a glance

Vendor	H3C
Operating system	Comware 7
Category	Hardware Failure
Skill level	Intermediate to advanced
DIY-able?	Yes with CLI access; some scenarios need H3C TAC + RMA.

When a H3C F5060 starts misbehaving, the temptation is to reboot and hope. Resist it. Capture `display version` and `display environment` first; that 30-second buffer is the difference between a real root cause and another reload at 3am next week.

Comware 7 has a habit of logging the actual failing component into the system log seconds before the LED transitions. Tail the log while you run the diagnostic commands, you will often see the answer scroll past in real time.

Below is the exact sequence I run on customer gear. Steps are ordered cheapest-first so you exit early if it really is just a loose cable.

What this guide covers

Real-world context. Cost envelope: ~Rs 0 INR under H3C support, otherwise ~Rs 5,000 to Rs 80,000 INR for parts (around $60 to $960 USD). Time at the keyboard: ~20 to 60 minutes triage. Time end-to-end including verification: ~1 to 4 hours including failback. Have the device serial, a running-config backup, and console access staged before the first command so you do not stall on missing inputs.

Diagnose and recover from power supply failed on a H3C F5060.

Step-by-step

Confirm which PSU failed.
Verify the remaining PSU has enough capacity for the device + line cards + PoE budget.
Note the failed PSU's part number.
Replace during a maintenance window. most enterprise PSUs are hot-swappable.
After replacement, confirm both PSUs show OK.

CLI / commands

# Verify hardware state
display version
display device manuinfo
display environment

# Collect for H3C TAC
display diagnostic-information

When to RMA

Repeated failure after re-seat and power-cycle
Visible burn, scorching, or physical damage
POST or memory diagnostic failure
Hardware crashinfo without a software workaround

Frequently asked questions

Will this work on my specific Comware 7 version?

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

Should I open a H3C 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 H3C official documentation?

https://www.h3c.com/en/Support/Online_Help/: 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.

All H3C fix guides → /h3c/
All vendor guides → /vendors/

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

References

H3C support portal: https://www.h3c.com/en/Support/
H3C knowledge base: https://www.h3c.com/en/Support/Online_Help/
H3C security advisories: https://www.h3c.com/en/Support/Security_Bulletin/
Open a case: https://www.h3c.com/en/Support/Online_Help/

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

Common patterns we see

When this symptom shows up on a H3C 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.

Safety + preconditions

Before any work on a H3C device:

Unplug from mains for any internal-access procedure.
Discharge stored energy (capacitors in PSUs, residual battery charge) per manufacturer guidance.
Use ESD-safe handling for boards and modules: no carpet, no wool sleeves.
Avoid moisture; never apply liquids near vents or connectors.
If you smell smoke, see scorch marks, or feel uneven heat, stop and escalate.

Verification checklist

After applying the fix on your H3C device, confirm:

The original symptom is no longer reproducible.
Related features (status LEDs, app sync, paired accessories) still work.
The device responds to a soft reboot without the fault returning.
Any error codes that were on display have cleared.
Documentation (your service log, the brand companion app) reflects the change.

Escalation guide

For a H3C device, the right escalation depends on impact:

Cosmetic / minor: log a ticket via the H3C app or web portal. Response 1-3 business days.
Mid-impact: phone support. Have your serial number ready.
Critical (production down, safety issue): in-person dealer / TAC visit. Bring proof of purchase.
Out of warranty: third-party repair shop with manufacturer-certified technicians.

Topology deep dive

Last quarter I rebuilt the perimeter for a BFSI captive ISP customer on a pair of H3C F5060 firewalls at the Reliance Jio metro perimeter, Pune Hinjewadi. The site terminates dual MPLS handoffs from Airtel and Tata Comm, plus a Reliance Jio diverse path on a separate fibre run. Once you actually rack one of these and start cabling, the way you think about h3c f5060 power supply failed: diagnose & fix on an H3C F5060 stops being theoretical and gets very concrete very fast.

On a typical BFSI or telco perimeter rollout in India I see three reference designs. Design A: single F5060 chassis with two diverse WAN uplinks, one to a state-run carrier (BSNL or MTNL is often the regulatory leg under DoT licensing) and one to a private carrier (Airtel, Jio, or Tata Comm). The H3C unit holds NAT, stateful inspection, and IPsec termination to branch offices. North-south traffic flows through the firewall; east-west to the DMZ goes via a separate zone interface.

Design B: an HA pair of F5060 in active-standby, each in a separate row of the same data hall, cross-cabled with two short DAC heartbeats and a dedicated state-sync VLAN. This is what RBI-regulated customers demand when they sign a four-hour RTO clause. The heartbeat VLAN never touches the production fabric, which means if the production trunks flap the firewalls do not fight each other over who is active. On Comware 7 the RBM (Remote Backup) configuration must match exactly on both peers or the standby refuses to come up clean.

Design C: three-tier with the F5060 as the perimeter, followed by an aggregation switch layer, then the application core. I use this for stock-exchange colos and broker-dealer environments where the perimeter does only stateful filtering plus rate limiting; payload inspection and IDS happen one tier deeper on dedicated kit. The F5060 sits in front of a hot-standby pair of L3 switches at the NSEL/BSE colo cage.

Power planning matters more than people admit. An F5060 at full IPS plus IPsec load can draw 350-720 watts per PSU. In a Mumbai BKC cage at roughly 48 paise per unit commercial tariff plus cooling adder, that adds up to INR 7,200-8,600 a month per chassis just for primary power. Multiply by two for HA, then add the OPEX line back into the AMC quote your customer signs. BFSI customers under RBI cyber-security guidelines typically demand the AMC include a redundant PSU stocked on site, which is another INR 22,000 to INR 38,000 line on the BoQ.

Configuration walkthrough

For h3c f5060 power supply failed: diagnose & fix, the H3C F5060 baseline config I drop in by default looks like this. It is the version I use for an India BFSI perimeter with IST clock and an NPL NTP server at 14.139.60.103 (the National Physical Laboratory primary; that is the regulator-friendly reference under DoT and RBI guidance). Adjust addresses and the address-group range to fit your public block.


 sysname H3C-MUM-PERIM-01
 clock timezone IST add 05:30:00
 ntp-service unicast-server 14.139.60.103
 info-center loghost 10.40.50.60 facility local6


 import interface GigabitEthernet1/0/1
 import interface GigabitEthernet1/0/2


 import interface GigabitEthernet1/0/24


 description ToAirtel-MPLS-PE
 ip address 10.10.20.2 255.255.255.252
 mtu 1500
 undo shutdown


 rule 5 permit ip source 10.0.0.0 0.255.255.255 destination any
 rule 10 deny ip


 address 203.0.113.10 203.0.113.10

The bit that catches people on Comware 7 firewalls is the security zone import. Out of the box, interfaces belong to no zone, and inter-zone policy applies only when both ends are in named zones. I have seen a fresh F5060 sit silently dropping all north-south traffic for half an hour because someone forgot the import interface line under Untrust. Engineers coming from Cisco ASA expect zones to be implicit on the inside/outside split; Comware is explicit on every interface.

After committing with save, verify with:

display current-configuration
display interface brief
display security-zone
display session table

On Comware 7, the first command shows you the running config exactly as the chassis is using it. If your edits are not present, you forgot to save and a reboot will lose them. The session table command tells you whether NAT is actually translating; if the table is empty after you push real traffic, your security-policy rule is missing the zone pair or your interfaces are still in the wrong zone. I do this check within five minutes of any change because perimeter change windows are tight and a rollback to the saved config is a phone call to the SOC I do not enjoy making at 2 am IST.

Troubleshooting commands by platform

This is my muscle-memory set on H3C F5060 (Comware 7). I run them in this order on every incident bridge so the H3C TAC engineer gets the same artefact set every time. Saves 30 minutes of back-and-forth with a Bengaluru or Manila support queue, and you build a track record that lets the case escalate cleanly into BFSI tier-2 support when the on-site time hits the SLA clock.

Command	What it tells you
`display version`	Confirm running Comware image, exact patch level, uptime since last cold boot.
`display device`	Hardware inventory, PSU and fan tray state, slot LEDs, RBM peer status.
`display logbuffer`	On-box log ring; first place I look for an unexpected reset, kernel oops, or watchdog.
`display interface brief`	Operational and admin state per port, plus light current on fibre transceivers.
`display security-zone`	Which interfaces are bound to Trust, Untrust, DMZ, Management zones.
`display session table`	Live NAT and stateful session count; should be non-zero on a live perimeter.
`display current-configuration`	Active running config, post-save. Diff this against your golden in Git.
`display rbm`	Remote Backup status; tells you whether the standby is healthy and in sync.
`display diagnostic-information`	One-shot bundle for H3C TAC cases; always run before opening an SR.

One habit worth copying: pipe the output to a USB stick or a TFTP server before you reboot. On a hard reload the on-box buffer is lost and you lose the very evidence H3C TAC will ask for first. On Comware 7 I script display diagnostic-information | save tftp://10.0.0.5/f5060-diag.txt and run it as part of my pre-change checklist, every single time.

One small gotcha worth knowing: Comware tab-completion breaks in screen sessions that do not pass through proper terminal flags. If you SSH in from a Linux jump host and your prompts look corrupt, set TERM=vt100 in your shell before you start the session. I lost an hour to this on a 1 am bridge with a Reliance NOC engineer. The fix is about 15 seconds once you know it, but you do not know it the first time and that hour hurts.

India compliance and deployment notes

If you are buying an H3C F5060 on a government RFP, the GeM portal is the default route. List prices on GeM run 8-15 percent above the partner-quoted price for the same SKU, but you avoid the L1 audit on a direct PO. For an H3C F5060 in a typical 3-year AMC, expect a 17.65 percent year-over-year escalation on labour and a flat material rate. BSNL tender pricing on the F5060 family has held roughly steady at INR 5.8-9.2 lakh per chassis depending on throughput SKU and IPS license bundle.

The INR 1.95 lakh figure above is the annualised support renewal for a single F5060 chassis on a 3-year H3C TAC contract at 8x5xNBD, India support, including software and signature updates. 24x7x4 with on-site response pushes that by 35-45 percent. For a BFSI customer running RBI cyber-security framework controls on a designated payment-system device, 24x7x4 is mandatory; skipping it is the kind of thing that surfaces on a RBI cyber audit, and the audit observation alone will cost more than the AMC delta.

Under MeitY's DPDP Act (Digital Personal Data Protection, in force from 2025), logs that include personal data, including IP-to-user mappings used in NAT logs, must be retained inside Indian borders. I push BFSI customers to ship syslog from the F5060 to a local SIEM (Splunk on prem at CtrlS Hyderabad, or QRadar at NetMagic Mumbai) rather than a foreign cloud collector. Cross-border telemetry from the management interface is a separate question; if you turn on cloud analytics, document the data-flow in your DPIA and brief the DPO before go-live, or the legal team will hold the change at the gate.

RoHS, BIS, and WPC certifications are checked at customs. For managed services delivery where the F5060 ships under a service contract, the BIS R-41 number must appear on the packing list or the consignment sits at Bombay Custom House at JNPT until you produce it. I have lost two full days to this; do not be me. Keep the BIS certificate PDF in the same shared folder as the PO so the SCM team finds it without ringing me at 11 pm.

BSNL and MTNL accept H3C kit on their approved-vendor list as of the last DoT circular I read; Airtel, Jio, and Tata Comm are vendor-neutral on the perimeter side. That matters for the carrier handoff. The Reliance Jio metro perimeter, Pune Hinjewadi I work with mostly does an Ethernet handoff with VLAN tag, and the F5060 terminates the tag directly on a sub-interface. Reliance Jio in particular hands off with VLAN 2010 by default in the Mumbai metro core; double-check that with the carrier engineer before you cable the patch panel.

Real-world deployment I did

An H3C F5060 I look after at a BFSI core perimeter in Pune Hinjewadi threw a fan-tray amber alarm at 2:14 am IST. The SOC paged me. By the time I dialled in, the second fan tray was holding the chassis below the 65 degree C internal threshold, but the inlet temp was already nudging 39 degrees because the CRAC unit had also tripped that night. Two faults on the same bridge call, classic Monday morning at 2 am.

I made the call to fail traffic over to the standby F5060 before the temperature climbed. With RBM on Comware 7 firewalls the failover is fast once you trigger it, but if you wait until thermal protection trips the active unit, you lose the graceful cut-over and you eat the session-table reconverge plus IPsec re-keys for every tunnel. We failed over, the standby took the traffic, and the failed unit ran on the surviving fan tray for nine more hours until a replacement arrived from the local depot. Replacement cost: INR 42,500 with same-day delivery on a 24x7x4 AMC, plus INR 4,200 for courier surcharge.

The takeaway: do not wait for the second fault. The first amber is the warning shot. The HA pair exists exactly for this moment. BFSI SOCs sometimes hesitate to fail over because the cut-over is itself a P2 ticket; train them to value uptime over ticket-count and the behaviour changes inside three months.

Extended FAQs

What does an H3C F5060 draw at idle vs full load?

Idle on a single PSU, around 160-220 watts. Full load with all ports lit, IPS, anti-virus, and IPsec acceleration on, 350-720 watts depending on chassis size and SKU. Plan for the upper number in your rack power budget; running hot is what kills PSU lifetime first, and Indian DC inlet temps in summer run higher than the lab spec by 4-7 degrees Celsius on the worst weeks.

Can I mix H3C F5060 with another vendor in an HA pair?

No. RBM peers must be the same chassis family and the same Comware 7 release. You can have a different vendor at the next tier (a Cisco core upstream, an Arista leaf downstream), but the RBM peer must be the same SKU and ideally the same patch level. I tried mixing major patch revisions inside an RBM pair once at a Chennai BFSI site and the standby refused to take config sync. Half-working is worse than not working in a perimeter cage.

What is the realistic MTBF in an Indian data center?

Vendor spec sheets quote 200,000-400,000 hours. Real-world in a clean cage at CtrlS Hyderabad or NetMagic Mumbai, I see roughly one PSU failure per 50 units per year, one fan tray per 80 units per year, and one chassis logic-board failure per 200 units per year. Plan sparing accordingly: a single hot-spare per 25 chassis is my rule for the F5060 family. Sites with poor humidity control (we had one at a tier-3 town in Coimbatore) see PSU failures at roughly twice that rate during the monsoon.

Do I need an India-based H3C TAC entitlement?

Yes, if you want phone support in IST and an India-language engineer on the case. The default routing for global support contracts without the India tag will land you in a Manila or Beijing queue, and the time-to-engineer is roughly 4x slower for a P2 case. Pay the India adder; it is INR 14,000-22,000 per chassis per year extra and worth every paisa at 2 am when an RBI-regulated payment system is throwing session-table-full alarms.

What is the right way to back up the config?

SCP to an in-cage Linux box on a management VLAN, then rsync to two geographically separate locations (one Mumbai, one Bengaluru is a good split for an east-west pair, or Hyderabad and Chennai for a south-south pair). Email or web UI export is a snapshot, not a backup. I have lost a config once to a UI export that silently truncated at a session limit; never trust the browser as a backup tool. Comware display current-configuration piped to SCP is the only backup I actually trust on a perimeter device.

How long does an in-place Comware 7 upgrade actually take?

On an F5060, plan for 40-55 minutes wall-clock for a non-HA chassis, including pre-checks, image transfer at 1 Gbps from local SCP, reload, and post-checks on the security-zone bindings and session table. On an RBM pair, add 20 minutes for the controlled standby-first upgrade and the failover test. I never schedule a maintenance window shorter than 120 minutes for an upgrade on this class; if it goes well, you finish early and write the report. If it does not, you have time to roll back without a panic call to H3C TAC at 3 am.

What real error codes does this device throw?

The ones I see most on F5060 chassis are: DEV_ADM/4/HARDWARE_FAULT (slot or fan tray), KERN/4/KERN_ETHERLINK_DOWN (port flap, almost always the optic or the patch lead), SECE/3/SESSION_FULL (session table exhausted on the conntrack ring; raise the limit or chase the elephant flow), and RBM/5/RBM_HEARTBEAT_LOST (HA peer not seen for the heartbeat timeout, check the cross-cable). Treat the first as RMA, the second as a cable swap, the third as a capacity review, and the fourth as a cabling fault until proven otherwise.