Hello. After reading about all the complaints from Cobalt Rack users, I have decided to conduct a small test. I am going to find out why users can access cobaltrack.com, but not their own websites. So here is what I need to perform the test. I need:

1. 2 or more CURRENT cobaltrack.com users URL (IP to the server prefered).

2. Type of RaQ you have.

Once I have conducted and finish the test, I will post the results. Thanks.

You have so lost me on what you are talking about :)

I have been reading that people who have RaQ's from cobaltracks.com can't access their servers/websites. However, they CAN access cobaltracks.com. I am going to conduct a test to figure out why this is happening.

Originally posted by JL™
I have been reading that people who have RaQ's from cobaltracks.com can't access their servers/websites. However, they CAN access cobaltracks.com. I am going to conduct a test to figure out why this is happening.

It sounds like the user's servers are down. That is the only logical explanation for why cobaltracks.com would work but servers under their network would not work. Either that or if cobaltracks.com is located on a different network then where they host their servers. I wouldn't understand why they'd do this though ...

Or that their hosted servers are on a different / nested switch that keeps crashing all the time and that is never repaired.

I beleive that makes a lot of sense, I doubt that many people hazve their server crashing all the time. (or it could be a general power failure affecting only their customers... :P)

:D

As cobaltracks explained it to me, it's because their own server is in their old data center and their customers are in the new data center.

Doesn't it seem funny that they have never moved their own server to the new data center.

NO! It shouldn't, they know what they are doing, if they moved their own server over to the new data center then they would be experiencing the downtimes that their customers experience daily.

Bbox

I have been a customer for 1 month or so. My server has been online & fairly reliable so far. Actually, I don't remember any downtime on my server, although the cobaltracks.com site went down for 1 day this month.

Gee... maybe that's because this thread was started last Christmas?

Originally posted by brainbox
As cobaltracks explained it to me, it's because their own server is in their old data center and their customers are in the new data center.

Doesn't it seem funny that they have never moved their own server to the new data center.

NO! It shouldn't, they know what they are doing, if they moved their own server over to the new data center then they would be experiencing the downtimes that their customers experience daily.

Bbox

LOL, I have noticed many web hosts doing this.

1. The Servers all go down bar the hosts site, odd that. lol

Many web hosting companies often do not use their own co-lo network. Why? Conveince and security.

I have consulted for a mid-size co-lo company (~3000 servers) and a small one (250 servers). Both of them used a seperate networks for their own web site. This makes a lot of sense for management and security reasons.

Both companies had fractional T1 lines into their offices to provide a descent pipe into their co-lo (located on the outskirts of town where land was less expensive). By having the corporate servers in the office, access to the corporate servers was simpler and security was higher (techs in co-los are not often directly monitored). I don't know how many of you have actually visited a large co-lo in a tin building with hundres of computers humming and air-conditioning blasting. Not a pleasant place to work; so, many co-lo's have seperate office sites.

Both companies had their corporate web sites on servers that linked to customer databases. If they used their co-lo, then they would have to fetch customer data over the internet increasing bandwith usage and raising security issues. By having the machines in their office, the billing department and techs had fast access to the customer databases.

Cobaltracks.com is on the same ethernet as our customers, has been since March. Before hand it was on the same network but had it's own router so we could create stricker firewall rules...

Sam

Sam

Maybe you can answer this, why when i do a simple wget from the command line, does cobaltracks.com page show up so slow?



root@gary [/etc]# wget cobaltracks.com
--02:11:45-- http://cobaltracks.com:80/
=> `index.html'
Connecting to cobaltracks.com:80... connected!
HTTP request sent, awaiting response... 302 Found
Location: http://www.cobaltrack.com/ [following]
--02:11:49-- http://www.cobaltrack.com:80/
=> `index.html'
Connecting to www.cobaltrack.com:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 12,355 [text/html]

0K -> .......... .. [100%]

02:11:54 (2.41 KB/s) - `index.html' saved [12355/12355]

root@gary [/etc]# wget yahoo.com
--02:12:07-- http://yahoo.com:80/
=> `index.html.1'
Connecting to yahoo.com:80... connected!
HTTP request sent, awaiting response... 302 RD
Location: http://www.yahoo.com/ [following]
--02:12:07-- http://www.yahoo.com:80/
=> `index.html.1'
Connecting to www.yahoo.com:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

0K -> .......... .....

02:12:08 (86.86 KB/s) - `index.html.1' saved [16366]

