Tag Archives: F Root Server

27 Apr

Cloudflare hosting F root server

A few days some folks in internet community noticed Cloudflare AS13335 announcing F root server’s routes covering prefix 192.5.5.0/24.

 

 

Above tweet shows that case is clearly not a mistake but rather some sort of arrangement between Cloudflare and ISC (which is responsible for F-root). There was another discussion on DNS-OARC mailing list here.

From our bgp.he.net tool, one can analyse route propagation for F root’s AS3557.

 

Here we can see that routes are visible from AS13335 to Telefonica AS13335. One can safely assume that AS12956 (considered to be a Tier1 / transit free network as per list here) is not a customer of Cloudflare. So the fact that still route is being announced to Telefonica gives an impression that AS3557 is downstream of Cloudflare.

It’s hard to say on the kind of arrangement as I still see many of instances of F-root are being hosted directly by ISC from hostname.bind query triggered via local RIPE Atlas probes in those regions. It could be that Cloudflare is hosting a part of this setup say in developing region where they have their caching PoPs. Yet to see a detailed blog post from Cloudflare about it. (I like their detailed blog!)

 

Update: 2nd April 2017 

Henry from Cloudflare pointed me to their official announcement blog post written after around 5 months of this post. You can find their official announcement here.

20 Aug

F root server transit in Chennai

Few days back I noticed F root server (which is with ISC) brought it’s anycasted node in NIXI Chennai back live. They have taken that down as per my interaction with them over mailing list. My last post about F root coming back live was with guess work on who’s providing upstream.

 

Today I spent sometime in finding who’s providing transit to that node. It is very important to note that most of these key infrastructure related nodes rely on peering for most of traffic but a transit in form of full table or default stays so that one can push packets to a route if it is not in table learnt from peering. In case of Indian deployment which was at NIXI Chennai – many ISPs were following “regional routes” clause of NIXI and were announcing just their regional routes (to ISC’s F root router) but quite a few of them (like BSNL) were still learning routes from one region and exporting them into their other region via their IGP. This brought case where my router (sitting on BSNL link) was getting a forward path to NIXI Chennai for F root but there was return path from F root to my system because BSNL wasn’t announcing Northern prefixes in Chennai based NIXI.

As I noted earlier F root is back live in India and I am getting consistant and direct routes. It seems very much the case of addition of transit on that node. Today I was looking at global table dump and I came across some interesting routes which revealed who is probably the transit for ISC’s F root in India. 🙂

 

 

F root server uses IP 192.5.5.241 which comes under BGP announcement of 192.5.5.0/24 as well as 192.5.4.0/23 from quite a few autonomous system numbers of ISC. In India ISC is announcing 192.5.5.0/24 from AS3557. It seems like ISC does not uses AS3557 for direct peering with external networks but instead it peers with other ASNs of ISC. In ISC’s worldwide deployment of F root it seems like there are as many as 15+ ASNs with direct peering/upsteram for AS3557. In case of India AS24049 is used by ISC for inter-connection with external networks.

 

Here’s a routing table entry from NIXI Chennai:

 

show ip bgp 192.5.5.241
Number of BGP Routes matching display condition : 1
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.5.5.0/24 218.100.48.142 10 100 0 24049 3557 i

 

Looking into global IPv4 table from Orgeon route-views for AS24049 routes, we get:

route-views>sh ip bgp regexp 24049$
BGP table version is 911752723, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
* 203.119.18.0 12.0.1.63 0 7018 6453 4755 37986 24049 i
* 193.0.0.56 0 3333 3356 6453 4755 37986 24049 i
* 208.74.64.40 0 19214 174 6453 4755 37986 24049 i
* 154.11.11.113 0 0 852 3257 6453 4755 37986 24049 i
* 128.223.253.10 0 3582 3701 3356 6453 4755 37986 24049 i
* 157.130.10.233 0 701 6453 4755 37986 24049 i
* 164.128.32.11 0 3303 6453 4755 37986 24049 i
*> 66.110.0.86 0 6453 4755 37986 24049 i
* 208.51.134.254 2523 0 3549 6453 4755 37986 24049 i
* 203.181.248.168 0 7660 2516 6453 4755 37986 24049 i
* 144.228.241.130 0 1239 6453 4755 37986 24049 i
* 114.31.199.1 0 0 4826 6939 1299 6453 4755 37986 24049 i
* 206.24.210.102 0 3561 6453 4755 37986 24049 i
* 194.85.102.33 0 3277 3267 174 6453 4755 37986 24049 i
* 217.75.96.60 0 0 16150 1299 6453 4755 37986 24049 i
* 202.232.0.2 0 2497 6453 4755 37986 24049 i
* 207.172.6.20 0 0 6079 3356 6453 4755 37986 24049 i
* 207.172.6.1 0 0 6079 3356 6453 4755 37986 24049 i
* 4.69.184.193 0 0 3356 6453 4755 37986 24049 i
* 66.59.190.221 0 6539 6453 4755 37986 24049 i
* 194.85.40.15 0 3267 9002 6453 4755 37986 24049 i
* 154.11.98.225 0 0 852 3257 6453 4755 37986 24049 i
* 69.31.111.244 3 0 4436 3257 6453 4755 37986 24049 i
* 202.249.2.86 0 7500 2516 6453 4755 37986 24049 i
* 89.149.178.10 10 0 3257 6453 4755 37986 24049 i
* 129.250.0.11 6 0 2914 6453 6453 4755 37986 24049 i
* 216.218.252.164 0 6939 1299 6453 4755 37986 24049 i
* 203.62.252.186 0 1221 4637 6453 4755 37986 24049 i
* 66.185.128.48 7 0 1668 6453 4755 37986 24049 i
* 209.124.176.223 0 101 101 3356 6453 4755 37986 24049 i
* 134.222.87.1 0 286 6453 4755 37986 24049 i
* 207.46.32.34 0 8075 6453 4755 37986 24049 i
route-views>

 

