qwest.net dropping packets... wife would like someone to pick them up please...
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
On Fri, Nov 2, 2012 at 8:42 PM, Don Gould <don@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
Hi Matt (and other helpful posters off list), Yes, makes sense. I'm told this pops up twice a month, so opps, clearly I need to spend more time reading and learning! :) Thanks to the person who pointed out the PTR rec suggests that the impacted resource might be more west than I realised. I confess I don't know the .us very well at all. D On 3/11/2012 6:43 p.m., Matthew Petach wrote:
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
-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
On Sat, Nov 3, 2012 at 3:07 AM, Randy Bush <randy@psg.com> wrote:
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
trivial footnote: some folk configure some routers to rate limit icmp
other trivial footnote, not all traceroute is icmp.
--- On Sat, 11/3/12, Christopher Morrow <morrowc.lists@gmail.com> wrote:
one router along the path showing loss that does not continue to affect the rest of the path simply means the cpu on
From: Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: qwest.net dropping packets... wife would like someone to pick them up please... To: "Randy Bush" <randy@psg.com> Cc: "North American Network Operators' Group" <nanog@nanog.org> Date: Saturday, November 3, 2012, 7:04 PM On Sat, Nov 3, 2012 at 3:07 AM, Randy Bush <randy@psg.com> wrote: that router
is a bit too busy to respond to icmp messages
trivial footnote: some folk configure some routers to rate limit icmp
other trivial footnote, not all traceroute is icmp.
True, wrt to destination. However all intermediate(including penultimate) hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) ./Randy
For some more information, this previous document and presentation make good resources: Document: http://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N4... There's also a presentation here: http://www.nanog.org/meetings/nanog45/presentations/Interpret_traceroutes.wm... On Sat, Nov 3, 2012 at 11:10 PM, Randy <randy_94108@yahoo.com> wrote:
--- On Sat, 11/3/12, Christopher Morrow <morrowc.lists@gmail.com> wrote:
one router along the path showing loss that does not continue to affect the rest of the path simply means the cpu on
From: Christopher Morrow <morrowc.lists@gmail.com> Subject: Re: qwest.net dropping packets... wife would like someone to pick them up please... To: "Randy Bush" <randy@psg.com> Cc: "North American Network Operators' Group" <nanog@nanog.org> Date: Saturday, November 3, 2012, 7:04 PM On Sat, Nov 3, 2012 at 3:07 AM, Randy Bush <randy@psg.com> wrote: that router
is a bit too busy to respond to icmp messages
trivial footnote: some folk configure some routers to rate limit icmp
other trivial footnote, not all traceroute is icmp.
True, wrt to destination. However all intermediate(including penultimate) hops reveal themselves via ICMP type 11 Code 0 (TTL exceeded in transit) ./Randy
participants (6)
-
Christopher Morrow -
Don Gould -
Matthew Petach -
PC -
Randy -
Randy Bush