I can't access Nocster's site or my server. Tracert stops shy of the hostnoc.net router on XO's network. I tried DNSStuff.com's traceroute and it stops same place. Anyone else having problems getting to nocster or having extreme (95%) packet loss?
Printable View
I can't access Nocster's site or my server. Tracert stops shy of the hostnoc.net router on XO's network. I tried DNSStuff.com's traceroute and it stops same place. Anyone else having problems getting to nocster or having extreme (95%) packet loss?
what is your ip range? We have no problem on few of our boxes there.
64.191.12.29-32
jasonl813:
yep, it's unstable, it goes dow and on all the time this past minutes.
have you notify nocster yet?
Hop Time 1 Time 2 Time 3 IP Hostname Return TTL Country Time
1 25 ms 30 ms 29 ms 216.26.128.225 kenny.fe-0-0-0.sdf.xodiax.net. 252 UNITED STATES Unix: 0:08:54.614
2 31 ms 36 ms 36 ms 65.117.168.137 chi-edge-09.inet.qwest.net. 251 UNITED STATES Unix: 0:08:54.647
3 23 ms 103 ms 103 ms 205.171.20.125 chi-core-03.inet.qwest.net. 250 UNITED STATES Unix: 0:08:54.684
4 99 ms 109 ms 119 ms 205.171.220.62 chp-brdr-01.inet.qwest.net. 250 UNITED STATES Unix: 0:08:55. 42
5 29 ms 34 ms 34 ms 206.111.2.153 p4-3.IR1.Chicago2-IL.us.xo.net. 249 UNITED STATES Unix: 0:09:08.787
6 47 ms 19 ms 33 ms 65.106.6.133 p5-0-0.RAR1.Chicago-IL.us.xo.net. 247 UNITED STATES Unix: 0:08:54.965
7 30 ms 40 ms 49 ms 65.106.0.46 p6-0-0.RAR2.Washington-DC.us.xo.net. 244 UNITED STATES Unix: 0:08:55. 32
8 91 ms 96 ms 96 ms 65.106.3.154 p4-0-0.MAR2.Philadelphia-PA.us.xo.net. 243 UNITED STATES Unix: 0:08:55.166
9 54 ms 60 ms 69 ms 207.88.87.46 p15-0.CHR1.Philadelphia-PA.us.xo.net. 243 UNITED STATES Unix: 0:09:09.311
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
Done!
Can't get ahold of them. Can't access their site.
Mine is down to. But aletra which usually tells me pretty fast says everything is fine.
I was talking to the network admin online right before this started, he's aware of the issue. It looks like a massive flood (incoming on the XO line), which is giving very high latency & packetloss at the PHL router (those are only my thoughts, from what I could see).
Here's a trace that I did save:
traceroute: Warning: www.gblx.net has multiple addresses; using 64.211.77.61
traceroute to wwwgblx.web.globalcrossing.com (64.211.77.61), 30 hops max, 38 byte packets
1 ge-5-0-border.scr1.hostnoc.net (64.191.0.1) 0.243 ms 0.179 ms 0.153 ms
2 66.197.191.46 (66.197.191.46) 5.426 ms 5.308 ms 5.268 ms
3 fe12-0.chr1.philadelphia-pa.us.xo.net (66.236.204.9) 1133.783 ms pos-4-0-cmbn.rtr0.nyny.hostnoc.net (66.197.191.30) 1097.269 ms 577.532 ms
4 ge-2-1-0.ar1.JFK1.gblx.net (64.215.82.149) 16.522 ms 16.490 ms 17.119 ms
5 pos3-0-2488M.cr2.JFK1.gblx.net (67.17.72.17) 18.434 ms * pos3-0-2488M.cr1.JFK1.gblx.net (67.17.72.13) 16.788 ms
6 * * pos0-0-622M.cr2.CLE1.gblx.net (67.17.68.94) 34.810 ms
7 * * pos1-0-0-155M.ar1.CLE1.gblx.net (67.17.68.114) 34.853 ms
8 * s1-0-45M.dmz2.DET1.gblx.net (67.17.67.77) 113.327 ms 119.914 ms
9 * * *
- Matt
Somewhat back up. Getting 700ms pings and about 50% packet loss still.
Hop Time 1 Time 2 Time 3 IP Hostname Return TTL Country Time
1 27 ms 31 ms 31 ms 216.26.128.225 kenny.fe-0-0-0.sdf.xodiax.net. 252 UNITED STATES Unix: 0:16:58.678
2 31 ms 36 ms 35 ms 65.117.168.137 chi-edge-09.inet.qwest.net. 251 UNITED STATES Unix: 0:16:58.713
3 39 ms 44 ms 44 ms 205.171.20.125 chi-core-03.inet.qwest.net. 250 UNITED STATES Unix: 0:16:58.756
4 47 ms 51 ms 59 ms 205.171.220.62 chp-brdr-01.inet.qwest.net. 250 UNITED STATES Unix: 0:16:58.984
5 29 ms 34 ms 34 ms 206.111.2.153 p4-3.IR1.Chicago2-IL.us.xo.net. 249 UNITED STATES
6 31 ms 36 ms 35 ms 65.106.6.133 p5-0-0.RAR1.Chicago-IL.us.xo.net. 247 UNITED STATES Unix: 0:16:58.913
7 47 ms 51 ms 59 ms 65.106.0.46 p6-0-0.RAR2.Washington-DC.us.xo.net. 244 UNITED STATES Unix: 0:16:58.973
8 51 ms 55 ms 59 ms 65.106.3.154 p4-0-0.MAR2.Philadelphia-PA.us.xo.net. 243 UNITED STATES Unix: 0:16:59. 60
9 40 ms 44 ms 49 ms 207.88.87.46 p15-0.CHR1.Philadelphia-PA.us.xo.net. 243 UNITED STATES
10 560 ms 570 ms * 66.236.204.10 66-236-204-10.hostnoc.net. 240 UNITED STATES
11 632 ms 640 ms 649 ms 66.197.191.45 [Missing reverse DNS entry] 239 UNITED STATES
12 691 ms * 710 ms 64.191.47.155
[Reached Destination][Missing reverse DNS entry] 47 UNITED STATES
At least their site is loading fine for me :)
Hopefully the issue will be fixed asap.
Looks like it's coming back now, XO line is still congested though.
- Matt
Just a little rant, but have you ever read their TOS? It says you must open a ticket for packet loss or average access time above 85ms in order to receive credit for a partial month. But Nocster techs complain when you open the tickets. They tell me to wait longer before opening them!?!?!
I am pinging fine now, but was in the 750 range.
Nevermind it is still messed up.
That means that you must submit an SLA ticket, the form can be found on the website. (http://www.nocster.com/policy/sla.shtml)Quote:
It says you must open a ticket for packet loss or average access time above 85ms in order to receive credit for a partial month.
Average round trip latency for an entire MONTH has to be 85ms or more. Packetloss has to be 1% for a MONTH, or it doesn't qualify. Downtime has to be for more than .5% of the month, or it doesn't qualify. You don't qualify for the SLA this month, which is a good thing :)
- Matt
But you still have to open a support ticket to prove you were having an issue. They say they have to verify it if you try to collect on it.
Quote:
Each request in connection with network/server outages/downtime must be received by BurstNET™ within five days of the occurance.
Doesn't matter anyways. They always blame AT&T for everything and say it's not their fault.
The last set of issues WAS an ATT issue. ATT did verify this over the phone with me, and traceroutes showed the same thing. That took a long time to resolve since Burst doesn't actually use ATT bandwidth, the problem was between ATT & GBLX.
- Matt
I don't care, just glad they are back up.
Why does AT&T never show on my traceroutes when it happens? It is always at hostnoc.net that it jumps.
I'm back up too.
OR state there's not an issue when there really was. I've personally seen 'em do that more than once. The whole network could be down, they'd deny it on every forum, lolQuote:
Originally posted by jasonl813
Doesn't matter anyways. They always blame AT&T for everything and say it's not their fault.
You know... There is something called the... "assymetric routing/variance in BGP best path selection"Quote:
Originally posted by jasonl813
Why does AT&T never show on my traceroutes when it happens? It is always at hostnoc.net that it jumps.
I'm back up too.
_Your_ ISP does not think AT&T-->HOSTNOC is the best path, or does not have the path via AT&T to get to HOSTNOC. So _your_ packets get routed via another transit network i.e. XO to get to hostnoc.net.
Hostnoc.net however thinks in order to get back to _YOU_, sending out packet TO AT&T transit is the fastest path.
So when you run traceroute from _your_location_ *to* hostnoc, it goes via non-att network. But when hostnoc runs traceroute *to* you, it goes via at&T, which obviously does not show up in your traceroute b/c that's variance in reverse path (aka, asymetric routing).
This happens a lot on the internet, so nothing to worry about.
The problem is b/c AT&T's peering is all messed up since the last week or two, when hostnoc sends a packet thru at&t, it gets severely delayed on att's network. That's why in your traceroute you see a huge spike of latency as soon as it enters hostnoc.net, b/c hostnoc router was sending packets thru att.
So in other words... in this specific case, it was ATT's fault, none of it is hostnoc's in technical sense.
-hc
But then the server traceroute (initiated from the server in cPanel) back to me would show the problem going through AT&T though right? It doesn't and there is still a jump in latency.