Hey, until the recent Managed.com problems I've always pinged 1.xxx MS to google.com. Now the route is WAY off and I ping around 78. They are in the same datacenter so I dont see what the problem is here.. Here are the new routes and some pings replys... Anyone have any Idea what might be going on?



64 bytes from 216.239.37.99: icmp_seq=2 ttl=243 time=78.069 ms
64 bytes from 216.239.37.99: icmp_seq=3 ttl=243 time=78.042 ms
64 bytes from 216.239.37.99: icmp_seq=4 ttl=243 time=78.012 ms
64 bytes from 216.239.37.99: icmp_seq=5 ttl=243 time=78.051 ms



1 66.79.178.1 (66.79.178.1) 0.505 ms 0.277 ms 0.217 ms
2 manageddotcom.assertivenetworks.net (66.154.102.1) 68.963 ms 0.266 ms 0.306 ms
3 728.ge-5-1-1.er10a.sjc2.us.above.net (209.66.79.98) 0.436 ms 0.541 ms 0.370 ms
4 so-2-0-0.mpr3.sjc2.us.above.net (64.125.30.89) 0.366 ms 0.338 ms 0.360 ms
5 so-3-0-0.mpr2.sjc7.us.above.net (64.125.30.177) 0.606 ms 0.600 ms 0.571 ms
6 so-3-2-0.edge1.SanJose1.Level3.net (4.68.127.33) 0.575 ms 0.581 ms 0.587 ms
7 so-5-0-0.gar1.SanJose1.Level3.net (209.244.3.137) 0.913 ms 0.953 ms 0.831 ms
8 as-1-0.bbr1.Washington1.Level3.net (64.159.1.86) 77.729 ms 77.705 ms 77.725 ms
9 ge-9-0.ipcolo2.Washington1.Level3.net (64.159.18.36) 77.758 ms 78.114 ms 77.776 ms
10 unknown.Level3.net (166.90.148.174) 77.798 ms 77.812 ms 77.905 ms
11 64.233.174.126 (64.233.174.126) 78.195 ms 78.109 ms 78.122 ms
12 216.239.48.94 (216.239.48.94) 80.129 ms 80.180 ms 89.973 ms

managed's 400 new servers on thier 200 cpu network suckin gthe life out of the western us internet?

Originally posted by neoshell
managed's 400 new servers on thier 200 cpu network suckin gthe life out of the western us internet?

400 new servers on their 200 cpu network? what exactly is a 200 cpu network? :)

well obviously its a joke meaning they probably have double the amount of computers on thier net than it was designed to support.

Word is that a Fiber was cut somewhere that has impacted the internet as a whole for the past few days, especially the West Coast.

:bawling:

and here I saw the thread title and made popcorn...then I read it and realized this really isnt in line with all other managed.com threads.

Anywho, that google ip you traced to dropped off the face of the earth from my location...obviously some problems somewhere. Of course, if it were managed.com's problem..you'd see the high latency on THEIR network, not level3. No fun in pointing fingers at managed.com when it's obviously not related to them.

this isnt a high latency issue, its a route issue. Managed.com is sending the packets practically around the world when the google servers are situated tens of yards away in the same datacenter. It used to be a few hops. I dont remember exactly, maybe 4 or 5.

Originally posted by JSH-John
this isnt a high latency issue, its a route issue. Managed.com is sending the packets practically around the world when the google servers are situated tens of yards away in the same datacenter. It used to be a few hops. I dont remember exactly, maybe 4 or 5.

You should be able to tell from your own traceroute that that's clearly not the case, unless San Jose has been moved to Washington state.

Google has several datacenters and uses some kind of load balancing/geolocation/round robin DNS to determine what datacenter google.com resolves to.

Their San Jose datacenter has been out of commission for a good few months now. Go ahead and try this link:

www-sj.google.com (http://www-sj.google.com/)

Not doing much for you, huh? Next time try using IPs instead of domains and look at your own traceroutes before you start making wild accusations.

:cartman:

firstly, its ALWAYS been the same IP when I ping google.com, for years now I've always used google.com as a test to test my pings from different locations. I know I always get 10-11ms from home when my connection is fine, I know I always get 32-34ms from NAC OCT when everthing is fine, and I know I always get 1.1-1.3ms when Managed.com is fine. This has been true (with the exception of my fairly new managed.com bitch box) for years. Im not trying to make 'wild accusations' I'm wondering if anyone knows why the route would be all of a sudden changed. And google.com IS still hosted.

And about the traceroute, my point exactly. Its supposed to be staying *IN* San Jose, but it doesnt. Only 1.5-2 weeks ago it was 4 or 5 hops to google from my managed.com box with <2ms the whole way.

and hey, look at that. It just started taking the PROPER route again..

1 66.79.178.1 (66.79.178.1) 0.339 ms 0.252 ms 0.214 ms
2 manageddotcom.assertivenetworks.net (66.154.102.1) 0.376 ms 0.268 ms 0.247 ms
3 728.ge-5-1-1.er10a.sjc2.us.above.net (209.66.79.98) 0.398 ms 0.374 ms 0.830 ms
4 so-2-0-0.mpr3.sjc2.us.above.net (64.125.30.89) 0.379 ms 0.486 ms 0.404 ms
5 so-3-0-0.mpr2.sjc7.us.above.net (64.125.30.177) 0.655 ms 0.626 ms 0.546 ms
6 so-3-2-0.edge1.SanJose1.Level3.net (4.68.127.33) 0.590 ms 0.594 ms 0.611 ms
7 216.239.48.94 (216.239.48.94) 2.304 ms 1.604 ms 2.355 ms

Is their San Jose datacenter STILL out of commission? :P

Originally posted by JSH-John
and hey, look at that. It just started taking the PROPER route again..

1 66.79.178.1 (66.79.178.1) 0.339 ms 0.252 ms 0.214 ms
2 manageddotcom.assertivenetworks.net (66.154.102.1) 0.376 ms 0.268 ms 0.247 ms
3 728.ge-5-1-1.er10a.sjc2.us.above.net (209.66.79.98) 0.398 ms 0.374 ms 0.830 ms
4 so-2-0-0.mpr3.sjc2.us.above.net (64.125.30.89) 0.379 ms 0.486 ms 0.404 ms
5 so-3-0-0.mpr2.sjc7.us.above.net (64.125.30.177) 0.655 ms 0.626 ms 0.546 ms
6 so-3-2-0.edge1.SanJose1.Level3.net (4.68.127.33) 0.590 ms 0.594 ms 0.611 ms
7 216.239.48.94 (216.239.48.94) 2.304 ms 1.604 ms 2.355 ms

Is their San Jose datacenter STILL out of commission? :P

I don't know if anything has changed since your post...but, from where I'm sitting it is very dead. Traceroutes from the east coast (home, nocster, etc) die at the routers. Same with servermatrix and ev1.

I see three possibilities here; either 1) There is some kind of problem--again. 2) That IP is not publicly routed anymore and you can access it only because you're in the same DC. or 3) You're making this all up.

