Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and propagates all the way down the line. Worse during peak hours, gone late at night.
After three days of no email response for my ticket, I called and after an hour of my life I want back, front line support cannot reproduce the loss. Final conclusion: "Your host is dropping packets".
mtr packet loss column has no scientific precision and should not be
considered. It is not mtr fault but forwarding routers have a low priority
to respond to ICMP requests. The only way you can prove there is a problem
is a end to end ping, the regular ping command, not mtr.
If the loss is seen towards a terminating webserver maybe spool curl response times over the course of a day and correlated that to observed loss via a smokeping service.
Support may be more responsive with some hard statistics.
Regards,
Andrew Paolucci
Local Time: December 14, 2016 2:53 PM
UTC Time: December 14, 2016 7:53 PM
Nanog <nanog@nanog.org>
Hello,
mtr packet loss column has no scientific precision and should not be
considered. It is not mtr fault but forwarding routers have a low priority
to respond to ICMP requests. The only way you can prove there is a problem
is a end to end ping, the regular ping command, not mtr.
Also reproduced the results with pings walking them down the line up to
and including the actual host. The MTR example provided is simply the
clearest representation of the ping results which show the same.
esp the pdf there, but in this case Randy's mtr does do a ping to the last
hop. He did have 4.1% pl to the endpoint for his specific setup and
current gear/route/etc.
However, I go through the same hostname'd router he does (he didnt provide an
ip, but paris-traceroute doesnt show me load balancing, at least visibly), and
I only get 0.3% pl. (Though, my immediate upstream DSL provider's router is giving
me 0.2% pl, so who knows what that 0.3% means at the far end, really.)
Without bidirectional concurrent mtr's (one from cogent back to him at the
same time), it's quite hard to say what's going on. Even then that's no guarantee
of diagnosis.
Here's just the most recent thread with some depth on how to read traces and packetloss:
Walking the line, so to speak. Starting with our directly connected cogent peer. Loss begins at the same hop and carries through to the end host. I'm only using cogentco as an example, but the results are the same anywhere.
I think people are just going to see a traceroute determining packet loss and not going to read the rest of what happened. Just going to shortcut to an answer.
Odd, though, that they didn't respond for three days. I've typically had good luck with that, although admittedly it's been months since I've opened an e-mail ticket with their NOC. Spam-filter?
No, I got a confirmation and ticket ID immediately. Three days later I call it in and they pull it up, sure enough nobody took ownership. Same thing happened about a month ago. Seems email ticket priority is zero. You HAVE to call to get any kind of action. And it also seems the front line techs are not as skilled as before -- basic pinging and questionable understanding of traceroutes / asymmetrical routing.
Final update from Cogent -- glad they have finally acknowledged -- but no ETA, just great:
After further investigation, we have identified an issue of congestion on our core device. At this time we are scheduling a maintenance to alleviate the congestion which in turn will fix the packetloss seen across the Ashburn area.
The maintenance has not yet been scheduled but we will inform you once we have a set date.