qwest.net dropping packets... wife would like someone to pick them up please...
Matthew Petach
mpetach at netflight.com
Sat Nov 3 05:43:47 UTC 2012
On Fri, Nov 2, 2012 at 8:42 PM, Don Gould <don at bowenvale.co.nz> wrote:
> Hi all,
>
> Hope you're all getting on top of Sandy.
>
> Trying to hit kajabi.com, I'm getting up to 60% packet loss off qwest.net -
> dca2-edge-02.inet.qwest.net
>
> A bit of quick googleing and we assumed that they're on the west coast of
> US, so please excuse (and just ignore me) if you're on the east coast and
> this is being caused by all the Sandy issues (yes I've been following the
> Outage list and think you guys are just doing an amazing job right now!!!)
>
> Re the subject - told the wife that her problem is likely being caused by
> packets being dropped by qwest, her response "can someone pick them up for
> me plse :)"
>
>
> mx.8013.yournet.co.nz (0.0.0.0) Sat Nov 3 16:43:18
> 2012
> Keys: Help Display mode Restart statistics Order of fields quit
> Packets Pings
> Host Loss% Snt Last Avg Best Wrst
> StDev
> 1. router 0.0% 39 0.2 0.2 0.2 0.3
> 0.0
> 2. ???
> 3. 218.101.61.101 0.0% 39 9.1 21.8 7.0 173.6
> 33.4
> 4. ie2-g-0-0-0.telstraclear.net 0.0% 39 38.0 22.9 19.6 38.0
> 3.5
> 5. ge-0-2-0-1.xcore1.acld.telstracl 0.0% 39 22.2 22.9 18.9 38.5
> 3.9
> 6. unknown.telstraglobal.net 0.0% 39 23.4 22.1 17.6 26.4
> 1.4
> 7. i-0-6-1-0.tlot-core01.bx.telstra 0.0% 39 153.4 153.3 151.2 163.9
> 2.3
> 8. i-4-2.eqla01.bi.telstraglobal.ne 0.0% 39 147.0 154.8 143.5 313.8
> 27.7
> 9. lap-brdr-04.inet.qwest.net 0.0% 39 154.2 154.5 152.0 159.2
> 1.6
> 10. dca2-edge-02.inet.qwest.net 10.5% 39 221.0 223.1 217.1 247.6
> 6.6
> 11. 67.133.224.194 0.0% 39 220.8 222.2 216.3 268.6
> 8.1
> 12. 72.21.220.161 0.0% 39 221.2 225.3 217.6 268.2
> 10.8
> 13. 72.21.222.139 0.0% 38 220.9 222.8 216.6 266.6
> 7.5
> 14. 216.182.224.8 0.0% 38 221.3 223.2 220.5 243.9
> 4.1
> 15. ???
>
> D
> --
> Don Gould
> 31 Acheson Ave
> Mairehau
> Christchurch, New Zealand
> Ph: + 64 3 348 7235
> Mobile: + 64 21 114 0699
>
>
Hi Don,
based on your mtr output, there's no loss to the
end destination; one router along the path showing
loss that does not continue to affect the rest of the
path simply means the cpu on that router is a bit
too busy to respond to icmp messages; but there's
0% loss beyond it, which means it's doing its primary
job of forwarding packets just fine.
Thanks, and have a wonderful weekend!
Matt
More information about the NANOG
mailing list