Member Avatar for gn0m3

Hi and thanks for looking.

We have a main site in the South East of the UK and a satellite branch in Birmingham (we moved offices 4 months ago to a new site). We have a Multisite WAN with our ISP, we run a 30mb Fiber at our main site and bonded dsl in Birmingham (10mb circuit). We run a DB server (Filemaker) at the main office which our satellite offices connect to over the WAN. Birmingham branch experiences lag and incerdibly slow speeds when doings lookups or finds or when copying data from our fileserver and all ping tests I run from the 3 machines up there (two macs and a win 7 machine) get 12% or more packet loss when pinging our router or DB server in the main office, however our ISP tells me they cannot replicate this from the router.. We have replaced the CAT5 cabling at the branch and our ISP sent an engineer to check the other hardware wasn't to blame which I'm told is all functioning fine.

Getting super frustrated now and would like a fresh opinion on the possible reasoning behind this. Think I've included all the details but feel free to ask anymore questions!!

Thanks for looking.

J

  • 3 Contributors
  • 4 Replies
  • 224 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by gn0m3

Dani AI

Generated

Building on and : isolation is the right first move, but a few targeted diagnostics and data points make the difference between guessing and fixing. The most useful evidence to collect (from both branch and HQ) is continuous ping logs, MTR/traceroute outputs, iperf throughput runs, a short tcpdump showing retransmits, and SNMP/interface counters (CRC, FCS, drops, collisions) from switches and routers. Correlating those with CPU/memory utilisation on the edge devices shows whether drops are caused by line errors, queue exhaustion, or an underpowered router.

Common causes that were not fully explored in the thread include duplex/auto-negotiation mismatches, MTU/path‑MTU issues causing fragmentation and retransmits, interface/frame errors on switches, small‑packet “chatty” application patterns (DB lookups), per-flow policing or burst-limiting on the ISP/CPE, and NAT/conntrack table exhaustion. Microbursts can drop packets even when average utilisation looks low; queue/drop patterns in interface counters usually reveal that. Packet captures make it clear whether loss is due to retransmits (TCP) or drops at a specific hop.

For application-heavy traffic (FileMaker or similar), reducing WAN round trips is often the best long-term fix: local caching, a read-only replica, scheduled bulk syncs, or a WAN-optimiser will massively reduce perceived lag. When escalating to an ISP, hand over the collected traces and SNMP graphs and request simultaneous tests from their end; that removes ambiguity about “I can’t see it from my router.”

These steps provide a structured way to turn intermittent packet loss into actionable evidence, which in turn points to the right fix—whether it is cabling, config, line quality, or hardware capacity.

Recommended Answers

All 4 Replies

Member Avatar for CimmerianX

1st thing i would do is disconnect all internal lan devices. Plug a single system directly into your DSL drop (or into your DSL modem... not sure what type you have).

You should have 1 machine online. There's a linux tool called 'mtr' that will trace along a path and point out drops and delays along the path. If you have a mac, I would imagine there is a similiar util on there.

Point is, you should 1st eliminate all internal systems from the mix and run your tests to see if you can replicate the packet loss.

Member Avatar for cgeier

The following may be of interest:
Packet loss

Here are a few ideas.

Possible issue 1:
Packet loss due to network flooding. This could be caused by a bad network card, a virus, etc.

Tests:
Unhook all computers except for one, and test for packet loss. Repeat for the other two computers.

Repeat test using a clean computer--one that has a newly installed OS, or one that is known to work from another site--this will eliminate any computer hardware issues and the possibility of a virus/malware. Connect this computer to the cable from one of the other computers.

Possible Issue 2: Noise/interference on/in the cabling from the environment (such as fluorescent lighting, or other electro-magnetic interference)

Test:
Using clean computer, repeat test close to the router, using a 1-2 m cable to connect to the router. Disconnect all other cables at the router. Test for packet loss again.

Member Avatar for gn0m3

Thanks for your comments guys, much appreciated. I'll run the tests you've suggested.

Many thanks.

J

Member Avatar for gn0m3

In the end I replaced all the cabling etc at site and that made no difference. A Cisco guy at our ISP ended up getting invoved and said that the Router at our HQ wasn't beefy enough to handle the traffic.. Got it upgraded for free and problem solved.. Thanks again for your input.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.