And here we go!

 

AS37986 i.e Tulip Telecom seems to be transit. I think this is not case of any route leak – it’s just that Tulip telecom is providing transit.

 

route-views>sh ip bgp regexp 24049 3557

route-views>

 

 

Clearly there’s no announcement of F root prefix directly to Tulip which seems good to avoid any external (outside India) traffic hitting Chennai node. I am quite sure that default on router of AS24049 (or likely AS3557) does points to Tulip’s gateway.

Here we can see the sites under their management subnet – http://route.robtex.com/203.119.18.0-24—internet-systems-consortium.html#sites

 

Well, thanks to Tulip telecom for helping to bring F root node back live. 🙂

 

 

Disclaimer: This is my personal blog and post is completely a reflection of personal thoughts. It has no relation with my employer. 

26 Apr

Broken connectivity to F root server in India

It has been an interesting week at village – dry weather, (ultra) dry classes, (boring) external seminars and more of depressing environment but one can always find some hope out of such depressing environment. Overall life here is colourful but one just needs to lookout for colours. 🙂

 

One interesting case to report today – F root server has quite bad connectivity in India. Last week a friend asked me for traceroutes to all root servers and here’s what I saw when I did traceroute for F root from BSNL connection:

traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.508 ms 2.103 ms 2.614 ms
2 117.207.48.1 (117.207.48.1) [AS9829] 27.243 ms 29.811 ms 32.483 ms
3 218.248.173.42 (218.248.173.42) [AS9829] 39.861 ms 40.320 ms 40.755 ms
4 218.248.250.142 (218.248.250.142) [AS9829] 90.778 ms 93.919 ms 95.856 ms
5 * * *
6 * * *
7 * * *
8 * * *

 

There’s no route! 

 

This is not a overnight problem. I looked at my hosted RIPE Probe #1032 data and found this:

 

 

 

 

How can an ISP like BSNL can have missing route to one of key part of core Internet infrastructure?

 

Quick look at F root server:

 

 

F root server has a anycasting node deployed in Chennai, Tamil Nadu, India. This server is hosted at National Internet Exchange of India (NIXI) Chennai and ISC is responsible for this root server.

F root uses 192.5.5.241 across all anycasting instances and in India this block is being announced by Autonomous System Number 24049 which is of ISC. AS24049 does a BGP announcement for  203.119.18.0/24 at NIXI Chennai and this is “supposed to be” taken by all ISPs participating at Chennai IXP.

 

When I requested my friends across India for traceroutes to F root, it was a very interesting result!

We found connectivity works from everyone  including BSNL too for people living in or near around Chennai.

 

 

Here’s a traceroute from my friend in Chennai on BSNL to F root:

 

traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 3.328 ms 3.311 ms 4.616 ms
2 59.92.64.1 (59.92.64.1) 32.489 ms 36.188 ms 37.448 ms
3 218.248.255.2 (218.248.255.2) 45.312 ms 48.171 ms 51.017 ms
4 218.248.250.142 (218.248.250.142) 63.279 ms 66.086 ms 69.025 ms
5 218.100.48.142 (218.100.48.142) 71.112 ms 72.939 ms 76.107 ms
6 192.5.5.241 (192.5.5.241) 79.131 ms 44.760 ms 46.550 ms

 

Here we can see hop 4 is core network of BSNL while hop 5 is NIXI Chennai and hop 6 is ultimately F root server.

