# As4755

Published articles for As4755.

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](<https://devfeed.tech/articles/indian-backbones-need-as-path-filters-39786.md>)

Original publisher: [Read original article](<https://anuragbhatia.com/post/2026/09/india-routing-security/>)

Published: 2026-09-07T20:11:07Z

Content type: opinion

Language: en

Sources: [Personal blog of Anurag Bhatia](<https://devfeed.tech/sources/personal-blog-of-anurag-bhatia.md>)

Topics: [BGP](<https://devfeed.tech/topics/bgp.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Security](<https://devfeed.tech/topics/security.md>)

Tags: [airtel](<https://devfeed.tech/tags/airtel.md>), [as4755](<https://devfeed.tech/tags/as4755.md>), [as55836](<https://devfeed.tech/tags/as55836.md>), [as9498](<https://devfeed.tech/tags/as9498.md>), [bgp](<https://devfeed.tech/tags/bgp.md>), [india](<https://devfeed.tech/tags/india.md>), [jio](<https://devfeed.tech/tags/jio.md>), [network](<https://devfeed.tech/tags/network.md>), [rcom](<https://devfeed.tech/tags/rcom.md>), [routing](<https://devfeed.tech/tags/routing.md>), [tata-comm](<https://devfeed.tech/tags/tata-comm.md>)

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

## Telegram prefixes hijack by Rcom AS18101

DevFeed: [Telegram prefixes hijack by Rcom AS18101](<https://devfeed.tech/articles/telegram-prefixes-hijack-by-rcom-as18101-39780.md>)

Original publisher: [Read original article](<https://anuragbhatia.com/post/2026/06/telegram-prefix-hijack-by-rcom/>)

Published: 2026-06-16T19:44:03Z

Content type: opinion

Language: en

Sources: [Personal blog of Anurag Bhatia](<https://devfeed.tech/sources/personal-blog-of-anurag-bhatia.md>)

Topics: [BGP](<https://devfeed.tech/topics/bgp.md>), [networking](<https://devfeed.tech/topics/networking.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>)

Tags: [airtel](<https://devfeed.tech/tags/airtel.md>), [as15412](<https://devfeed.tech/tags/as15412.md>), [as18101](<https://devfeed.tech/tags/as18101.md>), [as4755](<https://devfeed.tech/tags/as4755.md>), [bgp](<https://devfeed.tech/tags/bgp.md>), [india](<https://devfeed.tech/tags/india.md>), [outage](<https://devfeed.tech/tags/outage.md>), [rcom](<https://devfeed.tech/tags/rcom.md>), [ripe-ris](<https://devfeed.tech/tags/ripe-ris.md>), [routers](<https://devfeed.tech/tags/routers.md>), [routing](<https://devfeed.tech/tags/routing.md>), [rpki](<https://devfeed.tech/tags/rpki.md>), [telegram](<https://devfeed.tech/tags/telegram.md>), [traffic](<https://devfeed.tech/tags/traffic.md>)

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

## Airtel-Tata Comm routing is cold potato in India?

DevFeed: [Airtel-Tata Comm routing is cold potato in India?](<https://devfeed.tech/articles/airtel-tata-comm-routing-is-cold-potato-in-india-39774.md>)

Original publisher: [Read original article](<https://anuragbhatia.com/post/2026/05/airtel-tata-comm-routing/>)

Published: 2026-05-20T13:20:53Z

Content type: opinion

Language: en

Sources: [Personal blog of Anurag Bhatia](<https://devfeed.tech/sources/personal-blog-of-anurag-bhatia.md>)

Topics: [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>), [networking](<https://devfeed.tech/topics/networking.md>), [BGP](<https://devfeed.tech/topics/bgp.md>)

Tags: [airtel](<https://devfeed.tech/tags/airtel.md>), [arelion](<https://devfeed.tech/tags/arelion.md>), [as1299](<https://devfeed.tech/tags/as1299.md>), [as174](<https://devfeed.tech/tags/as174.md>), [as4755](<https://devfeed.tech/tags/as4755.md>), [as9498](<https://devfeed.tech/tags/as9498.md>), [bgp](<https://devfeed.tech/tags/bgp.md>), [cogent](<https://devfeed.tech/tags/cogent.md>), [india](<https://devfeed.tech/tags/india.md>), [routing](<https://devfeed.tech/tags/routing.md>), [tata-comm](<https://devfeed.tech/tags/tata-comm.md>)

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