# AS3257 Published articles for AS3257. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## Understanding multiple routes from same ASN DevFeed: [Understanding multiple routes from same ASN]() Original publisher: [Read original article]() Published: 2025-12-01T18:54:58Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [Routing (disambiguation)](), [Networks](), [Network]() Tags: [algorithm](), [as174](), [as3257](), [as3356](), [as6453](), [as9498](), [bgp](), [cisco](), [ipv6](), [router](), [routing](), [trace]() ### AI overview This article explains why the same autonomous system can select different routes to the same prefix. Using examples involving AS3257 and AS3356, it shows that different routers and observation points may choose different best paths according to BGP's route-selection process. ### Source excerpt A while back bgp.he.net added the feature of a live route propagation graph for a given prefix. Besides being near real-time, it is also specific to a prefix, e.g let's look up for 2401:4900:87f0::/44 (Airtel mobility - 5G prefix): https://bgp.he.net/net/2401:4900:87f0::/44#_graph What sometimes confuses people is why there are multiple paths from a given ASN towards the originator ASN. Many people assume multiple paths exist for different prefixes only, and that is not true. Take e.g in the above route propagation graph AS3356 has a direct route to AS9498 as well as via AS2914, AS6939, AS6453, etc. And this kind of multiple paths is not limited just to AS3356 (which is run by three companies as of now - Lumen in North America, Colt in the EU and Cirion in South America). Notice GTT AS3257 is also learning it via Cogent AS174 as well as Tata Comm AS6453. Which is actually "best path" as determined by the BGP? Quick short answer: Both! Why does this happen? This kind of routing often happens when the other side is a large network with multiple routers doing eBGP with multiple other larger networks & not anywhere in the upstream path. Let's take the GTT AS3257 example first before coming to AS3356 case (as AS3356 has something more to it as well, which I will cover after this one). Let's query 2401:4900:87f0::/44 on Hurricane Electric's super-lg and restrict output with AS3257 in the path - output here Path 2 shows GTT AS3257 learning it from Cogent AS174 but path 4 shows it's learning it from Tata Comm AS6453. Both of these are "best paths" as determined by BGP in the respective routers that feed the routes. Path 2 via Cogent is being fed into route-views.chicago while path 4 is being fed into RIPE RIS RRC12 (DE-CIX, Frankfurt). Let's look at the GTT looking glass and trace to this route in the Chicago and Frankfurt router: GTT Chicago > 2401:4900:87f0::1 IPv6 traceroute to 2401:4900:87f0::1 HOST: cr1-chi1-re1 Loss% Snt Last Avg Best Wrst StDev 1. 2001:668:0:2:ffff:0