# Airtel Published articles for Airtel. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Airtel plans to begin RPKI Route Origin Validation rollout on 22 September 2026 DevFeed: [Airtel plans to begin RPKI Route Origin Validation rollout on 22 September 2026]() Original publisher: [Read original article]() Published: 2026-09-14T09:00:47Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [Routing Security](), [Security]() Tags: [airtel](), [apnic-62](), [as9498](), [india](), [ipv4](), [ipv6](), [routing-security](), [rov](), [rpki]() ### AI overview Airtel has told customers it plans to begin rolling out RPKI Route Origin Validation on 22 September 2026. The article examines 726 RPKI-invalid routes in Airtel's table, including 108 IPv4 and 618 IPv6 routes, and discusses their visibility outside India. ### Source excerpt Just back from Mumbai after APNIC 62 and Equinix's India Peering Forum. On excellent news: Airtel has started sending emails to its customers about RPKI RoV (Route Origin Validation). As per the mail, Airtel will start RPKI RoV soon and has mentioned 22 Sep 2026 as the timeline when they will start rolling out RoV. This is excellent news on the routing security front, and kudos to Airtel (AS9498) for taking the lead here among other large Indian backbones. This brings up the important question of how many routes exist in their table which are RPKI RoV invalids as of today? Looking at their announcements, I see the following: RPKI Valids: 33,735 RPKI Unknown: 4632 RPKI invalids: 726 This is for their table, including downstream routes. One can view the complete list of those 726 invalids, including prefix and AS_PATH here. One interesting thing here is that out of 726, 140 are from Airtel fixedline AS24560 and 122 are from Airtel Mobility. In terms of address family, there are 108 invalids from IPv4 and 618 from IPv6. How many of these invalids are single-homed vs multi-homed? This is important to check, as often the argument against RoV given by various operators in past was that they were losing traffic to their competitors. When I checked, I do not see any of these prefixes visible outside of India behind a transit-free / tier 1 network without AS9498 in the path. It could be because Tata Comm AS6453 drops RPKI invalid already & most of these are not dual-homed via Jio AS64049. So unless a less specific RPKI valid announcement is there, these are anyway largely blackholed for now by networks & IXPs doing RoV outside of India. Let's hope other Indian backbones also start doing RPKI RoV soon. Happy routing! 😀 ## Indian backbones need AS\_PATH filters DevFeed: [Indian backbones need AS\_PATH filters]() Original publisher: [Read original article]() Published: 2026-09-07T20:11:07Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [Routing (disambiguation)](), [networking](), [Security]() Tags: [airtel](), [as4755](), [as55836](), [as9498](), [bgp](), [india](), [jio](), [network](), [rcom](), [routing](), [tata-comm]() ### AI overview The article argues that route leaks are a longstanding security problem for India's routing infrastructure. It explains limitations of IRR AS-SETs, discusses ASPA and AS_PATH filters or peer lock, and questions whether major Indian backbones can consistently apply those filters because of indirect routing and smaller downstream networks. ### Source excerpt The security of India's routing infrastructure is something that isn't discussed as much as cybersecurity, software vulnerabilities, etc. Part of the blame for that has to go to our industry, which is relatively closed when it comes to sharing incidents and also lacks good documentation on the deployment side of things. Some of these things came to light after the RCom (AS18101) BGP hijack of Telegram prefixes in June 2026. One silent problem for a long time has been route leaks. BGP route leak Route leaks happen when a network ends up announcing a route to a BGP adjacency where it is not supposed to announce that route. Take, for example, a network "leaking" routes learnt from a peer to transit, or vice versa. One can filter downstreams which are small, but it's very hard to filter large downstream networks which have further downstreams, or if one is far removed from that ASN. IRR AS-SETs exist for this reason, but they have not worked well due to tooling challenges. Furthermore, IRR (Internet Routing Registry) by design is a public register where one "publishes intent" before actually doing that in BGP, and then anyone can match the intent with the state in BGP. New tech ASPA will help address this issue, but it's new, vendor support is still in the development phase and it will take its own adoption time. AS_PATH filters / Peer lock This is older tech which can play a very effective role in controlling leaks. If network A decides to peer with network B, they both can agree to announce all routes to each other over the peering & agree to reject each other's ASN from all other BGP sessions. It's a common practice between large transit-free Tier-1 networks as well as major backbones and is often referred to by the fancy name of "peer lock". In India, I doubt backbones like Airtel, Jio, and Tata Comm can have AS_PATH filters rejecting each other from everywhere except direct sessions because there is some indirect routing visible all the time. It could be because of ## Beyond 5G: The Two Biggest Challenges for India's Internet DevFeed: [Beyond 5G: The Two Biggest Challenges for India's Internet]() Original publisher: [Read original article]() Published: 2026-07-02T19:50:52Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Internet](), [Networks](), [networking](), [5G]() Tags: [5g](), [airtel](), [broadband](), [cgnat](), [ftth](), [india](), [internet](), [jio](), [logging](), [networks](), [pm-wani](), [resilience](), [routing](), [wifi]() ### AI overview This opinion argues that India's internet ecosystem is held back by duplicated fixed-line last-mile infrastructure and difficulty sharing Wi-Fi legally. It proposes neutral last-mile fibre infrastructure, allowing ISPs to compete on service quality, and discusses contention in PON and AON networks. ### Source excerpt The recent debate around Airtel's priority 5G generated plenty of noise. Personally, I'm not a fan of it either but Airtel and Jio are private companies. Their job is to maximise shareholder value, not to maintain market competition. The real question is why competition remains so limited. And by competition, I don't mean another mobile operator. I mean fixed-line broadband. Two long-standing problems continue to hold India's internet ecosystem back. 1. Every ISP builds its own last mile In the early days of FTTH this was understandable. In 2026, it feels increasingly wasteful. At my home in Haryana, around a dozen FTTH providers are available. The pole outside carries 14 fibre cables from different operators -- all solving the same problem independently. The last mile isn't where ISPs differentiate. Fibre from ISP A isn't inherently "faster" than fibre from ISP B. The real differentiation is in the network behind that fibre capacity, routing, peering, resilience and customer support. Yet every provider continues deploying duplicate infrastructure. Even Airtel and Jio increasingly push Fixed Wireless Access because expanding FTTH remains expensive. Instead of parallel deployments, we should encourage neutral last-mile infrastructure. A small number of regulated fibre providers could deploy high core count cables, while ISPs lease strands and compete on service quality rather than digging the same streets repeatedly. This will also help in fixing streets which look quite ugly with excess fibre routing in all directions. Earlier this year, Stefan Schüller published an excellent article, The Free Market Lie: Why Switzerland Has 25 Gbit Internet and America Doesn't comparing broadband infrastructure in Switzerland, the US and Germany. It's well-researched and provides useful context for many of the points discussed here.I do disagree with one aspect of the article - its comparison of Passive Optical Networks (PON) and Active Optical Networks (AON). Contention exists thro ## Telegram prefixes hijack by Rcom AS18101 DevFeed: [Telegram prefixes hijack by Rcom AS18101]() Original publisher: [Read original article]() Published: 2026-06-16T19:44:03Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [Routing (disambiguation)]() Tags: [airtel](), [as15412](), [as18101](), [as4755](), [bgp](), [india](), [outage](), [rcom](), [ripe-ris](), [routers](), [routing](), [rpki](), [telegram](), [traffic]() ### AI overview The article examines Rcom AS18101's apparent BGP hijacking of Telegram prefixes during Telegram's blocking in India. It confirms that Rcom originated at least one Telegram prefix and argues that the incident was more likely an accidental configuration error than intentional sabotage, while noting that the impact varied by upstream connectivity. ### Source excerpt The last few hours were quite noisy with a lot of discussion around Telegram block and Rcom's hijack of Telegram prefixes. For those who may not know, Telegram has been blocked in India till 22 June 2026 (news here). The justification has been to avoid paper leak over the telegram. Anyways, I am not going into whether the block is good or bad as it can be part of an endless discussion depending on how one views it. Maybe some separate time but let's look at the BGP routing side of things. ISPs went for blocking it in all possible ways - from the usual DNS layer to block resolution of Telegram to also blackhole its prefixes. Telegram is a special case as they have their own ASN, IP prefixes etc making it easy to block them at the routing layer directly. I saw this on Airtel, where traffic seems to be dropping at their routers. mtr -wby0 -4 web.telegram.org Start: 2026-06-17T01:20:46+0530 HOST: desktop Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway (172.16.0.1) 0.0% 10 0.2 0.2 0.2 0.2 0.0 2. AS??? 10.240.9.204 0.0% 10 4.6 7.4 4.2 25.7 6.5 3. AS??? 172.31.0.154 0.0% 10 8.1 13.5 6.4 26.4 6.2 4. AS9498 169.168.18.125.dhcp.anaronline.net (125.18.168.169) 0.0% 10 5.2 6.8 4.9 13.6 2.6 5. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 At 11:58 PM - Telegram CEO Pavel Durov tweeted and accused Reliance (technically Rcom and not Jio) for outage of Telegram outside of India by BGP hijacking. Indian telecom Reliance is sabotaging access to Telegram for millions of users OUTSIDE India (including the UAE) via a rogue method called BGP hijacking. The sabotage seems intentional, as Reliance has ignored multiple reports. This may be part of a competitive war, as... -- Pavel Durov (@durov) June 16, 2026 Technically it's true that Rcom AS18101 has hijacked Telegram's prefixes. Take e.g 91.105.192.0/23 - AS18101 started originating this prefix at 16:14:19 GMT / 21:44:19 IST on 16 June as visible from many RIPE RIS collectors including RIPE RIS RRC01 in London. It's bad and they should not ha ## Measuring IPv6 deployment on Indian Govt websites DevFeed: [Measuring IPv6 deployment on Indian Govt websites]() Original publisher: [Read original article]() Published: 2026-06-04T20:19:53Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Network](), [Internet](), [Website](), [Google](), [Cloudflare](), [amazon](), [Amazon Web Services]() Tags: [airtel](), [akamai](), [aws](), [cloudflare](), [dns](), [google](), [india](), [ipv6](), [jio](), [nixi](), [websites]() ### AI overview The article measures IPv6 support on Indian government websites using certificate transparency logs and checks for working IPv4 and IPv6 endpoints. Among 4,924 examined domains under gov.in and nic.in, 174, or about 3.5%, had working IPv6 web endpoints. ### Source excerpt India has done well on IPv6 deployment thanks to Jio taking the lead in 2016, along with Airtel & VI aggressively catching up. Many of us in the industry are very proud of the work done by these players, resulting in over 78% deployment of IPv6 when measured by APNIC / Google, etc. Jio and Airtel numbers are as high as 95% IPv6 preferred at this point in time. But that's one part of the Indian metrics. IPv6 deployment, DNSSEC usage or even Internet Exchange peering - one can find very different metrics depending on how one is measuring. Both APNIC & Google rely on Google's network and judge how (largely mobile) end users across India are connecting to their (IPv6-enabled) services, and this gives the "eyeballs" side of specs. One key element missing in the picture is IPv6 support on the Government of India websites. I am using "Govt. of India" loosely here. I mean the Central Govt, state governments, as well as UTs and any of their departments. I have always felt that deployment is very poor, as randomly looking across the critical government websites. The service either shows no DNS AAAA record or may have a AAAA record but does not respond to port 80/443, giving an idea of a broken deployment. Measuring deployment is hard since (as far as I know) there is no authoritative source of government domains. Likely NIXI or ERNET, etc. may hold them but then getting them may be a long process and may not work at all. Then I thought of certificate transparency logs. Most of the CAs would log TLS certificates issued in public logs. One can read these logs for *.gov.in and *.nic.in to get a list of all government. used domains under those well-known TLDs and the ones which took a TLS certificate. I did some extra checks, like verifying the A record, working website on IPv4, before looking for IPv6. That way I remove all non-existent/old/expired websites. Also, looked for and www. in some cases as TLS may be issued for both. In case of wildcard TLS certificates like *..gov.in ## Airtel-Tata Comm routing is cold potato in India? DevFeed: [Airtel-Tata Comm routing is cold potato in India?]() Original publisher: [Read original article]() Published: 2026-05-20T13:20:53Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Routing (disambiguation)](), [networking](), [BGP]() Tags: [airtel](), [arelion](), [as1299](), [as174](), [as4755](), [as9498](), [bgp](), [cogent](), [india](), [routing](), [tata-comm]() ### AI overview An analysis of traceroutes between Airtel (AS9498) and Tata Comm (AS4755) in India suggests their routing tends toward cold-potato behavior. The article explains hot- and cold-potato routing, compares Arelion and Cogent traces, and examines possible interpretations of an Airtel-to-Tata Comm trace. ### Source excerpt Over the years, I have seen a number of traces between Airtel (AS9498) and Tata Comm (AS4755) in India, which strongly suggests that routing tends to be 'cold potato' between them. By default, routing between large backbones that interconnect across different locations is typically 'hot potato' - meaning traffic exits to other ASNs as close to the source as possible Hot potato routing is common Hot potato routing is quite common across large backbones. Let's analyse this concept by tracing between Arelion AS1299 and Cogent AS174 from their respective looking glasses. Trace Arelion AS1299 (Frankfurt) -> Cogent AS174 (San Francisco) - 66.250.250.146 (ism01.sfo01.atlas.cogentco.com): Router: ffm-b11 / Frankfurt (Equinix FR5, Kleyerstrasse) Command: traceroute ipv4 66.250.250.146 timeout 1 source Loopback0 Tracing the route to 66.250.250.146 1 * * * 2 be7948.ccr42.fra05.atlas.cogentco.com (154.54.72.126) 1 msec 1 msec be5484.ccr41.fra05.atlas.cogentco.com (130.117.1.1) 1 msec 3 be3343.ccr41.ams03.atlas.cogentco.com (154.54.62.142) 9 msec be2950.ccr42.ams03.atlas.cogentco.com (154.54.72.41) 9 msec be3343.ccr41.ams03.atlas.cogentco.com (154.54.62.142) 9 msec 4 be9036.ccr82.lon05.atlas.cogentco.com (154.54.72.185) 104 msec be2182.ccr21.lpl01.atlas.cogentco.com (154.54.77.246) 104 msec 104 msec 5 port-channel8444.ccr92.lhr01.atlas.cogentco.com (154.54.72.182) 16 msec port-channel3464.ccr91.lhr01.atlas.cogentco.com (154.54.75.150) 17 msec 17 msec 6 be8668.ccr31.bos01.atlas.cogentco.com (154.54.167.29) 99 msec be3501.ccr42.jfk02.atlas.cogentco.com (154.54.95.101) 101 msec be8668.ccr31.bos01.atlas.cogentco.com (154.54.167.29) 104 msec 7 be8030.ccr22.alb02.atlas.cogentco.com (154.54.169.226) 104 msec port-channel2994.ccr92.cle04.atlas.cogentco.com (154.54.31.233) 99 msec be8029.ccr21.alb02.atlas.cogentco.com (154.54.169.222) 104 msec 8 be2718.ccr42.ord01.atlas.cogentco.com (154.54.7.129) 101 msec port-channel8023.ccr92.cle04.atlas.cogentco.com (154.54.169.197) 99 msec 99 msec 9 ## Airtel India - Europe routing issues DevFeed: [Airtel India - Europe routing issues]() Original publisher: [Read original article]() Published: 2026-01-28T22:15:04Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [Latency](), [BGP](), [Routing (disambiguation)]() Tags: [2026](), [airtel](), [arelion](), [as1299](), [as9498](), [bgp](), [europe](), [india](), [latency](), [routing]() ### AI overview The article investigates increased latency and significant packet loss between Airtel India and Europe beginning on 28 January 2026. Traceroutes and public BGP route data indicate traffic was taking an indirect path through the United States, while later updates report improved routing and restored connectivity after a MENA cable repair. ### Source excerpt Since 20:08 IST / 14:38 GMT on 28 Jan 2026, the latency between Airtel India and Europe has gone up along with significant packet loss. Here's an example of shortlist 300+ endpoints from Airtel India with European endpoints: Traceroutes Airtel Haryana -> Contabo Europe Start: 2026-01-29T03:52:33+0530 HOST: desktop Loss% Snt Last Avg Best Wrst StDev 1. AS??? _gateway (172.16.0.1) 0.0% 10 0.2 0.2 0.2 0.2 0.0 2. AS??? 10.240.9.204 0.0% 10 6.2 7.7 4.6 17.7 3.7 3. AS??? 172.31.0.155 0.0% 10 12.1 8.4 5.0 12.8 3.2 4. AS9498 173.168.18.125.dhcp.anaronline.net (125.18.168.173) 0.0% 10 5.1 6.5 5.0 8.0 1.2 5. AS??? 182.79.243.34 0.0% 10 266.6 262.7 259.1 276.3 5.3 6. AS1299 lax-b22-link.ip.twelve99.net (62.115.162.62) 0.0% 10 259.4 258.1 256.6 259.9 1.1 7. AS1299 lax-bb2-link.ip.twelve99.net (62.115.140.156) 10.0% 10 256.7 257.9 256.6 259.6 1.2 8. AS1299 dls-b7-link.ip.twelve99.net (62.115.140.247) 20.0% 10 323.4 324.2 322.6 326.2 1.2 9. AS1299 atl-b24-link.ip.twelve99.net (62.115.140.32) 0.0% 10 336.4 336.5 335.4 338.0 0.9 10. AS1299 atl-bb2-link.ip.twelve99.net (62.115.143.236) 0.0% 10 323.1 321.7 320.2 323.4 1.0 11. AS1299 ash-bb2-link.ip.twelve99.net (62.115.137.132) 40.0% 10 320.9 321.1 320.6 321.7 0.4 12. AS1299 prs-bb2-link.ip.twelve99.net (62.115.140.106) 0.0% 10 318.8 318.3 317.2 319.5 0.9 13. AS1299 laut-b2-link.ip.twelve99.net (62.115.136.185) 0.0% 10 325.7 326.0 324.3 327.7 1.3 14. AS1299 contabohubeurope-ic-385701.ip.twelve99-cust.net (213.248.67.11) 0.0% 10 325.8 324.4 322.8 326.4 1.2 15. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 17. AS51167 eu01.anuragbhatia.com (213.199.54.67) 0.0% 10 323.1 323.5 322.4 324.9 0.9 Reading this trace: This is Ambala " Airtel MPLS " Los Angeles Arelion AS1299 handover > Arelion Dallas > Arelion Atlanta > Arelion Ashburn > Arelion Paris > Europe Contabo Europe -> Airtel Haryana (CGNAT IP terminating in Saha (Ambala) Haryana): Start: 2026-01-29T03:53:51+0530 HOST: eu01.anuragbhatia.com Loss% Sn