The call came in at 5:43am. “The routers are acting up again down at 1313 Packetloss Lane” the night supervisor whispered, as if afraid the devices might hear her.
“It’s… flickering. The network’s hanging in there, but people keep reporting ghost pings and strange device behaviour.”
This is the bane of my existence – another cursed asset.
I grabbed the essentials: laptop, EM Packet Field Meter (Spectrum Analyser), Ecto-Sniffer 3000 (Network Packet Sniffer), Ectoplasmic Residue Collector (Dust Buster for equipment cleaning), cable tester and, just in case an emergency really arises, a smudge stick of white sage.
Experience has taught me that in the field of network engineering there are problems you can diagnose, problems you can escalate and problems that make you wish you’d brought a priest. This is where a good Possession Alert System (Real-Time Alerting Dashboard on your AIOps platform) comes in handy!
The server room was cold – standard air-con chill, not supernatural frost… or was it? But something was off. LED indicators pulsed in non-standard rhythms and the router logs showed inexplicable reboots timestamped at 06:66 exactly – always 06:66. And clearly, that’s not even a possible timestamp!
For those without a networking sixth sense (technically speaking), this was likely a firmware bug or a dodgy PSU. But on a deeper level I recognised the signs. Every network technician eventually encounters a cursed asset. That piece of infrastructure that defies logic, drains hours, triggers repeated call-outs at the most inopportune times and spreads outages like a digital contagion.
It might not show up on SNMP traps or get flagged by the NOC’s dashboards. Yet its impact ripples outward – zombie processes, orphaned sessions, phantom alarms. Like some ghostly presence, it haunts not just the device but your whole stack and gets your whole service management team stressed out!
The average technician’s toolkit already looks suspiciously like that of a techno-occultist:
Incantations = CLI commands – tick
Divination = packet capture – tick
Exorcisms = factory resets – tick
Warding sigils = firewall rules – tick
When facing a cursed devices, I follow a five-step ritual:
Identification – Isolate the asset. Confirm its sins through log files and localised outages
Appeasement – Reboot, reconfigure or roll back firmware. Offer it one last chance at redemption
Containment – Segment it from the rest of the network. No need to let evil propagate and infect
Exorcism – Full wipe. Remove all state. Purge it with known-good configs and firmware
Replacement – If it still resists? Decommission it, stab its ungodly heart with a sabre of pure silver and burn the serial number from your memory (and CMDB)
Is this procedure in the ITIL playbook? No, but I have submitted it to Axelos as practitioner feedback more than once. They do only seem to treat me as a whacko though (probably rightly so!).
While we joke about ghostly glitches, cursed assets are often just the physical manifestation of weak infrastructure hygiene:
When you look at that checklist above, clearly modern OSS tooling can help. Solutions like next-gen AIOps / Observability platforms with advanced anomaly detection are our infrared goggles in the dark, helping us spot patterns in the network that would otherwise go unnoticed. Platforms that unify observability – tracking everything from power draw to packet paths and power / building / environment systems – can reveal that the “ghost” is really a firmware race condition or a heat issue when ambient temp exceeds a certain temperature. Advanced asset management capabilities allow you to spot patterns of deterioration.
Still, there’s something to be said for field intuition. A seasoned tech can walk into a room and feel when something is off. Sometimes the cursed asset detection software just confirms what you already knew in your gut.
Over the years of network exorcisms, I’ve learned a few truths:
In the end, this job is as much about faith as it is about logic. Faith in protocols, in packet paths and in your own instincts when logic fails. We work in a world where the “logical” – data, software, intent – is not always logical and controls the physical. Sometimes things go wrong in ways we can’t immediately explain.
That’s when you light the sage, run the diagnostics and remember:
Every haunted router was once a pristine, innocent device
It’s not cursed. It’s simply seeking a path to a stress-free afterlife.
Hat-tip to Dan for the seed of the idea for this post! His concept of cursed HVAC equipment chilled me to my bones! Glad I don’t work in network ops these days!!
Making your OSS easy to use isn’t about adding more “easyness” – it’s about subtracting what sucks. “To make your stuff “easier to use” you
During my first forays into OSS, over a period of 6+ years, I averaged 85 hours a week whilst being paid for a 40 hour
Telco appears to be an increasingly tough industry. Demand for connectivity continues to soar, yet profitability and differentiation are becoming ever more difficult to achieve.
I know a guy. One of my great friends actually. We’ve known each other since kindergarten – back when we were five years old. He
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