Initially I got feeling that this is because of broken IGP implementation for BSNL network since their border gateway routers are holding different routing tables and they are not syncing them properly but one strange thing here – Hop 4 in this traceroute i.e 218.248.250.142 is same as last hop in 1st traceroute (done from BSNL Haryana). How come same router has no route when looked from Haryana while it works for Chennai (and nearby) users!

This gives clue that forward path is there but return path has issues. For some reason ISC router in NIXI Chennai is not able to get return path to reply for non-Chennai region users.

I raised this concern with Network Operations Center of ISC yesterday along with mailing lists like APNIC & RIPE Atlas. One of my friend who is expert into these issues pointed us to right direction which is NIXI routing policy.

 

Reading out policy:

” An ISP at any NIXI node must at a minimum announce all its regional routes to the NIXI router at that NIXI location. All ISPs connecting to that NIXI node are entitled to receive these routes using a single BGP session with the NIXI router. This will guarantee the exchange of regional traffic within a NIXI node. This is referred to as forced regional multi-lateral peering under the policy”

 

So this is what is happening:

Each operator is providing ISC with limited regional routes around Chennai area and not to it’s entire network. This was later confirmed by ISC NOC reply. This is sort of awful situation in terms of policy which is breaking India backbones badly and ISPs not able to even reach root servers instances hosted within country. Worst, I have been told that there is 10 day time for fix of this problem else ISC is prepared to pull off plug from Chennai F root node. Since it’s anycasting, once there won’t be any instance inside India injecting routes, traffic will simply start flowing towards other F root server instances in nearby countries. If this happens, it will be surely a sad thing for India since we will loose one out of three four root nameservers. 🙁

 

With hope that next update on this issue will be positive, time to end this post for now. Feel free to share your comments below.

(Incase your are ISP or datacenter in India – I would be happy to discuss this issue with you. You can contact me directly from here)

 

 

***Updates***

 

ISC Network Operations Center acted very efficiently on this issue.  Special thanks to Mr Leo Bicknell from ISC who is taking care of it. In initial phase full routing table was made available to F root server via STPI Internet transit. This fixed the problem (on test basis) and after a week of testing,  F root instance in Chennai has been switched off until ISC & NIXI get into a contract over additional bandwidth and costs.

For now Indian traffic is being routed to other anycasting instance of F root. Earlier it was California, US instance and now it is Hong Kong instance.

traceroute to f.root-servers.net. (192.5.5.241), 30 hops max, 60 byte packets
1 router.local (192.168.1.1) [AS8151/AS28513] 2.536 ms 2.799 ms 3.624 ms
2 117.200.48.1 (117.200.48.1) [AS9829] 29.778 ms 32.488 ms 34.677 ms
3 218.248.173.38 (218.248.173.38) [AS9829] 36.966 ms 43.283 ms 44.119 ms
4 59.163.207.81.static.chennai.vsnl.net.in (59.163.207.81) [AS4755] 189.973 ms 192.398 ms 195.118 ms
5 ix-4-2.tcore1.CXR-Chennai.as6453.net (180.87.36.9) [*] 199.965 ms 202.296 ms 203.396 ms
6 if-5-2.tcore1.SVW-Singapore.as6453.net (180.87.12.53) [*] 206.915 ms if-3-3.tcore2.CXR-Chennai.as6453.net (180.87.36.6) [*] 166.267 ms if-5-2.tcore1.SVW-Singapore.as6453.net (180.87.12.53) [*] 160.231 ms
7 if-2-2.tcore2.SVW-Singapore.as6453.net (180.87.12.2) [*] 161.044 ms if-5-2.tcore2.SVW-Singapore.as6453.net (180.87.15.69) [*] 164.876 ms 167.178 ms
8 Vlan1870.icore1.HK2-HongKong.as6453.net (180.87.15.61) [*] 217.994 ms Vlan1779.icore1.HK2-HongKong.as6453.net (180.87.15.38) [*] 216.922 ms Vlan1870.icore1.HK2-HongKong.as6453.net (180.87.15.61) [*] 218.664 ms
9 isc2-FE.hkix.net (202.40.161.200) [AS2687/AS4862/AS9498/AS10026/AS1221] 206.692 ms 208.920 ms isc1-FE.hkix.net (202.40.161.202) [AS2687/AS4862/AS9498/AS10026/AS1221] 211.561 ms
10 f.root-servers.net (192.5.5.241) [AS55440/AS3557/AS23708/AS8167] 247.908 ms 252.645 ms 253.544 ms

 

 

I am looking forward towards permanent fix and will update here once I get updates or find any further changes in the routing tables.