12 Oct

UKNOF32 – Analysis of F-root placement using RIPE Atlas

Enjoyed ISC’s presentation about their analysis of F root server (one 13 root DNS servers which power the Internet) about anycast performance gloablly for announced (and anycasted) by AS3557 (ISC). This was presentation at UKNOF 32.

Embedded presentation below (or click here to watch on YouTube directly)


04 Jun

F-root DNS node back up in Chennai!

And finally ACN i.e “Advanced Computer Networks” exam next. Hopefully less to cram in this one and syllabus is pretty interesting. 


Talking about networks – I am very happy to post this update. Finally F root server’s node in Chennai is back up! 

Though ISC did not updated me about this development but anyways I can always assume they were busy in hitting head with India bureaucratic bodies. 🙂

If you are following my blog, you might have seen my past blog post about “Broken connectivity of F root server” due to NIXI’s routing policies. When I informed ISC (root server operator for F root) about it, they took down the Indian anycasting instance in order to work on fix. 


Quoting publically available reply from Mr Leo from ISC on RIPE mailing list in response to my original post about routing glitch:

ISC has experienced a number of routing challenges at our Chennai node over the past year resulting in problems such as this one. We’ve been working with APNIC (the node Sponsor) and NIXI (the node host) to get these resolved. We’ve found the Indian market to be rather unique in the way various large ISP’s chose to announce (or not announce, as the case may be) their routes at various exchanges. In this particular case it appears that the traffic is making it to our Chennai node, but not making it back.

I will work with Anurag directly in the ticket to get this issue resolved. If anyone else is seeing issues in India please mail noc at isc.org to open a ticket. The more reports we have of problems the more attention we can get this issue with the various parties involved.



Here’s updated route:

anurag:~ anurag$ traceroute -a f.root-servers.net
traceroute to f.root-servers.net (, 64 hops max, 52 byte packets
1 [AS65534] router.home ( 1.809 ms 0.915 ms 0.981 ms
2 [AS9829] ( 17.017 ms 18.209 ms 18.170 ms
3 [AS9829] ( 25.560 ms 29.347 ms 26.233 ms
4 [AS9829] ( 87.839 ms 86.766 ms 86.485 ms
5 [AS0] ( 97.747 ms 104.656 ms 98.620 ms
6 [AS55440] f.root-servers.net ( 97.615 ms 97.153 ms 97.531 ms
anurag:~ anurag$


97 ms latency seems OK. Likely should be slightly less but I assume that’s BSNL problem (return path via Airtel) rather then NIXI or F root’s issue. 

I guess Indian instance has been brought up somewhere in mid of April last month (20 days back). I can guess that based on data collected from RIPE Atlas Probe #1032 hosted at my home network along with BGP session details at NIXI’s route server in Chennai.


Screen Shot 2013-06-04 at 8.56.52 PM



It seems like ISC team has done a good job and brought back the node with full connectivity. I can’t blame them for time since it involved Indian bureaucracy. 


Going into some of technical details…


Original Problem

The original problem with this node was because NIXI enforces regional route policy. According to that ISPs are forced to announce regional routes and they have option of announcing or not announcing other region routes. E.g BSNL was participating at NIXI Chennai and announcing it’s South Indian prefixes only and not BSNL Haryana (in North of India) prefixes. Now since BSNL was participating at NIXI and had a BGP session with NIXI’s route server on AS24029, it was getting routes to F root while in return it was NOT announcing BSNL Haryana’s prefixes. 



There could be multiple solution to this problem

  1. ISP’s like BSNL start announcing all prefixes at all NIXI. (Hard because they won’t let others to “use their backbone” by just peering) 
  2. ISP’s like BSNL peer directly with ISC’s router at Chennai and pass their entire table. (Bit hard since number of ISPs & hard to connivence them)
  3. ISC adds transit link defaulting on to transit interface for any non-available routes. It does NOT means announcing F root server prefixes to transit but rather using transit as “default” incase of partial connectivity. 



I think ISC went with #3. F root server uses IP address which comes from subnet announced by AS3557. In India AS3557 sits under another AS24049 of ISC and router on AS24049 connects to NIXI’s shared peering switch on IP 

There was exactly same problem with Netnod’s i root server in Mumbai and they also brought it down after I informed them last year (blog post here). It still seems down. Let’s hope it will be up again very soon.


So that’s all about it. Back to studies for now…


Disclaimer: I work for PCH and part of what we do involves backend DNS hosting. My involvement here is completely out of personal interest about infrastructure in India and has nothing to do with my employeer. All comments are completely personal.