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