Joe Marr wrote: the only thing I can find wrong is packetloss and latency between hops 7 and 8.
It has nothing to do with your issue. The very fact that the next hops do not exhibit the same problem shows that the router is processing packets fine. This is not uncommon, might be caused by our old friend the BGP scanner process which has a higher priority than ICMP. There is no relation between pinging the router and the router processing packets correctly. And although Sprint might want to address it at some point it is absolutely none of your business as long as the router keeps processing traffic which it does. The "loss" you are referring to is no loss at all it's likely rate-limiting. Lots of people do something along these: rate-limit output access-group 100 16000 1500 2000 conform-action transmit exceed-action drop access-list 100 remark ------------------- access-list 100 remark acl for rate-limit. access-list 100 remark =------------------ access-list 100 permit icmp any any access-list 100 remark What you care is end-to-end traffic anyway. If that router did not respond to pings at all it would still process traffic which is the only thing you should care about.
but how do I go about tracking down this issue? None of their other offices have this problem.
By hiring a professional. Comparing msec sniffer traces between the server, a site that works and the site that has problems would be a good beginning. Getting meaningful conclusions out of them requires a certain level of skill though; I hope you'll forgive my bluntness but if you can't analyze the fact that the traceroute is not the tool you need you are nowhere near where you need to be in order to look at sniffer deltas. Michel.