H3C F100 power supply failed: Diagnose & Fix
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
| 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. |
Across years of operating H3C 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 Comware 7 the recovery path is the same whether the affected unit is from the F100 family or something newer.
Before you touch anything, capture state. `display version` and `display environment` dumped to a file is worth more than a screen-cap because H3C 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 H3C 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
Diagnose and recover from power supply failed on a H3C F100.
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.
Related guides
Related fixes
Related guides worth a look while you sort this one out:
- H3C F1030 power supply failed: Diagnose & Fix
- H3C F5000-A power supply failed: Diagnose & Fix
- H3C F5060 power supply failed: Diagnose & Fix
- H3C MSR2630 power supply failed: Diagnose & Fix
- H3C MSR3640 power supply failed: Diagnose & Fix
- H3C MSR3660 power supply failed: Diagnose & Fix
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.
Why this matters for your day-to-day
A H3C 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 H3C device fix goes cleanly:
- Latest firmware downloaded if you're going to update.
- Warranty + support contract status checked, opening sealed parts may void it.
- Backup of current configuration (where applicable) taken.
- Spare parts on hand if you anticipate replacement.
- Adequate workspace, lighting, and time: rushing causes regressions.
How to confirm it's actually fixed
On a H3C device, the test is rarely "reboot and see". Use this list:
- Active reproduction: trigger the original failure path on purpose.
- Indirect reproduction: do an activity that would expose the same subsystem.
- Status indicator review: every LED / display / app status should be green.
- 24-hour soak: leave the device under normal load overnight; check the next morning.
- Telemetry check: review the device or app's diagnostic log for new error entries.
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.
More frequently asked questions
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.
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.
What if the fix returns after a reboot?
Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).
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.
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.
Topology deep dive
Last quarter I rebuilt the perimeter for a BFSI captive ISP customer on a pair of H3C F100 firewalls at the BSNL branch perimeter, Hyderabad Hitech City. 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 f100 power supply failed: diagnose & fix on an H3C F100 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 F100 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 F100 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 F100 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 F100 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 F100 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 f100 power supply failed: diagnose & fix, the H3C F100 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 F100 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 F100 (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/f100-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 F100 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 F100 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 F100 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.05 lakh figure above is the annualised support renewal for a single F100 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 F100 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 F100 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 BSNL branch perimeter, Hyderabad Hitech City I work with mostly does an Ethernet handoff with VLAN tag, and the F100 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 F100 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 F100 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 F100 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 F100 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 F100 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 F100, 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 F100 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.