Networking

 

Few days back I mentioned how reverse DNS setup of Airtel was incorrect. Sad to say it has not been fixed yet. In meanwhile I was looking at domain name - airtel.in the main domain which runs website for Bharti Airtel’s Indian operations. I am little surprised to find that DNS server of airtel.in are failing randomly!  

Problem:

airtel.in uses 4 DNS servers from Mantra Online - a small ISP which Bharti took over years back. Here are the DNS servers used by domain name: aaadel.mantraonline.com. dnsbom.mantraonline.com. dnsdel.mantraonline.com. dnsblr.mantraonline.com.   Now interesting part here is that out of these 4, only 1 behaves normally. DNS server - dnsblr.mantraonline.com. seems working fine but rest all are rejecting queries “randomly” which is interesting. I have mostly seen DNS servers being up or down. This is probably first case when I can see DNS servers failing in random fashion.

Yesterday I came across a very interesting case of network hijacking of an ISP from wrong BGP announcements by another network. This issue was reported to NANOG mailing list. 

Issue was reported by Kevin, Senior Engineer at Altus Communications (AS11325). Problem was that SBJ Media LLC (AS33611) was making a /24 block announcement for specific slices of Altus -  208.110.48.0/20, 63.246.112.0/20, and 68.66.112.0/20 which are allocated to Altus Communications (as per ARIN whois).

Sify is one of really interesting companies. One time pioneer of Indian internet market via chain of cyber cafes. Good old days. Present situation of Sify in consumer market is not significant. Latest earing figures clearly state company is moving towards enterprise segment.

Company is quite aggressive in enterprise segment offerings specially datacenters & corporate leased lines.
Is consumer market really over for Sify or there’s still some hope?

Well, consumer broadband market isn’t really over! Infact this is the main market which is yet to explode in India!

Interestingly routing issues didn’t spare one of top CDN provider - Akamai!

So what’s wrong?

(from my BSNL connection):

PING akamai.com (61.213.189.49) 56(84) bytes of data.  
64 bytes from 61.213.189.49: icmp_req=1 ttl=52 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=2 ttl=52 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=3 ttl=52 time=474 ms  
64 bytes from 61.213.189.49: icmp_req=4 ttl=51 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=5 ttl=51 time=489 ms

\--- akamai.com ping statistics --- 
5 packets transmitted, 5 received, 0% packet loss, time 22236ms  
rtt min/avg/max/mdev = 474.296/488.469/492.837/7.183 ms

~ 500ms is way too high. Even US is at like 300ms latency.

Looking at traceroute: 

traceroute to akamai.com (61.213.189.49), 30 hops max, 60 byte packets  
1 router.local (192.168.1.1) [AS8151/AS28513] 4.223 ms 4.979 ms 5.879 ms  
2 117.200.48.1 (117.200.48.1) [AS9829] 45.241 ms 46.384 ms 52.839 ms  
3 218.248.173.46 (218.248.173.46) [AS9829] 87.089 ms \* \*  
4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755] 74.675 ms 76.970 ms 80.856 ms  
5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [\*] 83.234 ms 84.403 ms 87.742 ms  
6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 230.777 ms 185.553 ms 194.288 ms  
7 \* Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453] 203.104 ms \*  
8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453] 308.973 ms 310.324 ms 311.038 ms  
9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 311.799 ms 333.841 ms 313.348 ms  
10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 499.075 ms 501.158 ms 512.657 ms  
11 ae-5.r24.tokyjp01.jp.bb.gin.ntt.net (129.250.3.221) [AS2914] 484.258 ms 485.401 ms 499.039 ms  
12 \* \* \*  
13 xe-2-3.a17.tokyjp01.jp.ra.gin.ntt.net (61.213.169.214) [AS2914] 488.807 ms 489.543 ms 495.396 ms  
14 61.213.189.49 (61.213.189.49) [AS2914] 506.170 ms 501.504 ms 507.296 ms

So route is like Mumbai (India) - London (UK) - Tokyo (Japan).

This is a very popular mistake admins make - it’s missing . i.e dot in the end of hostname. This causes serious problems (and lot of frustration!).

E.g taking example of popular Google’s cname record ghs.google.com. As we know if one would like to use mail.domain.com., he has to point the CNAME record to “ghs.google.com”. Now here if one misses dot in the end of ghs.google.com. - it will give a real value like: