Reliance | anuragbhatia.com

03 Jul

Reliance Jio orignating Charter’s /16 pool

Just noticed that Reliance Jio (AS55836) seems to be originating a /16 which is for Charter Communications (AS20115) – 47.35.0.0/16.

route-views>sh ip bgp 47.35.0.0/16 long | exclude 20115
BGP table version is 18764390, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network          Next Hop            Metric LocPrf Weight Path
*   47.35.0.0/16     195.208.112.161                        0 3277 3267 174 64049 55836 i
*                    217.192.89.50                          0 3303 6762 64049 55836 i
*                    212.66.96.126                          0 20912 1267 64049 55836 i
*                    162.243.188.2                          0 393406 6453 6762 64049 55836 i
*                    192.241.164.4                          0 62567 2914 174 64049 55836 i
*                    129.250.0.11          1007             0 2914 174 64049 55836 i
*                    104.192.216.1                          0 46450 174 64049 55836 i
*                    202.93.8.242                           0 24441 3491 3491 174 64049 55836 i
*                    66.59.190.221                          0 6539 577 6762 64049 55836 i
*                    144.228.241.130         80             0 1239 174 64049 55836 i
*                    207.172.6.20             0             0 6079 3356 174 64049 55836 i
*                    203.62.252.83                          0 1221 4637 174 64049 55836 i
*                    93.104.209.174                         0 58901 51167 3356 6762 64049 55836 i
Network          Next Hop            Metric LocPrf Weight Path
*                    162.250.137.254                        0 4901 174 64049 55836 i
*                    4.69.184.193             0             0 3356 174 64049 55836 i
*                    208.51.134.254           1             0 3549 3356 174 64049 55836 i
*                    89.149.178.10           10             0 3257 174 64049 55836 i
*                    66.110.0.86                            0 6453 6762 64049 55836 i
*                    134.222.87.1           650             0 286 174 64049 55836 i
*                    95.85.0.2                              0 200130 6453 174 64049 55836 i
*                    12.0.1.63                              0 7018 174 64049 55836 i
*                    173.205.57.234                         0 53364 3257 174 64049 55836 i
*                    206.24.210.80                          0 3561 174 64049 55836 i
*                    5.101.110.2                            0 202018 2914 174 64049 55836 i
*                    207.172.6.1              0             0 6079 3356 174 64049 55836 i
*                    154.11.98.225            0             0 852 174 64049 55836 i
*                    194.85.40.15                           0 3267 174 64049 55836 i
*                    208.74.64.40                           0 19214 174 64049 55836 i
*                    209.124.176.223                        0 101 101 174 64049 55836 i
*                    66.185.128.48            6             0 1668 174 64049 55836 i
*                    203.181.248.168                        0 7660 2516 6762 64049 55836 i
*                    202.232.0.2                            0 2497 701 6762 64049 55836 i
*                    103.247.3.45                           0 58511 64049 55836 i
*                    193.0.0.56                             0 3333 1103 64049 55836 i
Network          Next Hop            Metric LocPrf Weight Path
*                    80.241.176.31                          0 20771 47872 64049 55836 i
*>                   216.218.252.164                        0 6939 64049 55836 i
*                    132.198.255.253                        0 1351 174 64049 55836 i
*                    103.255.249.22                         0 58443 45177 64049 55836 i
*                    114.31.199.1                           0 4826 174 64049 55836 i
route-views>

This shows Reliance Jio’s ASN AS55836 announcing 47.35.0.0/16. Charter Communications (AS20115) is originating multiple of /18s out of the same pool.

route-views>sh ip bgp 47.35.0.0/16 long
BGP table version is 18764237, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network          Next Hop            Metric LocPrf Weight Path
*   47.35.0.0/18     195.208.112.161                        0 3277 3267 6939 20115 i
*                    212.66.96.126                          0 20912 6939 20115 i
*                    162.243.188.2                          0 393406 6939 20115 i
*                    192.241.164.4                          0 62567 6939 20115 i
*                    129.250.0.11          1006             0 2914 1299 20115 i
*                    4.69.184.193             0             0 3356 20115 i
*                    89.149.178.10           10             0 3257 3356 20115 i
*                    194.85.40.15                           0 3267 6939 20115 i
*                    216.218.252.164                        0 6939 20115 i

Let’s look for whois record of this /16 pool: https://whois.arin.net/rest/net/NET-47-32-0-0-1

