When a routing problemm is indicated, the first thing to do is examine the routing table to make sure that the necessary routes for the local interface and the default route are defined.

  $ route -n 

  This option will display various fields in the routing table and for more info please refer to the Routing section of my document.   In the case of a large routing table, use grep with the route command to search for a default route or a specific route.

  $ route -n | less 

  traceroute traces the route of UDP packets or ICMP echo packets through the network, and lists every router between your computer and the remote host.   It does this by sending out UPD packets with small time-to-live(TTL) values and invalid port numbers to force ICMP errors and to record the sources of those errors.

  $ traceroute vins.vinsky2002.org

  Note that there are three(3) packets sent to each hop(router) along the path.   If a packet is lost ( that is, if no error is returned for the packet ), an asterisk (*) is printed instead of a round-trip time.    If a series of three(3) asterisk is printed on several lines, it indicates that the trace was unable to reach the remote end.

  One row of asterisk is not enough to tell you there is a problem because some routers don't return ICMP errors.   I let four(4) or five(5) lines of asterisk print out before I believe there is a remote routing problem, and then only if ping also fails.   Routing is a two(2)-way street.   If possible, have the administrator of the remote system test the route from the remote server back to your system.