Network Troubleshooting Jamaica: Isolating Faults Across Shared Networks
The hardest network faults in Jamaica are rarely the technical ones. They are the political ones. When a connection between a Government of Jamaica agency, a hosting ministry, and a commercial provider goes down, network troubleshooting in Jamaica turns into a three-way conversation in which every party checks its own equipment, finds it healthy, and reports back that the problem must be someone else's. Everyone is telling the truth. Nothing moves. The link stays down.
We were called into exactly that stalemate. Three parties, each certain their side was fine, and a connection that had been down long enough for frustration to set in. It was resolved the same day, not with better equipment, but with evidence that no one could argue with.
Why "our side is fine" is usually honest and useless
In a multi-party network, each organisation can only see its own edge. The agency sees its firewall responding. The ministry sees its VPN up. The provider sees its circuit green. Each test is real and each result is correct, for the slice that party can observe. The fault lives in the gaps between them, in a path that no single party can see end to end.
That is why these faults stall. There is no shared view, so there is no shared conclusion, and in the absence of proof the safe move for everyone is to defend their own patch. Troubleshooting across shared networks is less about finding the break and more about producing evidence that assigns it to one specific party beyond dispute.
Step one: eliminate the variable everyone forgets
The first thing we do is remove the one variable that silently breaks these connections: the source address the traffic leaves from. In a setup with more than one path, traffic can leave from more than one address, and only some of those addresses may be authorised on the far side. A test that works from one address and fails from another looks like an intermittent fault to everyone watching, when it is actually a routing and policy question.
So before anything else, we test from both candidate source addresses explicitly. Often that single step collapses the mystery: the connection is not intermittent at all, it simply only ever worked from one address, and the traffic had started leaving from the other. Eliminate that variable and the real fault stops hiding behind it.
Step two: make the network name the responsible party
Once the source-address question is settled, the tool that ends the stalemate is a traceroute read together with the specific ICMP error that comes back. A plain "it times out" tells you nothing useful. But a traceroute that reaches a particular hop and returns "destination net unreachable" from that hop is doing something powerful: a device on the path is identifying itself and admitting it has no route onward.
That is no longer an opinion. It is the network itself naming where the path dies, and which party owns the device that said so. You are no longer asking three parties to trust each other. You are showing all three the same message from a specific hop, and the conversation changes immediately, because there is nothing left to dispute.
How the stalemate ended
In this case, the combination did the job. Testing both source addresses ruled out the agency's side. The traceroute and the ICMP error pointed at a specific hop and a specific party, and once everyone was looking at the same evidence, the responsible party could act instead of defend. The path came up the same day.
The lasting fix went further than restoring the link. The design was changed so a dedicated government circuit became the primary path and the existing VPN became an automatic backup. When that failover was later exercised, the result was a single packet lost and no production outage, the difference between a network that merely works and one that keeps working when a path fails.
Why this is a managed-services problem, not a one-off call
The reason these faults drag on is that no single party owns the end-to-end path, and nobody is positioned to coordinate across the agency, the ministry, and the commercial provider at once. That coordination, holding the evidence, driving the parties to the same conclusion, and then designing the path so the next fault is survivable, is exactly what belongs in a managed service rather than an emergency call placed after a week of downtime.
The equipment was never really the problem. The missing piece was someone whose job was the whole path, not one edge of it.
Related reading: why a backup link often cannot actually carry traffic, how SD-WAN turns multiple paths into real redundancy, and the firewall mistakes that create these faults in the first place.
Carrier and vendor coordination, handled. When a fault crosses agencies and providers, someone has to own the whole path and the evidence. Make that Systems Rubix, as part of managed IT services built for Jamaica's multi-party government and business networks.