3

We rent a server in Czech Republic where our web site is running.

When I trace it from USA, India, Russia or Ukraine everything is working fine, trace log shows that querying reaches the hosting company's router. So the site is very well accessible from all these countries.

However when tracing from Finland querying reaches the node in Czech Republic (xe100-5.RT.STL.PRG.CZ.retn.net [87.245.233.182]) and stops displaying timeouts. I suppose this node has nothing to do with the hosting company. As a result guys in Finland are not able to gaze on our gorgeous web site :)

Two things confound me:

Firstly, tracing from India passes through the very same Czech node, IP addresses do match. However tracing goes further and reaches hosting company's router, which is not the case from Finland. How this could happen?

Secondly, users in Finland carried out tracing from within their corporate network. However, when one of the employees tried it from home, the site was accessible just fine, so I suppose tracing was fine as well.

The worst thing is that helpdesks on both sides point me to each other stating that the problem is beyond their area of responsibility.

UPDATE:

I've got reply from RETN who controls RT.STL.PRG.CZ router

As can be seen from our looking glass (http://lg.retn.net/), the next hop after RT.STL.PRG.CZ towards you IP address in Czech Republic would be GW1-HostTelecom.retn.net (87.245.246.98) — AS51248 border.

As can be seen from the second trace, they do not use us to reach the IP address in Finland.

I'd suggest looking into AS1759 for the source of the problem.

*second trace means trace back from the server in CR to the client's IP address in Finland

and now wondering how they come to a conclusion that the AS which successfully transferred traffic can be responsible for the issue while their router that blocked everything is not to blame.

Second question is how I can contact any responsible person pertaining to AS1759, please point me to a common way of translating ASN to email.

Finally, why RETN treats it as a problem that back trace goes via different route? Is it really a symptom of routing issue?

Improve this question
5
  • 1
    The ability to perform a traceroute to a system has zero bearing on whether or not users will be able to access TCP port 80.
    – EEAA
    May 29, 2012 at 16:15
  • @ErikA This is understood of course. However if trace can't reach the destination then the server will not be accessible regardless of any open ports, right?
    – Mooh
    May 29, 2012 at 16:29
  • 2
    @mooh, no. A node in the middle could easily block ICMP, which would cause traceroute to fail, but not TCP Port 80. The vice-versa could also be true with a node blocking TCP Port 80 but not ICMP. If a route cannot be found, that's another story, but that's very unlikely here.
    – Chris S
    May 29, 2012 at 16:40
  • @Mooh No, that's not necessarily true. Traceroute uses ICMP, which is commonly blocked however, not usually by intermediate routers like in your case.
    – Richard Keller
    May 29, 2012 at 16:40
  • @Richard Which traceroute? tracert on Windows uses ICMP by default. traceroute on most other systems uses UDP by default. Both are useless for testing TCP connectivity to a web server. I tend to use tcptraceroute or nmap --traceroute instead.
    – Gerald Combs
    May 29, 2012 at 17:37

2 Answers 2

Reset to default
3

Possible rare cause: BGP propagation issues

It's possible that particular autonomous system is unreachable from another due to misconfiguration, filtering errors, or a financial posturing match. I've only encountered this once on my residential link, but I'm sure my ISP was a bit befuddled when I escalated that up enough that somebody understood.

Take a look at some looking glass servers and see if you can find anything odd about how the system in question is propagating its address.

Improve this answer
1
  • I am not an expert in networking, could you please explain in a bit more details what I should look at? An example of an 'odd thing' would be helpful.
    – Mooh
    May 31, 2012 at 6:05
0

While this is odd, you should remember that your ability to traceroute or ping doesn't necessarily mean you won't be able to access certain ports or protocols on the remote server. A more accurate tool to test whether some ports are in fact being blocked (and more specifically, at which hop), try using traceproto. It's not usually installed by default, but it's a common enough tool to be easily installable through your distro's package management system.

For a quicker way of testing port and/or service availability without caring about which hop is dropping the packets, you could just use nmap.

I suggest providing your corporate network's ISP with the trace output, in addition to showing them the trace output from another source that is able to access the destination through the same hop. They should be able to provide you with a reason, and if not, you should ask them to investigate further as it's in their best interest to ensure that their IP ranges are not being blocked anywhere.

Improve this answer
1
  • Do you mean that ICMP packets can be blocked at some hop based on where they are coming from and depending on the ISP network configuration?
    – Mooh
    May 29, 2012 at 17:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .