Xeon Software Ltd. Official Blog

If you are unable to connect to your website there are a few things you can try (if you have the time) to help us better diagnose where the problem lies.

Simply put, the more quickly this information is collected the more quickly we can fix whatever is causing almost any issue. Help us help you!

One of the most common causes for customers being unable to connect to their website is they have been blocked by their firewall for too many failed logins (through cPanel, SSH, FTP, e-mail, etc.) To diagnose this, see if you can connect to another website on your server. If you only have one, try connecting to google.com. If you can see other websites on your server, your IP has not been blocked. If you are unable to see all sites on your server, but are able to see google.com, chances are good you have been blocked.

In this case, you can try using a proxy site to view your website. A proxy site will obscure your IP address, thereby circumventing any IP blocks. A popular proxy site is http://www.proxysite.org. If you are able to view your website from there, you may have been blocked by IP address, or there may be network issues between you physical location and ours. To get your public-facing IP address, go to http://www.whatismyip.com and have it ready in your ticket for us to check.

Another common cause of false-positive website downtime is network congestion or outages. A very powerful diagnostic tool for this occurrence is traceroute. Traceroute shows you a visual representation of how your traffic is routing from your local computer to the server. If you need help running a traceroute you can find a helpful knowledge base article at http://www.xeonbd.com/blog/archives/423.

If you see asterisks in your traceroute, those are “lost packets,” which mean there is network congestion or outages at the hop where you see the asterisk. Including traceroute results in your ticket will help us to diagnose where the troubles lies.

If neither an IP block nor network congestion apply, we’ll need to know what error you’re seeing in order to determine the trouble. It could be DNS-related, or Apache might be having troubles serving your pages. Before you send in a ticket, noting what error you’re seeing in the web browser for the specific URL you’re trying to reach will help us more quickly solve the problem.

Your server is only as secure as your weakest password. As a rule of thumb, the more complex a password, the stronger it is.

So, for example,

candy123

would be extremely insecure, whereas

Tmb1W\>r~ii

would be pretty secure.

Generally, insecure passwords:

• Are shorter than eight characters
• Are based almost entirely on dictionary words
• Do not mix in numbers and special characters

Whereas secure passwords:

• Are at least ten characters, if not longer
• Omit dictionary words
• Have a healthy mix of numbers and special characters

While you could research plenty of theory and use it to construct ever more secure passwords, the easiest way to come up with a good password is to use goodpassword.com as a one-stop shop for secure passwords.

Traceroute is an application that traces the path data takes from one computer to another.  Basically a traceroute is a map that shows what stops or locations that data must pass through in order to go from one computer to another.

To be effective troubleshooting tool, the traceroute needs to be run during a time when  the problem is occurring, from a computer that is experiencing the problem.

How do I run a traceroute?

To Run a Traceroute in Windows:

In Windows 98 or ME, Go to “Start” > “Run”. Type “command” and press the “Enter” key.
In Windows 2000, XP, or Vista, go to “Start” > “Run” and type “cmd” and press the “Enter” key.

This will bring up a black command prompt window. It will have a line that looks like this:

C:\Documents and Settings\>

with a cursor blinking next to the “>” symbol.

To run the traceroute, type:
tracert yourdomain.com

Where  “yourdomain.com” is the name of the server that you are having difficulty connecting to. The traceroute process may take only a few seconds or a few minutes. Typically, the farther you are away, geographically, from your target location, the longer the trace will take.

If you have difficulty copying the traceroute information, or if it runs off the screen, you can instead type:

tracert yourdomain.name > C:\trace.txt

This would write the command results to a text file named trace.txt in the root of your C: drive.

To Run a Traceroute on a Mac:

If you have OS X, you can use the built-in network tools. Double-click the Hard Drive icon > Applications folder > Utilities folder > Network Utility program. Select the Traceroute tab and enter the hostname or domain name.

Mac OS X users can also take advantage of the the terminal that is built in to the system. Inside the same Utilities folder described above and open the program labeled Terminal. Once inside the terminal application type in the command ‘traceroute domain.com’. Be sure to leave out the quotation marks and substitute the target server name or IP address instead of domain.com

