All

I am after some help tracking down a connection problem. Details below. I am not sure what else I can try to find the cause.

• When I ping 8.8.8.8 from laptop wired directly into Draytek I get 3%+ packet loss and a variance of ping time from 15ms up to 180ms
  
  When I ping externally from a linux box to our router, via firewall rule and NAT routing to a linux box internally I get similar packet loss 3%+ and variance in ping time.
  
  When I ping internally to a from laptop to the router(192.168.0.1) i get no packet loss and ping times of less than 1ms
  
  When I ping internally to a from laptop to linux server (192.168.0.200) i get no packet loss and ping times of less than 1ms

All this is done with machines wired to the network rather than wireless.

ISP says all is clear on our line (Fiber line with huge bandwidth both ways)

The problem is our website calls back to our servers here to get prices and stock availability, the unreliable state leaves a high percentage (seemingly higher than the 3% packet loss figure) of those requests for prices to timeout and fail.

I began to think this was the Draytek routers firewall so I turned off all rules apart from the two needed to keep the website running, and repeated all tests with similar results.

I am at a loss of what to try next to nail down the problem. Any help would be great, is there a fault on the router? Is it my Firewall rules?

Thanks

Matt Houldsworth

On your net

Tracert 8.8.8.8
Ping you router
Ping the isp's first hop the other side of the router - you can see this node in the tracert
What do you see?

Pinging the router produces the same 2-3% packet loss and spikes in ping time every few seconds
Pinging the first hop in the tracert gives the same.

I repeated the tests direct into the fiber ONC I did not get lost packets but I did get the spikes in ping time

Matt

check there is no speed and duplex mismatch between PC an Switch port on the router

Do you have multiple IPs on a single WAN or multiple WANs (backup or load balancing)?
The most likely scenario is that the return packet is sent back to the wrong IP.
Also, try test some server you know to be local (bbc.co.uk), long distance ICMP echo packets are often downloaded.
Use a tool like WinMTR to track down the bottleneck.
3% packet loss is quite severe, most connections can't recover with more than 1.2% (despite what your consumer ISP might tell you).