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?
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 22.214.171.124
traceroute to wwwgblx.web.globalcrossing.com (126.96.36.199), 30 hops max, 38 byte packets
1 ge-5-0-border.scr1.hostnoc.net (188.8.131.52) 0.243 ms 0.179 ms 0.153 ms
2 184.108.40.206 (220.127.116.11) 5.426 ms 5.308 ms 5.268 ms
3 fe12-0.chr1.philadelphia-pa.us.xo.net (18.104.22.168) 1133.783 ms pos-4-0-cmbn.rtr0.nyny.hostnoc.net (22.214.171.124) 1097.269 ms 577.532 ms
4 ge-2-1-0.ar1.JFK1.gblx.net (126.96.36.199) 16.522 ms 16.490 ms 17.119 ms
5 pos3-0-2488M.cr2.JFK1.gblx.net (188.8.131.52) 18.434 ms * pos3-0-2488M.cr1.JFK1.gblx.net (184.108.40.206) 16.788 ms
6 * * pos0-0-622M.cr2.CLE1.gblx.net (220.127.116.11) 34.810 ms
7 * * pos1-0-0-155M.ar1.CLE1.gblx.net (18.104.22.168) 34.853 ms
8 * s1-0-45M.dmz2.DET1.gblx.net (22.214.171.124) 113.327 ms 119.914 ms
9 * * *
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 126.96.36.199 kenny.fe-0-0-0.sdf.xodiax.net. 252 UNITED STATES Unix: 0:16:58.678
2 31 ms 36 ms 35 ms 188.8.131.52 chi-edge-09.inet.qwest.net. 251 UNITED STATES Unix: 0:16:58.713
3 39 ms 44 ms 44 ms 184.108.40.206 chi-core-03.inet.qwest.net. 250 UNITED STATES Unix: 0:16:58.756
4 47 ms 51 ms 59 ms 220.127.116.11 chp-brdr-01.inet.qwest.net. 250 UNITED STATES Unix: 0:16:58.984
5 29 ms 34 ms 34 ms 18.104.22.168 p4-3.IR1.Chicago2-IL.us.xo.net. 249 UNITED STATES
6 31 ms 36 ms 35 ms 22.214.171.124 p5-0-0.RAR1.Chicago-IL.us.xo.net. 247 UNITED STATES Unix: 0:16:58.913
7 47 ms 51 ms 59 ms 126.96.36.199 p6-0-0.RAR2.Washington-DC.us.xo.net. 244 UNITED STATES Unix: 0:16:58.973
8 51 ms 55 ms 59 ms 188.8.131.52 p4-0-0.MAR2.Philadelphia-PA.us.xo.net. 243 UNITED STATES Unix: 0:16:59. 60
9 40 ms 44 ms 49 ms 184.108.40.206 p15-0.CHR1.Philadelphia-PA.us.xo.net. 243 UNITED STATES
10 560 ms 570 ms * 220.127.116.11 66-236-204-10.hostnoc.net. 240 UNITED STATES
11 632 ms 640 ms 649 ms 18.104.22.168 [Missing reverse DNS entry] 239 UNITED STATES
12 691 ms * 710 ms 22.214.171.124
[Reached Destination][Missing reverse DNS entry] 47 UNITED STATES
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!?!?!
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
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.
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.
You know... There is something called the... "assymetric routing/variance in BGP best path selection"
_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.