Personally I vote for 1, or 2. Something seems screwy...

Haha, why would I make it up? It was someone on these forums that origionally told me that google was in the same datacenter as manged.com was using. :)

Originally posted by JSH-John
Haha, why would I make it up? It was someone on these forums that origionally told me that google was in the same datacenter as manged.com was using. :)

I didn't mean to imply you would, was just trying to give an objective view of possibilities :)

Either way I can't reach that ip from anywhere so one would think its either down or a private address only accessible from a certain location.

Yea, I don't know enough about this stuff to determine why I'd be able to access it and you wouldn't... But regardless, the route is back to normal and I'm satisfied.

Originally posted by JSH-John
Haha, why would I make it up? It was someone on these forums that origionally told me that google was in the same datacenter as manged.com was using. :)
Google and looksmart are both in the san jose MFN/AboveNET datacenter.

Those of us who follow Google have known for a good while now that they aren't using their San Jose datacenter for serving live web pages.

The fact that you're able to ping www-sj.google.com's old IP is probably a side effect of being in the same DC. IMO, whatever route you get to a server that's offline to the rest of the world is a poor gauge of network performance, and no responsibility of managed.com. Time for a new metric.

Don't worry...by the look of it, there's plenty else to complain about with managed.com.

Iam guessing the problem was fixed iam pulling these type of speeds off my managed.com server


HTTP request sent, awaiting response... 200 OK
Length: 78,424,160 [application/zip]

100%[==================================================================================>] 78,424,160 8.44M/s ETA 00:00

20:07:05 (8.44 MB/s) - `testfile.zip' saved [78424160/78424160]


Although i was very disappointed in the downtime they had earlier

Yes, Looks as if the speed improved.

==> PASV ... done. ==> RETR yarrow-i386-disc1.iso ... done.
Length: 660,340,736 (unauthoritative)

21% [======> ] 139,450,400 418.77K/s ETA 20:14

jesus, people. there *was no problem with routing*. hop 5 was the last hop on mfn, where the traffic went from there depends on what google announced as the route.

recommended reading:
* cidr
* bgp v4

paul

Just FYI...Google has shut down the dns (meaning the ability to reach it by www-xx.google.com) for most of it's datacenters now, in what appears to be an attempt to hide the progress of it's latest update.

there ya go :P

yeah. except that has nothing to do with anything. you posted a traceroute that was perfectly fine, made a completely misguided conclusion based on an incorrect analysis of it and proceeded to argue when people with clue pointed out the error.

paul

Originally posted by rusko
yeah. except that has nothing to do with anything. you posted a traceroute that was perfectly fine, made a completely misguided conclusion based on an incorrect analysis of it and proceeded to argue when people with clue pointed out the error.

paul

Wow... someone put on their, "I know everything a$$hole" hat this morning, huh?

Sirius

Originally posted by sirius
Wow... someone put on their, "I know everything a$$hole" hat this morning, huh?

Sirius

that hat is lodged there permanently. i have little patience with people who refuse to understand what is being communicated and choose to make misinformed remarks with the air of technical authority. i am not always suave, please deal with it =]

paul

Did I argue? I'm just a noob that was trying to figure out why the traceroute has taking a route I've NEVER seen it take in the last 2 or 3 years that I've been doing it on a regular basis. If you ask me, MOST people that've posted in this thread realized that when all of a sudden my trace started going back to its normal 7 hops they were completely wrong and stopped posting their aggressive opinions towards what I was saying.

You're just the same, did you even read the rest of the thread? I never said the traceroute was anything other than 'perfectly fine'. It worked perfectly, there was no problem. It was a DIFFERENT route is what I was saying, much different. 5 additional hops different and ~80ms ping different (consistantly) - That is where the problem is. I 'understood' what was being 'communicated' to me (to use your wording) however I wasn't satisfied that the SanJose datacenter was offline so I kept on the topic, and low and behold I WAS RIGHT, its NOT offline! Want proof? Call the toll free # at http://www.abovenet.com and ask them about it.

www.google.com. 1H IN CNAME www.google.akadns.net.

theres no point in tracing google's www. , its akamai'zd and the ip it resolves to can change from time to time, why does that happen? ask akamai.