The Anomaly That Wouldn’t Go Away
The client’s site had been upgraded from LTE to a fibre link several months earlier. Standard carrier upgrade, standard handover process, standard expectation that everything would work correctly from day one.
Except our connectivity monitoring was showing packet loss that didn’t make sense. The fibre link should have been performing better than the old LTE connection, not worse. When we logged a ticket with the carrier, they came back and said they could see packet loss too, but they saw something different from what we were reporting.
That’s when things got interesting.
Following the Data Trail
Rather than accepting the carrier’s initial response, our team started pulling the documentation apart. The handover that accompanied the LTE upgrade contained the IP addresses and configuration details we needed to set up monitoring. Standard practice is to trust that documentation and configure your systems accordingly.
When we compared what was in the handover against what we were actually monitoring, the picture became clear. The gateway IP the carrier provided wasn’t the fibre link at all. It was the microwave service, which meant we had been monitoring the wrong circuit since the upgrade happened.
But that wasn’t the only problem. The service description in the handover still referenced the old LTE service that had been replaced. And the line tag, the unique identifier that should track the specific service, was also wrong. Three separate documentation errors in a single handover, each one pointing our monitoring at the wrong target.
Why Systematic Verification Matters
The carrier wasn’t being deliberately unhelpful. When our team logged the ticket referencing packet loss on the fibre, the carrier’s support team went looking for the fibre service using their internal records. They found packet loss too, but on a different service, because they were looking at the fibre circuit on the actual IP address and not the IP address that our monitoring had been misdirected to.
Everyone was looking at the wrong thing because the handover documentation was wrong from the start.
Once we obtained the correct IP address directly from the carrier’s technical team, we updated our monitoring configuration and aligned everything properly. The packet loss we had been chasing wasn’t only a fibre problem. There was an issue on both links.
The Billing Question
Monitoring configuration errors don’t just affect visibility. They affect accountability. When circuits aren’t being monitored correctly, performance issues go undetected, and billing discrepancies can accumulate over time.
After correcting the monitoring configuration, we conducted a full verification against the carrier’s billing to ensure the services we were paying for matched the services we were receiving. That kind of proactive monitoring and verification isn’t standard practice for most organisations, but it should be.
What This Means for Carrier Handovers
Every carrier handover should be treated as a document that needs verification, not a source of truth to be accepted without question. Configuration details, IP addresses, service descriptions, and line tags all need to be validated against the actual infrastructure before monitoring goes live.
The alternative is months of monitoring data that tells you nothing useful about the services you’re actually paying for.
Trust your monitoring data over carrier assurances. When the numbers don’t match the narrative, the documentation is usually the problem.
Is your organisation confident that your connectivity monitoring reflects your actual infrastructure? Let’s discuss your monitoring and verification approach.
