# Tata Comm Published articles for Tata Comm. 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 ## 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