If you have an older Macintosh, you may need to acquire third party software utility software. Go to http://www.tucows.com and do a search for “Trace” on “Macintosh”. Programs like the ‘DNS Expert Professional’ will allow you to run a “trace route”. Then send us the results for analysis.

To Run a Traceroute on Linux or UNIX:

At the command line, type:
traceroute yourdomain.com
FOR All SYSTEMS:
Please note that yourdomain.com should be replaced with the site is not working for you.

WHAT DOES THE TRACEROUTE SHOW YOU?

Let’s take a few sample traceroute outputs. The first is a successful trace:
Tracing route to xeonbd.com [67.43.13.136]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 10.18.61.1
2 1 ms 1 ms 2 ms 116.193.170.161
3 4 ms 3 ms 1 ms 116.193.169.245
4 5 ms 4 ms 7 ms bgp1.ispros.com.bd [116.193.170.1]
5 3 ms 11 ms 10 ms 123.49.4.41
6 3 ms 2 ms 7 ms 123.49.13.94
7 150 ms 153 ms 150 ms pal9-bangladesh-4.pal.seabone.net [213.144.181.125]
8 195 ms 205 ms 193 ms decix-fra52-racc2.fra.seabone.net [195.22.211.107]
9 187 ms 205 ms 217 ms global-crossing-2-decix.fra.seabone.net [89.221.34.50]
10 324 ms 329 ms 322 ms 64.209.88.186
11 314 ms 305 ms 304 ms lw-dc2-core3-te9-1.rtr.xeonbd.com [209.59.157.224]
12 310 ms 310 ms 313 ms lw-dc2-sec3-dist5-sec3-po1.rtr.xeonbd.com [209.59.157.118]
13 313 ms 310 ms 310 ms 67.43.13.136


It looks like gibberish, right? But it’s actually fairly easy to understand. After the traceroute command, the program tells you what it’s doing;

It’s looked up the domain xeonbd.com,
It found xeonbd.com on the IP address of 67.43.13.136
Now it will now attempt to find its way there.

It will only be able to attempt 30 “hops” (stops along the way, or connections to routers) and it will send a packet of 40 bytes.

The numbers at the far left are the number of the hop, followed by the name and/or IP address of the router that hop is going through. You can see our trace started within the XeonBD network, progressed through AT&T and found its way to msu.edu.

The set of three numbers on the right side of the lines indicate the amount of time, in milliseconds, it took for that hop to complete. Traceroute performs each hop three times.

In this example there are no asterisks (which indicate packet loss) and no inordinately long delays.  If your trace to the server looks like this, you’re in good shape in terms of network connectivity.

Now, let’s look at a traceroute that ends without reaching its destination:
traceroute xeonbd.com
traceroute to xeonbd.com (209.59.139.21), 30 hops max, 40 byte packets
1  lw-dc2-hsrp-vlan132.rtr.xeonbd.com (67.43.8.129)  0.947 ms  1.028 ms  1.101 ms
2  lw-dc2-core4-po2.rtr.xeonbd.com (209.59.157.131)  1.275 ms  1.308 ms  1.385 ms
3  lw-dc1-core1-ge3-5.rtr.xeonbd.com (209.59.157.93)  1.849 ms  1.921 ms  1.980 ms
4  lw-dc1-dist1-ge1.rtr.xeonbd.com (209.59.157.2)  92.082 ms  92.155 ms  92.347 ms
5  * * *
6  * * *
7  * * *
8  * * *
[truncated]

Our trace to xeonbd.com failed because we ran it from our internal network –xeonbd.com is not actually down. It’s just a nice, short example of what a failed trace looks like.

You can see on the fifth hop we have nothing but packet loss. The traceroute continued for the full 30 hops, each reporting * * * as it went. If your trace to the server has many asterisks like this one, that means that the connection was not able to be completed.  This could be for a variety of reasons including:

A network outage
High amounts of traffic causing network congestion
A firewall dropping traffic from your IP

If you see these asterisks once you are inside XeonBD’s network, there may be no need to worry. VPS customers frequently are not able to trace to their instance on the parent server.

Having traceroute’s output ready is an excellent way to help us help you if you are experiencing network issues.