# Jio Published articles for Jio. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## 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 ## Strange route with Jio and GTT as adjacency DevFeed: [Strange route with Jio and GTT as adjacency]() Original publisher: [Read original article]() Published: 2026-04-30T19:42:16Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [Network](), [clickhouse](), [Internet]() Tags: [as3257](), [as55836](), [bgp](), [clickhouse](), [gtt](), [internet](), [jio](), [network](), [route]() ### AI overview The article investigates a strange BGP route announcement involving Jio (AS55836), GTT (AS3257), Tata Comm (AS6453), Airtel (AS9498), and Brazilian networks. Querying a ClickHouse table of route-collector data showed the route only at collectors in Rio de Janeiro and Fortaleza, and the author could not determine which of three Brazilian ASNs generated it. ### Source excerpt Last month (on 18th April 2026), I saw an alert for a strange route announcement: Prefix AS Path Origin ASN 117.120.58.0/23 262427 262761 263444 6453 3257 55836 9498 134863 134863 Background While this specific alert triggered because it had three large Indian backbones - Tata Comm (AS6453), Jio (AS55836) and Airtel (AS9498) and normally this would appear just as a leak by Jio for routes learnt from Airtel (a known peer of Jio), but AS3257 before Jio makes it strange and interesting. AS3257 is a known transit-free network GTT. Jio is not known to be connected to them at all. Jio does have a mix of transit & peering internationally via AS64049 but not via AS55836. When they started, they had some transit via Tata Comm (AS4755) for a few early days of the launch. After that AS55836 only has peering with Tata Comm (AS4755) and Airtel (AS9498), besides technically transit via their own AS64049 which takes transit from Arelion (AS1299), Cogent (AS174) and NTT (AS2914) and a mix of transit/peering relations with Lumen (AS3356). Who possibly caused it? The AS_PATH here: 262427 262761 263444 6453 3257 55836 9498 134863 can be read backwards to understand the announcement: SP Internet (134863) > Airtel (9498) > Jio (55836) > GTT (AS3257) > Tata Comm (AS6453) > Open X Tecnologia (AS263444) > Sinal Br Telecom (AS262761) > Invista Net Provedor (AS262427). As mentioned in a post last year, I hold recent routes in a Clickhouse table from various route collectors. This makes it easy to query a large number of routes quickly. SELECT count(*) FROM bgp.table Query id: df33f954-7fbd-41a3-8de2-184990ca06d4 ┌─────count()─┐ 1. │ 68882920533 │ -- 68.88 billion └─────────────┘ 1 row in set. Elapsed: 0.034 sec. Let's ask this table of 68.88 billion routes for routes matching AS_PATH: 3257 55836: SELECT timestamp, prefix, as_path, collector FROM bgp.table WHERE arrayExists(i -> ((i < length(as_path)) AND ((as_path[i]) = 3257) AND ((as_path[i + 1]) = 55836)), arrayEnumerate(as_path)) Query id