network last hour

[kitchin]

Is it normal?

[sheila]

I am not seeing any issues. Sites are responding normally for me (from my remote location in Los Angeles County). What are you seeing? Can you provide additional details? Traceroutes? Etc...?

[oheso]

I was getting no response (from Japan) for anything FQ from about 23:50 GMT to 0:12. But it's all back now.

I'm used to occasional transient outages of five minutes or so. This one was unusual in its length. (I didn't do a traceroute, sorry.)

I wonder if there's a DOS going on somewhere, or something else we'll read about in Slashdot tomorrow.

[sheila]

We have had a couple of other clients inquire through the Service Desk about network connectivity issues. But I have seen no issues, and our monitoring systems show that everything is fine. I suspect there is something going on out there in the Internet that is affecting routing to FutureQuest for some clients, but no one has provided any specifics, so that is mere speculation on my part.

[oheso]

OK, I'm running into a roadblock somewhere between Taiwan and Aota ...


Tracing route to www.aota.net [69.5.6.207]
over a maximum of 30 hops:

1 1 ms <1 ms 10 ms 192.168.2.1
2 2 ms 25 ms 3 ms ntt.setup [192.168.1.1]
3 9 ms 8 ms 8 ms 118.23.70.134
4 8 ms 12 ms 32 ms 118.23.70.158
5 11 ms 10 ms 16 ms 118.23.64.233
6 20 ms 8 ms 10 ms 122.28.168.5
7 7 ms 9 ms 9 ms 118.23.168.91
8 22 ms 21 ms 16 ms ae-11.r21.tokyjp01.jp.bb.gin.ntt.net [129.250.12.201]
9 129 ms 131 ms 131 ms as-2.r21.snjsca04.us.bb.gin.ntt.net [129.250.4.44]
10 122 ms 130 ms 189 ms snjs.equinix.twtelecom.net [206.223.116.36]
11 262 ms 232 ms 235 ms orl1-ar3-xe-0-0-0-0.us.twtelecom.net [66.192.243.186]
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * 272 ms aota.net [69.5.6.207]

Trace complete.


Tracing route to www.aota.net [69.5.6.207]
over a maximum of 30 hops:

1 4 ms <1 ms 1 ms 192.168.2.1
2 3 ms 8 ms 1 ms ntt.setup [192.168.1.1]
3 11 ms 8 ms 11 ms 118.23.70.134
4 7 ms 7 ms 8 ms 118.23.70.158
5 36 ms 13 ms 8 ms 118.23.64.233
6 40 ms 7 ms 23 ms 122.28.168.5
7 11 ms 7 ms 11 ms 118.23.168.91
8 17 ms 17 ms 18 ms ae-11.r21.tokyjp01.jp.bb.gin.ntt.net [129.250.12.201]
9 146 ms 122 ms 122 ms as-2.r21.snjsca04.us.bb.gin.ntt.net [129.250.4.44]
10 159 ms 139 ms 131 ms snjs.equinix.twtelecom.net [206.223.116.36]
11 233 ms 238 ms 230 ms orl1-ar3-xe-0-0-0-0.us.twtelecom.net [66.192.243.186]
12 * * * Request timed out.
13 * * * Request timed out.
14 197 ms 196 ms 215 ms aota.net [69.5.6.207]

Trace complete.

It's a come-and-go thing.

[oheso]

My bad ... twtelecom is not in Taiwan! ;-)

[Kevin]

My Orlando Bright House cable modem connection seems to be working fine. I even go through the exact same hop #11 to get to FutureQuest.

I will keep an eye on it to see if something pops up but it seems fine to me.

[oheso]

