Posts

In Singapore for APRICOT 2013 from last couple of days.

Very interesting event and a beautiful country. If anyone of the readers of this blog are around - I would be happy to meet!

A quick blog post on a interesting issue coming up due to combined problem of CDN failure on Google Public DNS and bad Akamai performance due to Tata-NTT peering issue.

I was trying Zembra mail since there’s no more free Google Apps edition and one of my friend asked me to basic email on his domain up. It was more or less a straight task by installing Zembra with decent GUI.

An interesting evening here in village. From today sessional tests started at college and so does my blog posts too (to keep myself with positive energy!) ;)

 

Learned something new while troubleshooting. :)

I am used to getting latency of ~350ms with my server in Europe as I have mentioned in my past blog posts.

My connection > Server goes direct but return path goes via US and this is what increases latency. Today all of sudden I saw latency of 200ms with my server. 150ms less - that’s significant.

Just wrote a quick script to pull dump of Picasaweb albums backup on my server & further to Amazon S3. Overall I have good trust on Google for data but it’s always a poor idea to leave all eggs in single bucket.

OK here’s the script (poorly written code. Literally spent 10mins on this, thus suggestions to improve my coding are more then welcome!)

 #!/bin/bash

Destination=<PUT YOUR DESTINATION HERE!>
google picasa list-albums | cut -d"," -f1 » $Destination/tmp/album_list.txt

cat $Destination/tmp/album_list.txt | while read album

do
          google picasa get “$album” $Destination/tmp
done

FileName=PicsBackup-`date ‘+%d-%B-%Y’`.tar
tar -cpzf $Destination/$FileName $Destination/tmp
gpg –output $Destination/$FileName.pgp -r –always-trust –encrypt $Destination/$FileName
s3cmd put $Destination/$FileName.pgp s3://YOUR-AWS-S3-BUCKET-ADDRESS-HERE

rm -r $Destination/tmp/*
rm $Destination/$FileName
rm $Destination/$FileName.pgp

How to use

Simply download Google Cli scripts, and get your Google account working with the installed stack. Also if you need Amazon S3 backup support then install & configure s3cmd. Once you have both of these configured with your account, simple give executable bit to the script & run!

Yesterday it was reported across networking community that Google’s prefixes were having issue due to an Indonesian ISP Moratel AS23947.

Quick analysis

From data logged by routeviews it seems like it wasn’t exactly a prefix hijack. AS23947 did not originated prefixes but rather had a route leak leading to path leak of AS23947 > AS15169. 

Here’s a view of global routing table for Google’s prefix 216.239.32.0/24 at 15:57 GMT on 4th Nov:

One of my friend told me on error coming for http://www.musicindiaonline.com/ which was showing error that website is blocked as per DoT orders. I just checked it now and for now domain is not resolving at all! Quick analysis to see how site is blocked.  

anurag@laptop:$ dig musicindiaonline.com a ; «» DiG 9.8.1-P1 «» musicindiaonline.com a ;; global options: +cmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 23431 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;musicindiaonline.com. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Nov 3 02:31:58 2012 ;; MSG SIZE rcvd: 38 anurag@laptop:$

These days Open DNS resolvers are getting quite popular. With Open DNS resolver I mean resolvers including OpenDNS as well as Google Public DNS.

One of major issues these resolvers suffer is failure of integration with CDN providers like Akamai, Limelight etc. In this post I will analyse sample client site of Akamai - Malaysia Airlines website - http://www.malaysiaairlines.com.  

Looking at OpenDNS, Google Public DNS and my ISP (BSNL’s) DNS resolver for its DNS records:

Super dull time here. No classes going on due to “TCS Placement session” at college and this makes me to sit in my room most of time of my day. 

Yesterday I tested connectivity to all 13 Global Root DNS Servers and found i root was giving issue.

Here’s a my yesterday’s traceroute to i root: 

traceroute to i.root-servers.net. (192.36.148.17), 30 hops max, 60 byte packets
1 router.local (10.0.0.1) 1.470 ms 1.965 ms 2.452 ms
2 117.200.48.1 (117.200.48.1) 26.030 ms 28.857 ms 31.243 ms
3 218.248.173.46 (218.248.173.46) 34.673 ms 37.091 ms 41.025 ms
4 218.248.246.130 (218.248.246.130) 72.853 ms 75.272 ms 77.959 ms
5 * * *
6 * * *

Since i root is another root server hosted within India by NIXI, I was quite sure this was issue again due to NIXI’s regional route enforcement policy along with missing transit link on i root. You can see my last blog post about same issue with F root here.

Time for a quick followup blog post. On 26th April of this year I blogged about broken connectivity of F root server which was hosted in NIXI Chennai. Apart from that blog post, I did informed ISC which operates F root (NIXI was host on behalf of them in India). In my open email on APNIC mailing list, I got a reply from Network Operations Center of ISC that they will verify and will take necessary action. Within 48 hours of that email they figured out root cause and since they couldn’t fix it right at that point, they pulled plug off from that root server.

NIXI i.e National Internet Exchange of India is well known for it’s inefficiency and for its bad policies. I am posting this blog post to discuss some of them.  

Bit of background:

NIXI is one (and only) Indian IXP i.e Internet Exchange Point established in 2003 so as to facilitate peering between Indian ISPs. Before this, there were lot of cases when Indian ISP’s were connecting to each other from outside India in Singapore and Europe. Thus NIXI established few exchanges in key cities where necessary infrastructure was provided to ISP’s to “peer”.  With peering, the strict technical meaning is that exchange of traffic between ISPs.