Every network engineer has a category of fault they quietly dread, and it is not the dramatic one. A failed switch or a severed fibre is unpleasant but straightforward, because the symptom points directly at the cause and the party responsible is obvious within minutes. The faults that consume entire days are the quiet ones, where every individual component tests clean, every supplier can demonstrate that their equipment is behaving correctly, and yet something in the environment is measurably broken.

These faults do not live inside any system. They live in the interaction between two of them, which means they are structurally invisible to anyone who is only looking at one.

Why single system diagnosis fails on these

When a vendor tests their own equipment, they test it against its own specification. The firewall is passing traffic according to its rules. The internet connection is delivering the throughput it was sold at. The voice platform is registering endpoints correctly. All three statements can be simultaneously true while the business cannot make a phone call, because the fault is not in any of those behaviours, it is in what happens when they meet.

This is why the standard response to an interaction fault is a loop. Each supplier tests within their own boundary, finds nothing, and returns a clean result in good faith. The loop only breaks when somebody looks at the behaviour across the boundary, which requires knowing both sides well enough to reason about what they are doing to each other.

Here are four we encounter often enough that we check for them early.

One: a firewall quietly rewriting your voice traffic

Many business firewalls ship with a feature enabled by default that inspects and modifies voice signalling traffic as it passes through, on the assumption that it is being helpful. On a significant number of modern voice platforms it is not helpful at all, and the result is registration that drops intermittently, calls that connect with audio flowing in only one direction, or calls that fail entirely after a fixed period.

The reason this fault survives so long in the wild is that both vendors are correct when they investigate. The voice provider sees that registration requests are arriving malformed and concludes the problem is on the network side. The firewall vendor sees a feature operating exactly as designed and concludes the problem is with the voice platform. Neither is wrong. The fault is a default setting on one device interacting badly with a design decision on another, and finding it requires somebody who knows to look at that specific interaction rather than at either device in isolation.

Two: voice quality that degrades on a schedule

A complaint we see regularly is that call quality is fine for most of the day and becomes unusable at a consistent time, often late afternoon or at a particular point in the morning. The voice platform reports no faults during those windows, because from its perspective there are none. The connection is not down. It is saturated.

The usual cause is that something else in the environment is consuming the available upstream bandwidth on a schedule, most commonly a backup job or a large synchronisation task, and no traffic prioritisation has been configured to protect voice when the link comes under pressure. Voice is unusually sensitive to this, because it tolerates low bandwidth well but tolerates delay and jitter very poorly, which means a connection that still looks healthy on a speed test can be entirely unable to carry a clean call.

Nobody diagnoses this by examining the phone system, and nobody diagnoses it by examining the backup platform. It is found by correlating a complaint pattern against a schedule, which requires visibility of both.

Three: the applications that hang while everything else works

One of the more confusing faults to experience from the user side is when general browsing works normally, small transactions complete, and yet certain applications stall consistently at the same point, often when uploading a file or loading a larger page.

A common cause is a mismatch in the maximum packet size that different parts of the path will accept, typically introduced when a tunnel, a secondary link or an encrypted connection is added to an environment by one party without the rest of the path being adjusted. Small packets pass without incident. Larger ones need to be fragmented, and if something along the way is configured to refuse fragmentation and the message saying so never gets back to the sender, the connection simply hangs rather than failing cleanly.

Every device in that path can be individually correct. The fault is a value that needed to agree across three of them and was only ever set on one.

Four: the failover link that half works

Businesses that have invested in a secondary connection for resilience sometimes discover, at the worst possible moment, that failover is partially functional rather than fully functional. Traffic leaves over the new path but return traffic tries to come back over the old one, or a security appliance that tracked the original session refuses the reply because it arrived from an unexpected direction.

The result is an environment where some services recover and others do not, which is considerably harder to diagnose than a clean outage because the partial success suggests the failover worked. The only way to know whether a resilience arrangement genuinely functions is to test it deliberately, under controlled conditions, before the day it is needed. In our experience the majority of untested failover configurations have at least one of these issues waiting in them.

What actually finds these

There is nothing mystical about diagnosing interaction faults. It requires three things, none of which are individually complicated and all of which are commonly absent.

The first is an accurate and current picture of the environment, meaning documentation of what is connected to what, which party supplied each element, and what changed recently. A surprising proportion of difficult faults resolve immediately once somebody establishes that a firmware update ran three days before the symptoms began.

The second is enough working knowledge of each adjacent system to reason about how they influence each other. This does not mean matching each specialist vendor in their own domain, which would be neither possible nor useful. It means knowing what a firewall does to voice traffic, what a backup window does to a connection, and what a secondary link does to session state, well enough to form a hypothesis worth testing.

The third is somebody whose job continues after each individual supplier has returned a clean result. This is the part that is usually missing, and it is the reason these faults persist for weeks in environments where every vendor is performing competently.

That work is our discipline. Our suppliers build and maintain the components, and they are excellent at it. Diagnosing what happens where those components meet is a different skill, and it is the one we have built our practice around.

If your environment has a recurring fault that nobody has been able to explain, that pattern is usually diagnosable. Get in touch and we will take a look at it properly.