NetRange: 47.32.0.0 - 47.51.255.255
CIDR: 47.32.0.0/12, 47.48.0.0/14
NetName: CC04
NetHandle: NET-47-32-0-0-1
Parent: NET47 (NET-47-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Charter Communications (CC04)
RegDate: 2014-12-23
Updated: 2014-12-23
Ref: https://whois.arin.net/rest/net/NET-47-32-0-0-1

It seems highly unlikely that this pool has been transferred over to Jio and hence it’s highly likely that Reliance Jio is falsely advertising this pool. Possible reason for such mistake can be because they have got 47.29.0.0/16, 47.30.0.0/16 and 47.31.0.0/16 but beyond that there are few Charter Pools. So likely someone just mistyped an IP. Another possible reason for such mistype can be that they have also got 49.35.0.0/16 (it’s 49, not 47).

What is much more fascinating is that they even have a RADB route object registered for the same.

whois -h whois.radb.net 47.35.0.0
route:      47.35.0.0/16
descr:      Route Set JIO Maharastra LTE USER Pool
origin:     AS55836
notify:     Ip.abuse@ril.com
mnt-by:     MAINT-AS55836
changed:    ip.management@ril.com 20160624
source:     RADB

World of BGP is interesting!

Update:

As per update from Mr Morlay Gosh from Reliance Jio on SANOG mailing list- This was mistake and they are removing the same.

http://article.gmane.org/gmane.org.operators.sanog/2929

30 Jul

Welcome Amazon AWS AS16509 to India!

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:

Unicast prefixes originated in India (for Cloufront CDN):

54.230.172.0/22
54.230.188.0/22
54.239.160.0/22
54.239.188.0/22

Anycast prefixes (for anycasted DNS route 53)

205.251.192.0/23
205.251.198.0/23

Note: I pulled these prefixes by looking at upstream peers in India (which is Tata and Reliance) and running simply sh ip bgp regexp 4755 16509 & sh ip bgp regexp 18101 16509 on Oregon routeviews & few other major data collection points of global IPv4 table.

I can’t see any upstream from Airtel AS9498 or any other major Indian telco. Also at NIXI prefixes are available partially. I see prefiex at NIXI Mumbai carried by Tata VSNL. At NIXI Chennai prefixes are present with one degree prepend (AS4755 AS4755 twice) making route less preferable. While at NIXI Delhi there seems no route at all for Amazon’s prefixes (Tata follows regional route policy at NIXI).

So now big question here – which datacenter is that?

I doubt it would be Tata or Reliance since they are core competitiors and run datacenters pretty much on their own networks with almost zero carrier neutral options (few exceptions are there). My strong guess is that it’s Netmagic’s datacenter in Mumbai and Chennai with direct upstream links (bypassing Netmagic’s network). Just my guess. Cannot verify it from record of AS16509 on peeringdb.net – http://www.peeringdb.com/view.php?asn=16509

With that being said here’s a trace to cdn.anuragbhatia.com (which I use via Amazon Cloudfront):

Anurags-MacBook-Pro:~ anurag$ traceroute -a cdn.anuragbhatia.com
traceroute: Warning: cdn.anuragbhatia.com has multiple addresses; using 54.230.189.204
traceroute to ddlfp4nmkhyfr.cloudfront.net (54.230.189.204), 64 hops max, 52 byte packets
1 [AS1] 10.0.0.1 (10.0.0.1) 1.152 ms 0.765 ms 0.627 ms
2 [AS10223] 192.168.1.1 (192.168.1.1) 1.460 ms 2.906 ms 1.569 ms
3 [AS9829] 117.218.197.1 (117.218.197.1) 16.339 ms 17.905 ms 15.704 ms
4 [AS9829] 218.248.169.118 (218.248.169.118) 94.835 ms 29.628 ms 118.135 ms
5 [AS4755] 115.114.89.21.static-mumbai.vsnl.net.in (115.114.89.21) 60.472 ms 61.304 ms 59.103 ms
6 [AS0] 172.31.19.245 (172.31.19.245) 84.706 ms 87.201 ms 85.640 ms
7 [AS4755] 115.114.130.126.static-chennai.vsnl.net.in (115.114.130.126) 82.327 ms 83.276 ms 81.583 ms
8 [AS16509] server-54-230-189-204.maa3.r.cloudfront.net (54.230.189.204) 85.261 ms 85.185 ms 84.269 ms
Anurags-MacBook-Pro:~ anurag$

Always nice to maa in all these nodes at Chennai. Basically most of companies (including Google) use 3 digit airport code in name of node (in rDNS PTR record of router’s WAN IP). For Chennai (which used to be known as Madras) airport code is still MAA and this is why you will see maa in Chennai nodes and BOM on Mumbai based nodes. 🙂

Time to get back to work. Have a good week ahead! 🙂

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

traceroute 8.8.8.8

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

1 182.79.254.242 [MPLS: Label 550027 Exp 0] 0 msec
203.101.100.29 [MPLS: Label 550027 Exp 0] 4 msec
182.79.254.238 [MPLS: Label 354133 Exp 0] 0 msec
2 203.101.100.181 0 msec
182.79.247.13 0 msec 0 msec
3 74.125.51.34 44 msec 44 msec 48 msec
4 72.14.237.3 [AS 15169] 52 msec 56 msec 52 msec
5 google-public-dns-a.google.com (8.8.8.8) [AS 15169] 52 msec * 116 msec
DEL-ISP-MPL-ACC-RTR-9#

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:

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 @8.8.8.8 testing-google-dns.anuragbhatia.com. a +short to ask my DNS server for IP and this gave me source IP of Google’s resolver.
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 @8.8.8.8 +short
173.194.97.22
Anurags-MacBook-Pro:~ anurag$

In both cases I saw IP was 173.194.97.22. It belongs to 173.194.97.0/24 announced by Google’s AS15169. As per Google’s FAQ page (which has IPs too!) the prefix 173.194.97.0/24 belongs to Kuala Lumpur, Malaysia. So that’s the actual DNS resolver node which serves users here in India. Machines with IPs 8.8.8.8 and 8.8.4.4 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! 🙂

anuragbhatia.com

DNS, BGP, Anycast, IPv6 & more!

Tag Archives: Reliance