root@gary [/etc]# wget venturesonline.com
--02:12:38-- http://venturesonline.com:80/
=> `index.html.2'
Connecting to venturesonline.com:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 55,892 [text/html]

0K -> .......... .......... .......... .......... .......... [ 91%]
50K -> .... [100%]

02:12:38 (10.66 MB/s) - `index.html.2' saved [55892/55892]

Gary,

I get it faster:

[root admin]# wget cobaltrack.com
--20:44:56-- http://cobaltrack.com:80/
=> `index.html'
Connecting to cobaltrack.com:80... connected!
HTTP request sent, awaiting response... 302 Found
Location: http://www.cobaltrack.com/ [following]
--20:45:04-- http://www.cobaltrack.com:80/
=> `index.html'
Connecting to www.cobaltrack.com:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 12,355 [text/html]

0K -> .......... .. [100%]

20:45:04 (71.39 KB/s) - `index.html' saved [12355/12355]

I have a few possible answers, but I'd also be interested in knowing what IP the test was comeing from or atleast the ISP so I could see if we did have a conectivity issue. I traceroute would be great :-). Also was that last one from local on the server?
Sam

1. Perhaps the overhead of the HTTP brought down the average try a larger file, try one of the patches found on http://www.cobaltracks.com/patch3.html. These are on the same network as cobaltracks.com but on another cobalt.

2. Do you reverse DNS? If not each packet will be logged by our firewall (A pain I know but we had to do
something about DoS attacks) this will bring the entire TCP connection to a crawl... This DOES NOT affect the
patch server or any of our customers just cobaltrack.com and our DNS servers.


:D

From Germany (Europe) I reach cobaltracks.com really fast

Traceroute from Germany: 127 ms !

traceroute to cobaltracks.com (208.155.69.4), 30 hops max, 40 byte packets
1 Cisco-M-Fe0-0.Space.Net (195.30.0.126) 0.378 ms 0.228 ms 0.328 ms
2 Cisco-INXS-P6-0.Space.Net (195.30.3.205) 0.625 ms 0.595 ms 0.554 ms
3 demun1001-tc-s1-0.ebone.net (195.158.244.133) 1.461 ms 1.533 ms 2.217 ms
4 demun101-tc-r6-0.ebone.net (213.174.68.213) 0.791 ms 0.876 ms 1.049 ms
5 defra202-tc-p9-0.ebone.net (213.174.70.145) 6.827 ms 6.781 ms 6.268 ms
6 chgen102-tc-p1-0.ebone.net (213.174.70.122) 15.286 ms 14.787 ms 15.030 ms
7 chgen101-tc-p3-0.ebone.net (195.158.237.34) 14.901 ms 15.259 ms 14.747 ms
8 frpar301-tc-p5-0.ebone.net (195.158.238.41) 22.068 ms 22.465 ms 22.039 ms
9 frpar302-tc-p2-0.ebone.net (213.174.70.170) 22.119 ms 22.117 ms 21.994 ms
10 gblon304-tb-p3-0.ebone.net (213.174.70.174) 30.974 ms 34.780 ms 30.611 ms
11 usnyk105-tc-p0-2.ebone.net (195.158.229.13) 107.126 ms 107.653 ms 107.526 ms
12 213.174.69.161 (213.174.69.161) 101.300 ms 101.297 ms 105.421 ms
13 ATM1-0.BR1.NYC9.ALTER.NET (204.255.168.121) 104.986 ms 104.972 ms 104.865 ms
14 0.at-6-0-0.XL2.NYC9.ALTER.NET (152.63.18.226) 105.208 ms 105.728 ms 105.360 ms
15 0.so-7-0-0.XR1.NYC9.ALTER.NET (152.63.23.138) 104.999 ms 105.169 ms 105.068 ms
16 0.so-3-0-0.TR1.NYC9.ALTER.NET (152.63.22.98) 105.199 ms 105.067 ms 105.084 ms
17 125.at-7-1-0.TR1.DCA8.ALTER.NET (152.63.9.197) 111.058 ms 111.542 ms 111.144 ms
18 0.so-5-0-0.XR1.DCA8.ALTER.NET (152.63.25.38) 111.377 ms 111.346 ms 111.489 ms
19 POS6-0.GW1.DCA8.ALTER.NET (146.188.162.177) 111.665 ms 111.254 ms 110.986 ms
20 visuallink-gw.customer.alter.net (65.195.226.66) 127.140 ms 127.222 ms 127.004 ms
21 www.cobaltracks.com (208.155.69.4) 126.909 ms 127.037 ms 126.882 ms


Traceroute also from Germany to venturesonline.com:
232 ms

traceroute to venturesonline.com (157.238.46.231), 30 hops max, 40 byte packets
1 Cisco-M-Fe0-0.Space.Net (195.30.0.126) 0.331 ms 0.237 ms 0.211 ms
2 Cisco-INXS-P6-0.Space.Net (195.30.3.205) 0.601 ms 0.560 ms 0.690 ms
3 demun1001-tc-s1-0.ebone.net (195.158.244.133) 0.661 ms 0.653 ms 0.725 ms
4 demun101-tc-r6-0.ebone.net (213.174.68.213) 0.813 ms 0.785 ms 0.818 ms
5 defra202-tc-p9-0.ebone.net (213.174.70.145) 6.598 ms 6.305 ms 6.292 ms
6 chgen102-tc-p1-0.ebone.net (213.174.70.122) 14.899 ms 14.803 ms 14.847 ms
7 chgen101-tc-p3-0.ebone.net (195.158.237.34) 16.366 ms 14.797 ms 14.848 ms
8 frpar301-tc-p5-0.ebone.net (195.158.238.41) 23.401 ms 22.268 ms 22.103 ms
9 frpar302-tc-p2-0.ebone.net (213.174.70.170) 22.211 ms 22.165 ms 22.091 ms
10 gblon304-tb-p3-0.ebone.net (213.174.70.174) 30.605 ms 30.695 ms 30.573 ms
11 usnyk105-tc-p0-2.ebone.net (195.158.229.13) 107.170 ms 107.858 ms 107.276 ms
12 sl-bb20-nyc-13-2.sprintlink.net (144.224.21.193) 107.455 ms 107.396 ms 107.428 ms
13 sl-bb22-nyc-8-0.sprintlink.net (144.232.7.106) 105.819 ms 105.523 ms 105.775 ms
14 sl-bb20-rly-15-0.sprintlink.net (144.232.18.26) 126.359 ms 125.504 ms 125.618 ms
15 sl-gw9-rly-8-0.sprintlink.net (144.232.14.22) 125.319 ms 125.265 ms 125.235 ms
16 p1-1-1.r02.mclnva01.us.bb.verio.net (129.250.9.5) 126.751 ms 126.282 ms 126.514 ms
17 p4-6-0-0.r01.mclnva02.us.bb.verio.net (129.250.2.174) 127.008 ms 126.871 ms 126.776 ms
18 p16-0-0-0.r02.mclnva02.us.bb.verio.net (129.250.5.254) 126.479 ms 126.458 ms 126.495 ms
19 p4-6-1-0.r00.plalca01.us.bb.verio.net (129.250.2.245) 192.039 ms 194.079 ms 191.998 ms
20 p16-0-0-0.r06.plalca01.us.bb.verio.net (129.250.2.161) 192.078 ms 191.916 ms 192.236 ms
21 p16-0-0-0.r04.snjsca03.us.bb.verio.net (129.250.3.162) 192.394 ms 192.468 ms 192.445 ms
22 p4-1-0-0.r00.enwdco01.us.bb.verio.net (129.250.4.2) 232.350 ms 232.465 ms 232.895 ms
23 ge-1-2-0.a00.enwdco01.us.ra.verio.net (129.250.26.130) 232.568 ms 232.402 ms 232.675 ms
24 ge-1-1.a03.enwdco01.us.ra.verio.net (129.250.26.133) 232.470 ms 233.953 ms 232.487 ms
25 157.238.46.231 (157.238.46.231) 232.516 ms 232.735 ms 232.498 ms