Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am trying to reach a domain from my business. I am doing a traceroute on the ip:443 and the trace fails after reaching the dns. I am wondering where the error lies.

The last four lines of the trace:

    10  er1-te-3-1.sanjoseequinix.savvis.net (204.70.200.129)  15.641 ms  12.127 ms  14.280 ms
    11  cr1-tenge-0-3-5-0.sanfrancisco.savvis.net (204.70.200.198)  18.039 ms  17.210 ms  18.242 ms
    12  cr2-bundle-pos-1.losangeles.savvis.net (204.70.197.29)  23.199 ms  24.002 ms  27.607 ms
    13  er2-tengig-3-1.lay.savvis.net (204.70.198.10)  24.649 ms  24.145 ms  25.182 ms
    14  phyber.losangeles.savvis.net (208.173.55.226)  30.955 ms  20.603 ms  25.967 ms

share|improve this question

4 Answers 4

What symptoms are you seeing when you try to reach the host?

What do you mean by "doing a traceroute on the ip:443"? Ports are not relevant to traceroute. Can you show us the actual traceroute command you're executing?

Is the traceroute to the DNS server or to the destination host?

I'm also puzzled by "the trace fails after reaching the dns", as a traceroute to a host does not also traverse the DNS server used to resolve the host... Unless the DNS server is also your gateway. Can you clarify this statement a bit?

That trace looks fine, assuming the destination host is 208.173.55.226. Traceroute is actually of somewhat limited utility as it frequently will be dropped when normal TCP / UDP packets for legitimate ports will be accepted. In some cases using tcptraceroute can be illuminating.

share|improve this answer

Just a guess- but try a different DNS. 18.72.0.3 is one over at MIT that has never failed me.

share|improve this answer

According to that trace, you didn't lose any packets...30ms is a pretty reasonable return time.

One clarification though, neither DNS nor traceroute (which uses ICMP), has any knowledge of port 443 (layer 4). Unless you're using a TCP based traceroute, what you may be seeing is tracert converting 443 to an IP address (do you see a message regarding 0.0.1.187?) and then trying to trace to it. Checking the behavior on my windows box, that does appear to happen if you do: tracert valid.ip.add.ress 443 Tracing route to 0.0.1.187 over a maximum of 30 hops 1 * ^C

share|improve this answer

Traceroute is an ICMP diagnostic, and does not always give the same results as a TCP conenction would give. Using tracetcp, which performs a TCP based traceroute can give more information in these cases.

If those are the last four lines (i.e.: No "* * *" lines after) then your traceroute is reaching the destination, so you then need to start seeing why the server is not respnding to a web request - try to telnet to port 80 (http) or 443 (https) to see if you can open connections to the appropriate ports.

telnet remote.server.com 80

If you can't establish a TCP connection then use tracetcp to see when the connection is failing - it could be a firewall at your end or a firewall/dead service/etc at the remote end. Once you know exactly where the packets are failing you can contact the appropriate people. If you can establish a TCP connection on port 80/443, then contact the remote admins as lack of response after that means they have a service listening, but not returning proper responses.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.