Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At first, I'm not able to name my question properly, so this will be adjusted

I recently experienced an international network gap. Mean when some part of world wide network is unavailable.

I'm able to find out using ping,traceroute,nmap tools where the gap occurs and where are my requests thrown away or discarded.

example of recent gap:

traceroute to (, 64 hops max, 52 byte packets
 1  comtrend.home (  3.934 ms  0.860 ms  0.775 ms
 2 (  24.264 ms  24.790 ms  23.823 ms
 3 (  25.447 ms  25.848 ms  26.754 ms
 4 (  34.816 ms  27.087 ms  27.312 ms
 5 (  29.056 ms  27.352 ms  43.560 ms
 6 (  25.538 ms  26.177 ms  25.337 ms
 7 (  45.752 ms (  104.951 ms  46.658 ms
 8 (  44.561 ms (  48.202 ms (  47.801 ms
 9 (  44.551 ms (  288.925 ms (  158.111 ms
10 (  198.061 ms (  48.478 ms (  48.574 ms
11 (  50.303 ms (  55.350 ms (  56.176 ms
12 (  56.409 ms (  55.947 ms (  56.371 ms
13 (  57.218 ms (  55.703 ms (  56.929 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *

icmp_echo gave me request timeout, so I traced the request to (which is my VPS)

This last IP is (according to located in Washington DC, USA. Does it mean, that in Washington, they're blocking traffic to this network node or what?

  • First, I wonder, if we can trace to where and who specific IP was allocated
    • I tried RIPE DB Query, but I wonder if this is the right way
    • I know about reverse DNS query, but this is what traceroute does automatically
  • Second, If there is any world wide network monitoring system, where we can find out if there is any maintenance or network problem
    • I tried RIPE Atlas, where status of some (every? public?) nodes is displayed on map
  • Third (from question title), if we can somehow detect why this outage occurred
    • If it was some kind of bgp routes change or whatever it can be (I honestly don't know what reasons can be there)

Please excuse my language skills, I'm not sure if everything is laid down correctly and clearly. Ask if anything is unclear. Thanks

share|improve this question
try traceroute -I (thats cap I for india, not l for lemon) – Sirex Jan 3 '12 at 11:41
also worth pointing out that machines can block traceroute without being down as well – anthonysomerset Jan 3 '12 at 11:55
up vote 4 down vote accepted

Reverse-DNS to gather the 'owner' of an IP really isn't the way to go. The reverse tables are most often not updated by IPs provider and doesn't provide much in term of diagnostic. (This is different in the email world - as filtering rules are often added to determine the validity of reverse lookup).

To get the 'block owner', you should go to the attribution authority. RIPE is only 1 of 5 Regional Internet Registry (RIR). AfriNIC, ARIN, APNIC, LACNIC are the others one. Their WHOIS tables are SUPPOSED to be up-to-date and give you the official owner & some contact informations.

For more in depth investigation, I like ROBTEX ( It shows you the owner (as per their own database) along with its registered peers and AS numbers (required for BGP).

For outage detection, things get a little more tricky as 'Internet' isn't really that 'big homogeneous network' everybody seems to think it is. Your route toward a single IP depend on your upstream and all the peer along the way. Normally, a outage should be automatically detected and 'next available peer' used, but...

The easiest way to detect that kind of problems would be to use "Looking Glasses" (such as to see if you are the only one having problem to route traffic toward that target network.

share|improve this answer
thanks, looks like this outage was just malfunctioned switch on the route. Not the one from big nodes, the smaller one on data center side. But I'm going to test suggested tools on next outage (which are quite common in here) – Marek Sebera Jan 3 '12 at 13:58

That last IP ( is actually not in washington DC. Providers don't generally register each IP of their backbone devices because when they move links around etc, there's no need to register them. Also, a lot of the usual tricks for determining location (see where people using that IP ship things to using amazon) don't work for routers - they don't usually buy things.

For Telefonica, the first ISP, you have to decode it a little bit. Let's go from left to right, with hop 9 as an example.

xe-7-0-0-0 is an interface name, XE means 10gigabit ethernet on a juniper, and 7-0-0-0 is the slot and port.

grtparix1 is a combination of the router name 'grt' and site 'parix1'. grt is just noise in this context, but 'parix1' is a hint that this router lives in PARIX, which is a large interexchange site in Paris.

.red. is spanish for network, so that's telling you that's part of the customer/revenue network

and is the domain.

Let's try another one.

hop 12:

te0-1-0-0-5 is again ten gigabit ethernet (but maybe not a juniper, as it's te vs xe' and the slot and port designation

mpd21 is the particular device name ams03 is the site name - guessing this is most likely in Amsterdam (from AMS) and atlas is the 'backbone network' subdomain, with '' being the large domain'

Unfortunately, every provider has a different scheme, but they generally use some useful code scheme that isn't impossible to figure out - usually 3 or 4 letters. Some providers use airport codes, and some make up their own.

In order to find out what's wrong, you need to compare a working traceroute with a non-working one. I traced to the same IP you did and got this at the end:

11 (  89.837 ms (  90.029 ms (  93.493 ms
12 (  94.595 ms  94.891 ms  94.903 ms
13 (  91.821 ms  90.328 ms  90.380 ms

In this case, the trace succeeded, and all we can tell from your trace above is that yours ended after Was blocking traffic? Maybe. Or maybe was unable to send packets back to you - either because of a failure or because of a misconfiguration. Remember, traceroutes and pings have to go both ways, and it's not always apparent who is at fault, it can get murky sometimes.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.