Posts

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.    

Yesterday I spent sometime in answering questions on Google Apps forum. I really love this forum as I used to post a lot there. These days I don’t get much time for forum involvement.

Anyways, yesterday I came across very interesting post from a user named Sandip. He got an error from Google’s DNS checking in the Google Apps Toolbox.

Error:

Presence of mail server on A record of your domain can lead to subtle and hard-to-debug problems with mails ‘accidentally’ missing in case of DNS problems. You can check this problem yourself by typing

I was just working (and playing music!) and realized that “Movie player” package given on default Ubuntu installation isn’t of much use. 

Decided to uninstall it, next needed arping for some test and installed it (via default debian repository). Something crazy happened here. I opened something on personal server and it gave DNS error. I shot couple of digs from terminal and all timed it. I was scared to hell thinking of DNS failure on personal domain which is very very unlikely since I am using multiple DNS providers and close to a dozen of servers serving DNS zone. 

Yesterday I had a discussion with a friend from Airtel after long time. For some strange reason discussion topic was changed to old statements from Bharti Airtel’s executives that companies like Google, Facebook, Yahoo etc should pay to ISPs like Airtel for “data interconnection”. The argument goes more for Google then any other company. Statements from Airtel can be found here and here. 

The argument?

Companies like Airtel who have built a “physical infrastructure” feel that companies like Google should pay to them since they are putting so much of traffic on their networks. Airtel feels that services like YouTube take significant amount of bandwidth and thus requires and infrastructure from core, middle mile to edge part of network and all that needs significant investment. Similarly there was another argument from Mr Sunil Mittal about fact that Facebook is enjoying on top of infrastructure which ISPs like Airtel have created.

Quick analysis of BSNL-Level3 bad routing issue

I can see BSNL having pretty high latency again with most of Europe again. It seems like they are using Level3 Communications AS 3356 along with Tata-VSNL for upstream. With Level3 transit BSNL has badly screwed up reverse path causing very high latency and awful bandwidth.

anurag@laptop:~$ ping server7 -c 5
PING server7.anuragbhatia.com (178.238.225.247) 56(84) bytes of data.
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=1 ttl=52 time=320 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=2 ttl=52 time=320 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=3 ttl=52 time=319 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=4 ttl=52 time=327 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=5 ttl=52 time=320 ms
--- server7.anuragbhatia.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 319.880/**321.765**/327.384/2.828 ms
anurag@laptop:~$

Expected latency values here should be around 150ms. A packet should not take more then 150ms round trip between Radaur, Haryana to Munich located server.

Some important life changes…

I am not with Cloudaccess.net anymore. It was very nice experience of setting up AS54456 from scratch along with design of anycasting DNS instances.  Wishing Cloudaccess.net good luck for time ahead.

I just started working with Packet Clearing House (PCH). Looking forward towards exciting time ahead! Interesting pages to checkout - Anycasting DNS for TLDs  & Peering information. 

Thanks for reading.

Boring exam days, anyways time for a quick blog post to keep taste in life. :)

One of my good friend informed me about eNom DNS servers failing randomly. He gave clothdiaperrevival.com as sample domain name for testing.

Quick Check from my home connection:

anurag@laptop ~ $ dig clothdiaperrevival.com a @dns1.name-services.com +short  
216.239.32.21  
216.239.34.21  
216.239.36.21  
216.239.38.21

anurag@laptop ~ $ dig clothdiaperrevival.com a @dns2.name-services.com +short  
216.239.36.21  
216.239.32.21  
216.239.38.21  
216.239.34.21

anurag@laptop ~ $ dig clothdiaperrevival.com a @dns3.name-services.com +short  
216.239.38.21  
216.239.34.21  
216.239.32.21  
216.239.36.21

anurag@laptop ~ $ dig clothdiaperrevival.com a @dns4.name-services.com +short  
216.239.32.21  
216.239.38.21  
216.239.34.21  
216.239.36.21

anurag@laptop ~ $ dig clothdiaperrevival.com a @dns5.name-services.com +short  
216.239.32.21  
216.239.34.21  
216.239.36.21  
216.239.38.21

Next, checking from my EU located server:

anurag@server7:~$ dig clothdiaperrevival.com a @dns1.name-services.com +short  
216.239.32.21  
216.239.34.21  
216.239.36.21  
216.239.38.21

anurag@server7:~$ dig clothdiaperrevival.com a @dns2.name-services.com +short

anurag@server7:~$ dig clothdiaperrevival.com a @dns3.name-services.com +short  
216.239.36.21  
216.239.38.21  
216.239.32.21  
216.239.34.21

anurag@server7:~$ dig clothdiaperrevival.com a @dns4.name-services.com +short  
216.239.32.21  
216.239.38.21  
216.239.36.21  
216.239.34.21

anurag@server7:~$ dig clothdiaperrevival.com a @dns5.name-services.com +short  
216.239.32.21  
216.239.34.21  
216.239.36.21  
216.239.38.21

dns2.name-services.com is failing when reached my EU based server.

Sleepless night. Reading more about Quagga and it’s options.

In meanwhile a quick 5min script to enable domain to BGP/IP/ASN mapping. This script is using basic dig command (for finding IP address) and Team Cymru whois service for IP to ASN/block mapping.

#!/bin/bash  
\# Script for domain name to IP/ASN/BGP block mapping  
hostname=v4.whois.cymru.com  
IP=$(dig $1 a +short)  
whois -h $hostname " -c -p $IP"

Yeah just 3 line script! Less code = more power!