2

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 46.249.37.143 (46.249.37.143), 64 hops max, 52 byte packets
 1  comtrend.home (10.0.0.1)  3.934 ms  0.860 ms  0.775 ms
 2  88.103.200.48 (88.103.200.48)  24.264 ms  24.790 ms  23.823 ms
 3  88.103.203.1 (88.103.203.1)  25.447 ms  25.848 ms  26.754 ms
 4  194.228.190.1 (194.228.190.1)  34.816 ms  27.087 ms  27.312 ms
 5  194.228.190.193 (194.228.190.193)  29.056 ms  27.352 ms  43.560 ms
 6  ae0-0-grtprach1.red.telefonica-wholesale.net.7.16.84.in-addr.arpa (84.16.7.29)  25.538 ms  26.177 ms  25.337 ms
 7  xe3-3-0-0-grtpartv1.red.telefonica-wholesale.net.121.142.94.in-addr.arpa (94.142.121.30)  45.752 ms
    xe-4-0-0-0-grtpartv2.red.telefonica-wholesale.net.121.142.94.in-addr.arpa (94.142.121.34)  104.951 ms  46.658 ms
 8  xe7-0-0-0-grtparix1.red.telefonica-wholesale.net (84.16.14.162)  44.561 ms
    xe7-1-6-0-grtparix1.red.telefonica-wholesale.net (84.16.14.182)  48.202 ms
    xe0-3-0-0-grtpartv2.red.telefonica-wholesale.net (84.16.12.214)  47.801 ms
 9  xe7-0-0-0-grtparix1.red.telefonica-wholesale.net (84.16.14.162)  44.551 ms
    cogent-0-0-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.50)  288.925 ms
    cogent-1-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.134)  158.111 ms
10  cogent-1-0-0-grtparix1.red.telefonica-wholesale.net (213.140.52.134)  198.061 ms
    cogent-7-3-0-grtparix1.red.telefonica-wholesale.net (213.140.52.210)  48.478 ms
    te0-4-0-4.mpd21.par01.atlas.cogentco.com (130.117.1.69)  48.574 ms
11  te0-4-0-4.mpd21.par01.atlas.cogentco.com (130.117.1.69)  50.303 ms
    te0-3-0-5.mpd21.ams03.atlas.cogentco.com (154.54.36.254)  55.350 ms
    te0-0-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.57)  56.176 ms
12  te0-1-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.61)  56.409 ms
    te0-2-0-5.mpd21.ams03.atlas.cogentco.com (130.117.51.65)  55.947 ms
    te7-7.mpd01.ams04.atlas.cogentco.com (130.117.50.226)  56.371 ms
13  149.11.38.30 (149.11.38.30)  57.218 ms
    te8-4.mpd01.ams04.atlas.cogentco.com (154.54.39.106)  55.703 ms
    149.11.38.30 (149.11.38.30)  56.929 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
^C

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

This last IP 149.11.38.30 is (according to http://www.infobyip.com/) 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

2
  • try traceroute -I (thats cap I for india, not l for lemon)
    – Sirex
    Jan 3, 2012 at 11:41
  • 2
    also worth pointing out that machines can block traceroute without being down as well Jan 3, 2012 at 11:55

2 Answers 2

5

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 (http://www.robtex.com). 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 http://www.bgp4.as/looking-glasses) to see if you are the only one having problem to route traffic toward that target network.

1
  • 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) Jan 3, 2012 at 13:58
1

That last IP (149.11.38.30) 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-grtparix1.red.telefonica-wholesale.net

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 telefonica-wholesale.net is the domain.

Let's try another one.

hop 12: te0-1-0-5.mpd21.ams03.atlas.cogentco.com

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 'cogentco.com' 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  te2-1.mpd01.ams04.atlas.cogentco.com (130.117.49.10)  89.837 ms 
te1-7.mpd01.ams04.atlas.cogentco.com (154.54.36.134)  90.029 ms
te4-1.mpd01.ams04.atlas.cogentco.com (130.117.2.66)  93.493 ms
12  149.11.38.30 (149.11.38.30)  94.595 ms  94.891 ms  94.903 ms
13  46.249.37.143 (46.249.37.143)  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 149.11.38.30. Was 149.11.38.30 blocking traffic? Maybe. Or maybe 46.249.37.143 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.

You must log in to answer this question.

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