As a follow-up to the previous article and prompted by a question in the mailing list, we looked into connectivity of one particular instance of K-root: the one located in Delhi. India.
Prompted by an email from Anurag Bhatia , we looked into connectivity to the K-root instance located in Delhi, India.
RIPE Atlas probes query for the instance name of all root name servers periodically. From this data we distilled all queries that were answered by the instance in Delhi. We also record the round trip time (RTT) for these queries, which is plotted over time in Figure 1 for the 5 probes that we saw querying the Delhi K-Root instance.
Figure 1: Round trip time for queries answered by the New Delhi K-Root node
The image shows that probes 1020 (red) and 1032 (green) have periods where the RTT is around 300 ms. This is far above the average, which seems to lie at about 50 ms.
Looking at traceroute data collected in RIPE Atlas, probe 1020 seems to switch between just these 2 routes:
traceroute to 22.214.171.124 (126.96.36.199), 30 hops max, 38 byte packets 1 192.168.1.1 1.835 ms 1.820 ms 1.603 ms 2 188.8.131.52 25.264 ms 25.523 ms 25.559 ms 3 184.108.40.206 25.591 ms 25.313 ms 25.464 ms 4 220.127.116.11 31.220 ms 30.228 ms 31.039 ms 5 18.104.22.168 31.023 ms 30.416 ms 31.918 ms
traceroute to 22.214.171.124 (126.96.36.199), 30 hops max, 38 byte packets 1 192.168.1.1 18.587 ms 15.286 ms 18.437 ms 2 188.8.131.52 45.546 ms 45.281 ms 36.663 ms 3 184.108.40.206 45.648 ms 25.620 ms 46.263 ms 4 220.127.116.11 302.994 ms 302.111 ms 302.125 ms 5 18.104.22.168 323.703 ms 322.929 ms 322.003 ms
The difference between the two lies in hop 4. In the fast ~30ms case, 22.214.171.124 (BSNLNET National Internet Backbone) seems to hand it over to 126.96.36.199 a host on the national Internet exchange LAN. In the slow case, the same national backbone IP address is followed by 188.8.131.52 (Software Technology Parks of India). The ~300ms round trip time seems to be introduced in this step. In cases like these it would be interesting to have the reverse path, which we can't get from traceroutes from the RIPE Atlas probes, to see if this increase in RTT is caused by the return packets.
If you know of significant network situations where you think RIPE Atlas data can help, you can register for RIPE Atlas after which you have access to data for all public probes. If there are network situations that you think are interesting to have analysed for the community, please leave a comment under the article or contact us at ripe-atlas at ripe dot net. We can then look into this and produce a short RIPE Labs article in response.