As6453
Inefficient IGP can make eBGP go wild!
Lately, I have been struggling to keep latency in check between my servers in India and Europe. Since Nov 2021 multiple submarine cables are down impacting significant capacity between Europe & India. The impact was largely on Airtel earlier but also happened on Tata Comm for a short duration. As of now Airtel is still routing traffic from Europe > India towards downstream networks via the Pacific route via EU > US East > US West > Singapore path. Anyways, this blog post is not about the submarine cable issue.
Why Indian internet traffic routes from outside of India?
After my last post about home networking, I am jumping back into global routing. More specifically how Indian traffic is hitting the globe when it does not need to. This is an old discussion across senior management folks in telcos, policymakers, and more. It’s about “Does Indian internet traffic routes from outside of India?” and if the answer is yes then “Why?” and “How much?”
It became a hot topic, especially after the Snowden leaks. There was even an advisory back in 2018 from Deputy National Security Advisor to ensure Indian internet traffic stays local (news here). Over time this has come up a few dozen times in my discussion with senior members from the Indian ISP community, individuals, and even latency-sensitive gamers. So I am going to document some of that part here. I am going to put whatever can be verified publically and going to avoid putting any private discussions I had with friends in these respective networks. The data specially traceroutes will have measurement IDs from RIPE Atlas so they can be independently verified by other network engineers.
Tata - Airtel domestic peering IRR filtering and OpenDNS latency!
Last month I noticed quite high latency with Cisco’s OpenDNS from my home fibre connection. The provider at home is IAXN (AS134316) which is peering with content folks in Delhi besides transit from Airtel.
ping -c 5 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=51 time=103 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=51 time=103 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=51 time=103 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=51 time=103 ms
64 bytes from 208.67.222.222: icmp_seq=5 ttl=51 time=103 ms
--- 208.67.222.222 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 103.377/103.593/103.992/0.418 ms
This is bit on the higher side as from Haryana to Mumbai (OpenDNS locations list here). My ISP is backhauling from Faridabad which is probably 6-8ms away from my city and 2-3ms further to Delhi and from there to Mumbai around 30ms. Thus latency should be around ~40-45ms.
Routing with North East India!
A few weeks back I got in touch with Marc from Meghalaya. He offered to host RIPE Atlas probe at Shillong and that’s an excellent location which isn’t there on RIPE Atlas coverage network yet. It took around 5 days for the probe to reach Shillong from Haryana. I think probably this probe is the one at the most beautiful place in India. :) Now that probe is connected, I thought to look into routing which is super exciting for far from places like Shillong. Marc has a BSNL FTTH connection & mentioned about not-so-good latency. Let’s trace to 1st IP of the corresponding /24 pool on which probe is hosted:
What makes BSNL AS9829 as most unstable ASN in the world?!
On weekend I was looking at BGP Instability Report data. As usual (and unfortunately) BSNL tops that list. BSNL is the most unstable autonomous network in the world. In past, I have written previously about how AS9829 is the rotten IP backbone.
This isn’t a surprise since they keep on coming on top but I think it’s well worth a check on what exactly is causing that. So I looked into BGP tables updates published on Oregon route-views from 21st May to 27th May and pulled data specifically for AS9829. I see zero withdrawals which are very interesting. I thought there would be a lot of announcements & withdrawals as they switch transits to balance traffic. If I plot the data, I get following chart of withdrawals against timestamp. This consists of summarised view of every 15mins and taken from 653 routing update dumps. It seems not feasible to graph data for 653 dumps, so I picked top 300.
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
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.
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:
BSNL routing tables and upstreams
Just was looking at routing tables of BSNL. They have a significant address space in /10 - 117.192.0.0/10. Overall this /10 address space is divided into /18 and /20 subnets.
Let’s pick two of such subnets and observe routing tables from route-views:
- 117.192.0.0/18
- 117.192.0.0/20
Routing table for 117.192.0.0/18:
* 117.192.0.0/18 193.0.0.56 0 3333 3356 6453 4755 9829 9829 9829 i
* 194.85.102.33 0 3277 3216 6453 4755 9829 9829 9829 i
* 194.85.40.15 0 3267 174 6453 4755 9829 9829 9829 i
* 129.250.0.11 6 0 2914 6453 6453 4755 9829 9829 9829 i
* 128.223.253.10 0 3582 3701 3356 6453 4755 9829 9829 9829 i
* 4.69.184.193 0 0 3356 6453 4755 9829 9829 9829 i
* 209.124.176.223 0 101 101 3356 6453 4755 9829 9829 9829 i
* 69.31.111.244 3 0 4436 2914 6453 6453 4755 9829 9829 9829 i
* 207.46.32.34 0 8075 6453 4755 9829 9829 9829 i
* 66.59.190.221 0 6539 6453 4755 9829 9829 9829 i
* 12.0.1.63 0 7018 6453 4755 9829 9829 9829 i
* 208.74.64.40 0 19214 2828 6453 4755 9829 9829 9829 i
* 203.181.248.168 0 7660 2516 6453 4755 9829 9829 9829 i
* 66.185.128.48 111 0 1668 6453 4755 9829 9829 9829 i
* 134.222.87.1 0 286 6453 4755 9829 9829 9829 i
* 157.130.10.233 0 701 6453 4755 9829 9829 9829 i
* 114.31.199.1 0 0 4826 6939 1299 6453 4755 9829 9829 9829 i
* 89.149.178.10 10 0 3257 6453 4755 9829 9829 9829 i
* 154.11.98.225 0 0 852 3561 6453 4755 9829 9829 9829 i
* 202.249.2.86 0 7500 2497 6453 4755 9829 9829 9829 i
* 154.11.11.113 0 0 852 3561 6453 4755 9829 9829 9829 i
* 144.228.241.130 0 1239 6453 4755 9829 9829 9829 i
* 217.75.96.60 0 0 16150 1299 6453 4755 9829 9829 9829 i
* 207.172.6.20 0 0 6079 3356 6453 4755 9829 9829 9829 i
* 206.24.210.102 0 3561 6453 4755 9829 9829 9829 i
* 195.66.232.239 0 5459 6453 4755 9829 9829 9829 i
* 208.51.134.254 2523 0 3549 6453 4755 9829 9829 9829 i
* 207.172.6.1 0 0 6079 3356 6453 4755 9829 9829 9829 i
* 216.218.252.164 0 6939 1299 6453 4755 9829 9829 9829 i
* 203.62.252.186 0 1221 4637 6453 4755 9829 9829 9829 i
*> 66.110.0.86 0 6453 4755 9829 9829 9829 i
* 164.128.32.11 0 3303 6453 4755 9829 9829 9829 i
* 202.232.0.2 0 2497 6453 4755 9829 9829 9829 i
Routing table for 117.192.0.0/20: