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