Posts

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. :)

This Sunday I was looking at global routing table dump and found AS1 announcing some very weird prefixes.

AS1 i.e Autonomous System Number 1 belongs to Level3 but as far as I know they are not actively using it. They use AS3356 globally (along with Global Crossing’s AS3549). I noticed quite a few prefixes of a Brazil based telecom provider - Netvip Telecomunicaes being announced by AS1. 

Some of entries in global routing table belonging to AS1 (as picked from BGP table dump of route-views archive):

It has been few days since I am out of college. Was trying to put this blog post but wasn’t getting time for that. Earlier this month I visited Radaur with my father and vacated my room. It was an interesting experience of staying in that room for a while and working on so many things from there. This is how my room used to look like: Overall time was a long time and an experience full of surprises, fun times, bad times, very bad times and more importantly learning about life. In terms of learning - I learned bit of technical stuff related to networking, along with non-technical learning like understanding how world works, what makes people work, what makes people not to work etc. :)

Today I spotted some routes from Amazon AWS Cloud services -  AS16509 in Indian tables. AS16509 was originating prefixes while sitting in downstream of Tata-VSNL AS4755 and Reliance AS18101. I almost missed Amazon AWS's announcement on their blog about Indian PoPs for their DNS service - Route53 and CDN service - Cloudfront.

New PoP’s of Amazon in India are at Mumbai and Chennai and I see pretty much consistent BGP announcements to Tata and Reliance from these locations. Prefixes I have seen so far:

Sometimes we see interesting IP’s in traceroute & they confuse lot of people.

I have seen this topic in discussion twice on NANOG and once on Linux Delhi user group. 

OK - let’s pick an example: 

anurag:~ anurag$ traceroute 71.89.140.11
traceroute to 71.89.140.11 (71.89.140.11), 64 hops max, 52 byte packets
1 router (10.10.0.1) 1.176 ms 0.993 ms 0.941 ms
2 117.220.160.1 (117.220.160.1) 20.626 ms 29.101 ms 19.216 ms
3 218.248.169.122 (218.248.169.122) 23.983 ms 43.850 ms 45.057 ms
4 115.114.89.21.static-mumbai.vsnl.net.in (115.114.89.21) 118.094 ms 81.447 ms 66.838 ms
5 172.31.16.193 (172.31.16.193) 115.979 ms 90.947 ms 90.491 ms
6 ix-4-2.tcore1.cxr-chennai.as6453.net (180.87.36.9) 95.778 ms 98.601 ms 98.920 ms
7 if-5-2.tcore1.svw-singapore.as6453.net (180.87.12.53) 321.174 ms
if-3-3.tcore2.cxr-chennai.as6453.net (180.87.36.6) 331.386 ms 326.671 ms
8 if-6-2.tcore2.svw-singapore.as6453.net (180.87.37.14) 317.442 ms
if-2-2.tcore2.svw-singapore.as6453.net (180.87.12.2) 334.647 ms 339.289 ms
9 if-7-2.tcore2.lvw-losangeles.as6453.net (180.87.15.26) 318.003 ms 328.334 ms 309.234 ms
10 if-2-2.tcore1.lvw-losangeles.as6453.net (66.110.59.1) 306.500 ms 326.194 ms 341.537 ms
11 66.110.59.66 (66.110.59.66) 315.431 ms 330.417 ms 308.372 ms
12 dls-bb1-link.telia.net (213.155.136.40) 354.768 ms 344.360 ms 357.050 ms
13 chi-bb1-link.telia.net (80.91.248.208) 352.479 ms 358.751 ms 359.987 ms
14 cco-ic-156108-chi-bb1.c.telia.net (213.248.89.46) 367.467 ms 370.482 ms 377.280 ms
15 bbr01aldlmi-bue-4.aldl.mi.charter.com (96.34.0.98) 387.269 ms 385.362 ms 365.694 ms
16 crr02aldlmi-bue-2.aldl.mi.charter.com (96.34.2.11) 375.275 ms 375.356 ms 371.621 ms
17 dtr02grhvmi-tge-0-1-0-0.grhv.mi.charter.com (96.34.34.83) 383.539 ms 371.817 ms 383.804 ms
18 dtr02whthmi-tge-0-1-0-0.whth.mi.charter.com (96.34.34.85) 384.400 ms 391.197 ms 393.340 ms
19 dtr02ldngmi-tge-0-1-0-0.ldng.mi.charter.com (96.34.34.87) 371.192 ms 375.679 ms 378.457 ms
20 acr01mnplmi-tge-0-0-0-3.mnpl.mi.charter.com (96.34.40.75) 364.824 ms 385.534 ms 374.401 ms
21 * *^C
anurag:~ anurag$

Let’s try pinging IP on 14th hop (which is with a major backbone Telia) - 213.248.89.46

Today I noticed some traffic on my blog from a link from Broadband forum. 

Here’s what poster wrote:

I made a thread a few days ago complaining about BSNL’s horrible routing. Well it looks like it has been fixed. I thank all the guys who made efforts to bring this to BSNL’s notice. Especially Anurag Bhatia who highlighted the issue with much detail on his blog

Softlayer connectivity problem and possible fix.

Exam days still going and a few more to go. Before I go further on actual blog topic, a small story to share.  

“Being a Superman” story ;)

Recently it rained quite heavily in Radaur and I was trapped in a situation where stairs to my room got in touch with live grid electricity due to a badly insulated wire joint.  Stairs are made of metal and that brought this dangerous situation. I was informed about “current in stairs” from someone living in neighbourhood who accidentally touched stairs while it was raining. Next, I had to get down from there to go to my home. There was just no other option, and waiting for an electrician to figure it out was impractical idea. There was no option of turning down main power switch since leak was before switch in main line. At this point I gave some engineering thoughts.

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. 

It’s late night here in India. I am having final 8th semester exams and as usual really bored! 

Though this time we have interesting subjects but still syllabus is pretty boring spreading across multiple books, notes and pdf’s. Anyways I will be out of college after June which sounds good.

Tonight, I found a routing glitch. Yes a routing glitch!! :)

These issues somehow keep my life in orbit and give a good understanding on how routing works over the Internet.

And finally academic session over. Done with all vivas and related stuff. Next will be exams likely in June. Time for me to get ready for travel. :)   Anyways an interesting topic for today’s post - Google Public DNS. Lot of us are familier with popular (and free) DNS resolvers 8.8.8.8 and 8.8.4.4. I have covered reason in previous posts on why it tends to fail with Content Delivery networks like Akamai which rely on anycasting at bottom DNS layer and simple unicasting on application servers. Anycasted DNS nodes point to application servers based on various factors like distance, load, cost etc out of interesting algorithms these CDN networks use for load & cost management.   Anyways today’s post focus is not CDN issues with these resolvers but Google Public DNS itself. Are these servers located in India and everywhere else where Google has PoPs?   Let’s do a simple trace to get forward path from Airtel to Google’s 8.8.8.8: