Fibre Network Operators (FNOs) in South Africa have a fundamental problem: their operational support is utterly dismal. 🚨 The process of troubleshooting a reported link issue is stuck in the dark ages, relying on outdated and inadequate methods. Instead of proper diagnostics and transparent reporting, customers are met with frustration, delays, and agents who seem more interested in ending the call than actually solving the problem.
Primitive Troubleshooting Techniques 🛠️
When an issue is reported, the first response from an FNO is usually a set of primitive, generic troubleshooting steps. Reboot your router, change your cable, reset your ONT. These steps are fine for a first-tier support script, but when a customer has already ruled out these basics, the lack of escalation to meaningful diagnostics is mind-numbing. Worse still, when faced with a customer who pushes back against their ineffective methods, FNO agents become defensive, precious even, sometimes threatening to terminate the call. Eish. 🤦♂️
The Core Problem | Testing on Idle vs. Testing on Load ⚖️
One of the biggest flaws in FNO diagnostics is that their tests are conducted when the link is idle.
A link might pass a simplistic connectivity check when no traffic is flowing.
Under real-world load, the performance could degrade significantly due to packet loss, latency spikes, or congestion issues.
This is the key differentiator between an effective diagnostic process and a useless one. Without testing under load, intermittent failures and performance drops go completely undetected. The FNO's approach is like testing a car’s brakes while the car is parked—it tells you nothing about how they perform when you actually need them. 🚗💨
The One-Way Testing Problem 🔄
FNOs are only capable of testing from their core network inward towards the ONT (Optical Network Terminal). They cannot test in the reverse direction—meaning they have no way of detecting uplink failures between the ONT and the fibre distribution point. If an uplink is down or intermittently failing, their tests will still return an “all clear” status.
Customers, however, experience the reality: packet loss, slow speeds, or total connectivity loss. This makes FNO testing unreliable at best and downright misleading at worst. 🕵️♂️
A Case Study in Frustration | The Lightning Strike Incident ⚡
Let’s talk about a real-world example. My home was klapped by a lightning strike. Vrek. The geyser was gone. Three network switches were gone. Everything electronic had taken a hit. Given that level of damage, it was completely reasonable to suspect the ONT had issues too.
I ran my own tests:
Every test confirmed intermittent failures on the ONT’s Ethernet port. The logical conclusion? The ONT was damaged.
So, I reported the issue. The response from the FNO?
“Please test with an alternative account overnight.”
Wait. What?! 🤯 How does an authentication test help diagnose an intermittent hardware failure? It was a complete waste of time, demonstrating a total lack of understanding of network troubleshooting.
Where’s the Evidence? 📉
A competent FNO would provide real diagnostic data:
Fibre light levels
ONT logs
Error counters
But no, they provide nothing. How the hell can we believe you when you don’t show us any evidence? Instead, customers are expected to take their word for it, even when all signs point to a hardware failure or a line issue.
Wrap | The Need for Professionalism 🚀
FNO support needs a serious overhaul. Customers should not have to battle through incompetence just to get a working service. A proper diagnostic process should:
Test links under load, not just when idle.
Provide transparent data—show fibre levels, ONT logs, and real evidence.
Be able to detect uplink failures, not just core-to-ONT issues.
Have competent agents who listen to the customer’s testing results rather than following a rigid script.
Until then, we remain stuck in an endless cycle of frustration, unnecessary delays, and pointless testing. FNOs, do better. 🏆
Update: An Openserve techie was dispatched. He replaced the Huawei ONT and the all connection issues were resolved. Interestingly enough he confirmed that the call centre has no ability to test through the ONT so has no ability to confirm Ethernet port problems!