Seems fine now. (Intervening time spent "enjoying" father-in-law's cooking, hanging a clock for my mother-in-law, and doing dishes. Then moving the clock to another location.)

[oheso]

Kevin, just for my curiosity's sake, does a timeout in a traceroute indicate the exact location of the issue, or can it indicate an issue anywhere in the route up to that point? (Not sure how traceroute works in this regard.)

I'm asking because I have this one (taken during the earlier trouble):


Tracing route to www.aota.net [69.5.6.207]
over a maximum of 30 hops:

1 2 ms <1 ms 22 ms 192.168.2.1
2 1 ms 1 ms 5 ms ntt.setup [192.168.1.1]
3 13 ms 16 ms 14 ms 118.23.70.134
4 31 ms 13 ms 19 ms 118.23.70.158
5 14 ms 17 ms 36 ms 118.23.64.233
6 9 ms 22 ms 9 ms 122.28.168.5
7 26 ms 36 ms 11 ms 118.23.168.91
8 49 ms 20 ms 53 ms ae-11.r21.tokyjp01.jp.bb.gin.ntt.net [129.250.12.201]
9 186 ms 123 ms 120 ms as-2.r21.snjsca04.us.bb.gin.ntt.net [129.250.4.44]
10 164 ms 125 ms 138 ms snjs.equinix.twtelecom.net [206.223.116.36]
11 233 ms 237 ms 232 ms orl1-ar3-xe-0-0-0-0.us.twtelecom.net [66.192.243.186]
12 * * 318 ms g.core-x-03.futurequest.net [69.5.31.236]
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 263 ms * * aota.net [69.5.6.207]
17 * 294 ms * aota.net [69.5.6.207]
18 * * 274 ms aota.net [69.5.6.207]

Trace complete.

[Kevin]

Kevin, just for my curiosity's sake, does a timeout in a traceroute indicate the exact location of the issue, or can it indicate an issue anywhere in the route up to that point? (Not sure how traceroute works in this regard.)
It can but it doesn't have to. Traceroute operates on ICMP (like ping) and many routers tend to give ICMP traffic a very low priority. So it is entirely possible for ping and traceroute to show a problem when there isn't an issue at all.

Also, the next hop may simple be configured to not respond to traceroute requests or to filter them out.

Finally, it is possible that your you>FQ traffic takes one path through the internet and your FQ>you traffic takes a different path. In that case the stop in traceroute could simply indicate the point at which asymetric routing came into play and you stopped getting return data. This is why we generally ask what your IP is so we can run traceroute back to you from one of our servers.

You didn't give your IP address but I did a traceroute to the first real IP address in your traceroute output:

traceroute to 118.23.70.134 (118.23.70.134), 30 hops max, 60 byte packets
1 69.5.6.gw.futurequest.net (69.5.6.1) 0.163 ms 0.170 ms 0.165 ms
2 nova.futurequest.net (69.5.31.227) 0.415 ms 0.400 ms 0.411 ms
3 revnet.futurequest.net (207.50.14.97) 2.136 ms 2.211 ms 2.268 ms
4 savvis.futurequest.net (208.173.90.37) 7.053 ms 7.148 ms 7.156 ms
5 cr1-pos-0-3-1-1.miami.savvis.net (204.70.205.129) 10.588 ms 10.598 ms 10.583 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 ae-5.r20.lsanca03.us.bb.gin.ntt.net (129.250.2.168) 135.091 ms * 139.569 ms
11 as-5.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.3.23) 240.015 ms * *
12 * * *
13 * * *
14 * * *
15 118.23.64.230 (118.23.64.230) 254.115 ms * *
16 * * *
17 * * *
18 118.23.70.134 (118.23.70.134) 258.694 ms !X * *

That actually looks a lot worse :hrmm:

[oheso]

Thanks for the explanation! I was aware that some devices won't respond, and as you see many NTT devices do not. (And yes, that IP address is in line 3 of my traceroutes. I think it's the apartment's router.)

Still having big problems here with anything on FQ. I hope wherever the problem is, the admin responsible wakes up and fixes it!

[kitchin]

Thanks folks. I didn't run a traceroute or other tests, since I was leaving the office. When I came back later everything was good.