28 Jun

BSNL routing glitch and updates

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

anuragbhatia.com !!! » Blog Archive » BSNL > Softlayer connectivity problem & possible fix



Always good to see links to my blog. This was an interesting update and I can see forward does seems good for now. 


Here’s an updated traceroute from India to Singapore (BSNL > Softlayer):

anurag:~ anurag$ traceroute -a hostgator.in
traceroute to hostgator.in (, 64 hops max, 52 byte packets
1 [AS65534] router.home ( 1.183 ms 1.290 ms 0.849 ms
2 [AS9829] ( 17.517 ms 18.056 ms 17.163 ms
3 [AS9829] ( 71.872 ms 52.246 ms 114.018 ms
4 [AS4755] ( 49.644 ms 50.151 ms 49.265 ms
5 [AS0] ( 83.261 ms * 82.361 ms
6 [AS0] ix-4-2.tcore1.cxr-chennai.as6453.net ( 197.469 ms 199.161 ms 196.580 ms
7 [AS0] if-5-2.tcore1.svw-singapore.as6453.net ( 318.931 ms 307.292 ms
[AS0] if-3-3.tcore2.cxr-chennai.as6453.net ( 306.836 ms
8 [AS0] if-5-2.tcore2.svw-singapore.as6453.net ( 330.831 ms
[AS0] if-2-2.tcore2.svw-singapore.as6453.net ( 306.926 ms
[AS0] if-6-2.tcore2.svw-singapore.as6453.net ( 227.751 ms
9 [AS0] ( 230.692 ms 265.758 ms 241.768 ms
10 [AS4637] i-1-0-0.6ntp-core01.bi.telstraglobal.net ( 245.100 ms 235.299 ms 274.206 ms
11 [AS4637] i-0-1-0-0.istt02.bi.telstraglobal.net ( 307.158 ms 304.905 ms 307.080 ms
12 [AS4637] unknown.telstraglobal.net ( 307.409 ms 304.740 ms 307.178 ms
13 [AS36351] ae5.dar02.sr03.sng01.networklayer.com ( 307.167 ms 306.263 ms
[AS36351] ae5.dar01.sr03.sng01.networklayer.com ( 307.456 ms
14 [AS36351] po1.fcr01.sr03.sng01.networklayer.com ( 238.486 ms
[AS36351] po2.fcr01.sr03.sng01.networklayer.com ( 234.005 ms
[AS36351] po1.fcr01.sr03.sng01.networklayer.com ( 306.823 ms
15 * * *
16 * *^C
anurag:~ anurag$



So forward does seems good but latency is still way too high then an expected value of 120-150ms (from North India). There’s a jump as soon as we hit Chennai router for AS6453.


Quick ping output:

anurag:~ anurag$ ping -c 5 hostgator.in
PING hostgator.in ( 56 data bytes
64 bytes from icmp_seq=0 ttl=45 time=232.593 ms
64 bytes from icmp_seq=1 ttl=45 time=233.120 ms
64 bytes from icmp_seq=2 ttl=45 time=259.231 ms
64 bytes from icmp_seq=3 ttl=45 time=281.217 ms
64 bytes from icmp_seq=4 ttl=45 time=305.450 ms

— hostgator.in ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 232.593/262.322/305.450/28.154 ms
anurag:~ anurag$


We can ignore any value above 232ms because that’s simply latency added by router because they do not put ICMP on priority. But overall 232ms is quite high and it seems like there is issue in reverse path. I am doing this test from sitting on BSNL autonomous system 9829.


Looking at BGP table at Softlayer Singapore for this prefix via Softlayer Looking Glass, we get:



bbr01.eq01.sng02> show route protocol bgp table inet.0
inet.0: 461775 destinations, 1662681 routes (461773 active, 1 holddown, 1 hidden)
+ = Active Route, – = Last Active, * = Both *[BGP/170] 6:50:39, MED 1, localpref 160
AS Path: 4637 6453 9829 I

> to via xe-0/2/0.0
[BGP/170] 6:50:41, MED 5, localpref 10
AS Path: 2914 6453 9829 I

> to via ae11.0


So AS path is AS4637 > AS6453 > AS9829 


AS4637 is Reach/Telstra while AS6453 is Tata Comm and just next to it is AS9829 which again (as per my earlier post) is an IPLC link. AS6453 > AS9829 connection is from outside India for sure and it should be rather AS6453 > AS4755 (VSNL) > AS9829 for actual direct route from Singapore to Asia.


Just to confirm this, let’s run a trace to a random IP from Softlayer Singapore:

bbr01.eq01.sng02> traceroute
HOST: bbr01.eq01.sng02-re0 Loss% Snt Last Avg Best Wrst StDev
1. 0.0% 5 1.6 2.9 1.6 5.6 1.5
2. 0.0% 5 1.5 16.3 1.4 43.8 20.6
3. 0.0% 5 4.9 4.2 3.1 4.9 0.9
4. 0.0% 5 44.1 11.6 2.6 44.1 18.2
5. 0.0% 5 261.5 261.4 260.6 263.0 0.9
6. 0.0% 5 260.3 256.6 255.4 260.3 2.1
7. 0.0% 5 255.9 256.3 255.9 256.8 0.4
8. 0.0% 5 255.7 257.7 255.7 263.5 3.3
9. 60.0% 5 258.1 257.7 257.4 258.1 0.5
10. 80.0% 5 263.5 263.5 263.5 263.5 0.0
11. 0.0% 5 256.1 256.2 256.0 256.4 0.2
12. 0.0% 5 380.6 380.6 380.6 380.6 0.0
13. 0.0% 5 397.6 388.9 381.2 401.3 9.8
14. 0.0% 5 394.1 397.8 394.1 412.6 8.2
15. 20.0% 5 397.3 404.9 394.1 424.0 13.4
16. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0




Clearly a high latency route but unfortunately Softlayer looking glass is not doing rDNS PTR mapping for IP to hostname. Let’s try to look at some specific hops for them via using dig command (with -x argument for PTR):

anurag:~ anurag$
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$ dig +short -x
anurag:~ anurag$




So return path for packets is as:


Telstra (Singapore) > Tata AS6453 (Singapore) > Tata AS6453 (Chennai via Tata Indicom cable link) > Tata AS6453 (Mumbai) > Tata AS6453 (Marseille, France) > Tata AS6453 (London) > IPLC Link >>> BSNL AS9829 India.


So basically BSNL fixed forward path but return path is badly messed up. They are not announcing this prefix – along with many more prefixes  to transit provider’s IP links. They are just relying on NIXI for domestic traffic while for transit they are relying on IPLC ports which in this case seems to be with Tata AS6453 in London.


Here’s what Tata AS6453 router in Mumbai is getting:


AS6453 IPv4 and IPv6 Looking Glass
show ip bgp

Router: gin-mlv-core1
Site: IN, Mumbai, MLV
Command: show ip bgp

BGP routing table entry for
Bestpath Modifiers: deterministic-med
Paths: (3 available, best #3)
Multipath: eBGP
11 12
l78-mcore3. (metric 2968) from mlv-tcore2. (
Origin IGP, valid, internal
Originator: Loopback5.mcore3.L78-London.as6453.net.
l78-mcore3. (metric 2968) from mlv-tcore1. (
Origin IGP, valid, internal
Originator: Loopback5.mcore3.L78-London.as6453.net.
l78-mcore3. (metric 2968) from cxr-tcore1. (
Origin IGP, valid, internal, best
Originator: Loopback5.mcore3.L78-London.as6453.net.



So clearly in all three cases Tata AS6453 is getting routes via loopback interfaces of it’s router in London (m core 3 – London). There’s not even a single route via m-core Chennai/Mumbai via VSNL AS4755.



So what’s the possible fix?

Likely something like this:

  1. BSNL should maintain good capacity with IP ports along with IPLC ports.
  2. They should announce all prefixes to IP ports atleast without doing any preferred more specific announcement on IPLC like they announce /18 on IP port and more specific /20 on IPLC.
  3. BSNL should implement BGP blackholing to avoid East Asian traffic via their IPLC ports since most of their ports are in London, New York and Los Angles and not really in East Asia (as far as I can see from routes).
  4. BSNL “could” do a basic 1 degree prepend for IPLC routes specially with Tata AS6453 since AS6453 > AS9829 is short AS path then AS6453 > AS4755 > AS9829. Hence with one degree prepend they can have AS6453 > AS9829 > AS9829 (repetition of own AS once) to increase AS path to make route less preferred. 
  5. Buying IPLC port to reach Equinix Singapore + HongKong Internet Exchange (HKIX) – that’s where they can find a lot of local Asian traffic.
01 Jun

BSNL > Softlayer connectivity problem & possible 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.



OK – so the issue

I noticed a really bad (forward) route from my BSNL’s connection to hostgator.in website hosted in Softlayer Singapore. Let’s look at forward path:

anurag:~ anurag$ traceroute -a hostgator.in
traceroute to hostgator.in (, 64 hops max, 52 byte packets
1 [AS65534] router.home ( 1.189 ms 0.910 ms 0.810 ms
2 [AS9829] ( 17.707 ms 21.147 ms 16.925 ms
3 [AS9829] ( 30.195 ms 29.766 ms 29.976 ms
4 [AS9829] ( 75.432 ms 77.488 ms 76.761 ms
5 [AS6453] if-11-1-1.mcore3.laa-losangeles.as6453.net ( 368.104 ms 303.206 ms 309.964 ms
6 [AS6453] if-10-2-0-14.tcore2.lvw-losangeles.as6453.net ( 309.070 ms 308.725 ms 310.073 ms
7 [AS6453] ( 317.050 ms 318.714 ms 398.408 ms
8 [AS2914] ae-5.r21.lsanca03.us.bb.gin.ntt.net ( 305.672 ms * 304.480 ms
9 [AS2914] as-2.r20.osakjp01.jp.bb.gin.ntt.net ( 414.205 ms
[AS2914] as-1.r21.tokyjp01.jp.bb.gin.ntt.net ( 485.451 ms
[AS2914] as-2.r20.osakjp01.jp.bb.gin.ntt.net ( 414.272 ms
10 [AS2914] ae-3.r24.tokyjp05.jp.bb.gin.ntt.net ( 381.221 ms
[AS2914] ae-1.r23.osakjp01.jp.bb.gin.ntt.net ( 420.412 ms
[AS2914] ae-3.r25.tokyjp05.jp.bb.gin.ntt.net ( 372.768 ms
11 [AS2914] ae-7.r25.tokyjp05.jp.bb.gin.ntt.net ( 394.899 ms
[AS2914] ae-7.r24.tokyjp05.jp.bb.gin.ntt.net ( 406.922 ms
[AS2914] ae-2.r00.tokyjp03.jp.bb.gin.ntt.net ( 491.190 ms
12 [AS2914] ae-3.r00.tokyjp03.jp.bb.gin.ntt.net ( 399.065 ms
[AS2914] xe-0-0-0.bbr01.eq01.tok01.networklayer.com ( 307.955 ms
[AS2914] ae-2.r00.tokyjp03.jp.bb.gin.ntt.net ( 392.937 ms
13 [AS2914] xe-0-0-0.bbr01.eq01.tok01.networklayer.com ( 310.298 ms
[AS36351] ae1.bbr01.eq01.sng02.networklayer.com ( 306.396 ms
[AS2914] xe-0-0-0.bbr01.eq01.tok01.networklayer.com ( 407.191 ms
14 [AS36351] ae5.dar01.sr03.sng01.networklayer.com ( 388.660 ms
[AS36351] ae5.dar02.sr03.sng01.networklayer.com ( 303.546 ms 409.645 ms
15 [AS36351] po2.fcr01.sr03.sng01.networklayer.com ( 407.589 ms
[AS36351] ae5.dar02.sr03.sng01.networklayer.com ( 310.587 ms
[AS36351] po2.fcr01.sr03.sng01.networklayer.com ( 305.969 ms
16 [AS36351] po2.fcr01.sr03.sng01.networklayer.com ( 363.405 ms * 309.151 ms
17 * * *
18 * * *


BSNL (India) >> IPLC circuit >> Tata AS6453 Los Angeles, California >> NTT (US) >> NTT (Asia) >> NTT (Tokyo) >> Softlayer (Tokyo) >> Softlayer (Singapore)


Pretty bad. Ideally route should be BSNL > Upstream – Tata/Reliance/Airtel/Vodafone > Singapore (that’s it. Over!)


Interesting enough that Softlayer operates a nice looking glass and hence I was able to trace return path to my home router from there to get idea of complete route.

bbr02.eq01.sng02> traceroute
HOST: bbr02.eq01.sng02-re0 Loss% Snt Last Avg Best Wrst StDev
1. 0.0% 5 0.4 0.5 0.4 0.5 0.0
2. 0.0% 5 0.6 0.6 0.5 0.7 0.0 <<< PCCW Global
3. 0.0% 5 11.1 7.4 0.6 12.7 5.1 <<< Tata AS6453
4. 0.0% 5 0.6 2.4 0.6 9.6 4.0
5. 0.0% 5 62.1 61.2 60.7 62.1 0.6
6. 0.0% 5 97.7 73.3 60.8 97.7 17.4
7. 0.0% 5 103.2 75.0 59.6 103.2 18.1
8. 0.0% 5 61.1 74.0 61.1 88.9 12.4 <<< Tata AS6453
9. 0.0% 5 91.7 92.6 91.7 96.3 2.0 <<<< VSNL AS4755
10. 0.0% 5 95.5 96.5 95.5 99.7 1.8 <<<< Hits BSNL AS9829
11. 0.0% 5 106.6 110.4 106.4 126.2 8.8
12. 0.0% 5 106.3 107.0 106.3 108.6 1.0
13. ???



Overall pretty good and direct. Basically latency value is also as we expect till hop 12 because forward route (i.e from BSNL > Softlayer) is direct from BSNL router on hop 12 but for routers below it they are taking route via US. Return path trace is not showing those routers because BSNL is dropping ICMP.


Reason for problem:

Forward path is terribly bad here because BSNL let usual BGP route selection algorithm to deal with it. Basically BSNL is getting multiple routes for that prefix from Softlayer. One from it’s IP port in India with Tata-VSNL AS4755 and other from it’s port from Tata in Los Angles (Tata AS6453) over IPLC.


So possible routes as per AS paths are:

AS9829 > AS4755 > AS6453 > AS2914 > AS36351 

AS9829 > AS6453 > AS2914 > AS36351


Based on default property of BGP, it is picking short AS path i.e 2nd one. In case of #1 BGP session between BSNL AS9829 and Tata-VSNL AS4755 is within India. 

For example:

1 [AS65534] router.home ( 1.709 ms 0.912 ms 0.982 ms
2 [AS9829] ( 17.451 ms 18.075 ms 19.029 ms
3 [AS9829] ( 21.843 ms 24.584 ms 22.491 ms
4 [AS4755] ( 57.399 ms 58.563 ms 57.446 ms


Very likely BGP session here is configured on usual /30 subnet with one IP on BSNL side, one on Tata’s side, third one as broadcast and 4th lying useless due to Math game!

So is part of that /30. Let’s ping it:

anurag:~ anurag$ ping -c 5
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=58 time=63.286 ms
64 bytes from icmp_seq=1 ttl=58 time=66.029 ms
64 bytes from icmp_seq=2 ttl=58 time=59.063 ms
64 bytes from icmp_seq=3 ttl=58 time=59.439 ms
64 bytes from icmp_seq=4 ttl=58 time=61.719 ms

— ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 59.063/61.907/66.029/2.573 ms
anurag:~ anurag$


60ms latency – for sure Mumbai and all good here.


Now let’s look at IP just next to it:


anurag:~ anurag$ ping -c 5
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=251 time=28.784 ms
64 bytes from icmp_seq=1 ttl=251 time=25.586 ms
64 bytes from icmp_seq=2 ttl=251 time=28.631 ms
64 bytes from icmp_seq=3 ttl=251 time=26.905 ms
64 bytes from icmp_seq=4 ttl=251 time=26.213 ms

— ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.586/27.224/28.784/1.282 ms
anurag:~ anurag$


Half latency and that’s BSNL router in Delhi/Noida where they are taking drop from Tata. It’s BSNL’s router but sitting on Tata’s IP for BGP session. So this clearly tells that when we see routes from AS9829 to AS4755 Tata-VSNL they are between routers within India.


Now coming back to bad route between BSNL and Softlayer, in that case first few hops are:

1 [AS65534] router.home ( 1.189 ms 0.910 ms 0.810 ms
2 [AS9829] ( 17.707 ms 21.147 ms 16.925 ms
3 [AS9829] ( 30.195 ms 29.766 ms 29.976 ms
4 [AS9829] ( 75.432 ms 77.488 ms 76.761 ms
5 [AS6453] if-11-1-1.mcore3.laa-losangeles.as6453.net ( 368.104 ms 303.206 ms 309.964 ms


Hop 5 has latency of 300ms (usual for India > US routes). Again assuming is coming from /30 and as per usual BSNL practice next IP in that subnet i.e would be on BSNL’s side, let’s ping

anurag:~ anurag$ ping -c 5
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=250 time=373.483 ms
64 bytes from icmp_seq=1 ttl=250 time=395.493 ms
64 bytes from icmp_seq=2 ttl=250 time=419.340 ms
64 bytes from icmp_seq=3 ttl=250 time=305.460 ms
64 bytes from icmp_seq=4 ttl=250 time=362.598 ms

— ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 305.460/371.275/419.340/38.232 ms
anurag:~ anurag$



Hmm….300ms latency. Unexpected. I thought this router was in India but this seems slightly complex. Likely BGP session here is using BSNL’s /30 subnet and not via Tata Comm’s subnet. 

OK – let’s see last IP from BSNL on that trace – it was Let’s ask Tata AS6453 Los Angles LAA router via AS6453 Looking Glass for BGP table:


Router: gin-laa-mcore3
Site: US, Los angeles, LAA
Command: show ip bgp

BGP routing table entry for
Bestpath Modifiers: deterministic-med
Paths: (2 available, best #1)
14 16 17 18
ix-3-2.mcore3.LAA-LosAngeles. from ix-3-2.mcore3.LAA-LosAngeles. (
Origin IGP, valid, external, best
9829, (received-only)
ix-3-2.mcore3.LAA-LosAngeles. from ix-3-2.mcore3.LAA-LosAngeles. (
Origin IGP, valid, external


So BGP route is via –

Let’s trace:

traceroute to (, 64 hops max, 52 byte packets
1 router.home ( 4.047 ms 0.875 ms 0.958 ms
2 ( 18.779 ms 17.490 ms 19.334 ms
3 ( 44.040 ms 32.802 ms 29.831 ms
4 ( 82.626 ms 87.126 ms 84.243 ms
5 ( 86.061 ms 85.503 ms 83.003 ms


Here we go!

So clearly BSNL on is placed in India and is having a BGP session with Tata AS6453 router in Los Angeles. This is over an IPLC circuit of Tata Communications. 


Possible fix…

Following an amazing quote – “Never call it a problem unless you have the solution!

So problem here is not really via Tata’s network. They are just selling bandwidth in form of two products – IP Transit & IPLC. It’s BSNL’s wrong idea of using IPLC carelessly. Likely BSNL won’t care or put much effort in fixing it. 

There can be a possible fix from Softlayer side. If they blackhole prefix announcement to BSNL AS9829 via Tata AS6453, BSNL will never pick their IPLC (or even IP) route. Instead they will just pick route via any other upstream like Airtel or Reliance Globalcom.  


Let’s look at relationship of Tata AS6453 with PCCW Global (upstream for Softlayer)

anurag:~ anurag$ whois -h whois.radb.net as6453 | grep -w AS3491
import: from AS3491 action pref = 100; accept AS-CAIS
export: to AS3491 announce AS-GLOBEINTERNET
import: from AS3491 action pref = 100; accept AS-CAIS
export: to AS3491 announce AS-GLOBEINTERNET
anurag:~ anurag$


Clearly both are peering! 

Based on presentation from Mr Amit Dunga (from Tata Communications) at SANOG, here’s list of BGP communities used by Tata AS6453:

Screen Shot 2013-06-01 at 12.30.35 AM



Thus if Softlayer could get it’s upstream providers (like PCCW in this specific case) to use 65009:9829 – this will ensure that route learnt by Tata AS6453 from PCCW Global AS3491 is NOT exported to BSNL AS9829. Thus BSNL will instead get route via Bharti Airtel AS9498 or Reliance AS18101.


I just sent this detailed info as email to Softlayer and BSNL. And oh yes – I don’t know why hostgator.in is hosted in Softlayer Singapore anyways. They provide hosting in India out of Ctrls datacenter. Why they host their own home site in Singapore is something beyond my understanding!


With hopes that your packets to Singapore are not routing via US, time for me to get back to my “cramming” for exams. 🙂

16 May

Backend of Google’s Public DNS

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 and 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


Type escape sequence to abort.
Tracing the route to google-public-dns-a.google.com (

1 [MPLS: Label 550027 Exp 0] 0 msec [MPLS: Label 550027 Exp 0] 4 msec [MPLS: Label 354133 Exp 0] 0 msec
2 0 msec 0 msec 0 msec
3 44 msec 44 msec 48 msec
4 [AS 15169] 52 msec 56 msec 52 msec
5 google-public-dns-a.google.com ( [AS 15169] 52 msec * 116 msec


50ms latency. Clearly destination is within India and based on my experience with latency values, I strongly guess that’s Chennai.


Location of Google Public DNS servers

Anyways so does that means Google’s DNS server is within India?


A clear answer is no. This is just a DNS caching server and Google does not use it for originating actual queries further to root, TLDs nodes and authoritative DNS servers. This seems like a interesting distributed setup.

As per Google Public DNS FAQ page, there are quite a few locations from where DNS servers originate queries but India is not in the list yet. Google has PoPs in Delhi, Mumbai and Chennai and they peer with pretty much every Indian ISP out from there.


We can actually test which node is serving us here in India.
This can be achieved in multiple ways:

  1. Running a authoritative zone on a server with basic BIND installation. I tried this with my own Linux server by having testing-google-dns.anuragbhatia.com. DNS zone. I delegated NS for this zone on auth. DNS servers for “anuragbhatia.com” zone. Next I sent a DNS query with dig @  testing-google-dns.anuragbhatia.com. a +short to ask my DNS server for IP and this gave me source IP of Google’s resolver. 
  2. The other easy way out is to simply use Akamai’s “whoami.akamai.net” service. It is designed in a way to return A record of DNS resolver which queries it. This gives IP of Google’s server which sent the DNS query for resolution.


Anurags-MacBook-Pro:~ anurag$ dig whoami.akamai.net a @ +short
Anurags-MacBook-Pro:~ anurag$



In both cases I saw IP was It belongs to announced by Google’s AS15169. As per Google’s FAQ page (which has IPs too!) the prefix belongs to Kuala Lumpur, Malaysia. So that’s the actual DNS resolver node which serves users here in India. Machines with IPs and are just caching replies and more over taking the IP traffic to Google within India.


Now one can ask why Google is not having DNS resolver within India?




Guess work time!

I don’t know exactly but I can do a strong guess work here. Google is a tier 1 transit free network. It relies on paying on layer 2, building PoPs and connected them together. It does not pays on layer 3 for bandwidth to any ISP. So Google’s routers in India learn traffic from just peering sessions with all major telcos (except BSNL). Google is peering with Tata-VSNL AS4755, Reliance AS18101, Airtel AS9498, MTNL AS17813, Spectranet AS10029 etc. One interesting thing here is that these are all tier 2 networks. Tata Communications is a tier 1 network but their domestic backbone VSNL AS4755 is technically not a tier 1 network and technically it sits in downstream of Tata AS6453 (which is their tier 1 IP backbone). Thus Google does not gets full global table feed from any of these links and possibly nearest PoP of Google which has full table feed from Tier 1 networks is in Malaysia.


What I am not able to answer from my guess work is that when Google is relying on East Asian PoPs for such stuff and mantaining a backbone between East Asia and India directly then why they could not feed Indian routers routing table with routes learnt from outside?  It could be just to ensure direct delivery in India and avoid routing loops. E.g BSNL has IP port from Tata-VSNL AS4755 within India and IPLC port from Tata-AS6453 to outside Indian PoPs. Thus if tables are combined Google might see paths like  AS6453 > AS9829 and AS4755 > AS9829 which seem identical as per AS path but one is direct India to India traffic while other via India > Singapore > India or India > US > India. It’s not just about BSNL but Sify also lately has weird routing loops going from outside India for Indian destinations.


That’s about it. Can’t do any guess work beyond this point unless someone gives me access to a router of AS15169 to see table! 🙂