# AS9498 Published articles for AS9498. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Airtel plans to begin RPKI Route Origin Validation rollout on 22 September 2026 DevFeed: [Airtel plans to begin RPKI Route Origin Validation rollout on 22 September 2026]() Original publisher: [Read original article]() Published: 2026-09-14T09:00:47Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [Routing Security](), [Security]() Tags: [airtel](), [apnic-62](), [as9498](), [india](), [ipv4](), [ipv6](), [routing-security](), [rov](), [rpki]() ### AI overview Airtel has told customers it plans to begin rolling out RPKI Route Origin Validation on 22 September 2026. The article examines 726 RPKI-invalid routes in Airtel's table, including 108 IPv4 and 618 IPv6 routes, and discusses their visibility outside India. ### Source excerpt Just back from Mumbai after APNIC 62 and Equinix's India Peering Forum. On excellent news: Airtel has started sending emails to its customers about RPKI RoV (Route Origin Validation). As per the mail, Airtel will start RPKI RoV soon and has mentioned 22 Sep 2026 as the timeline when they will start rolling out RoV. This is excellent news on the routing security front, and kudos to Airtel (AS9498) for taking the lead here among other large Indian backbones. This brings up the important question of how many routes exist in their table which are RPKI RoV invalids as of today? Looking at their announcements, I see the following: RPKI Valids: 33,735 RPKI Unknown: 4632 RPKI invalids: 726 This is for their table, including downstream routes. One can view the complete list of those 726 invalids, including prefix and AS_PATH here. One interesting thing here is that out of 726, 140 are from Airtel fixedline AS24560 and 122 are from Airtel Mobility. In terms of address family, there are 108 invalids from IPv4 and 618 from IPv6. How many of these invalids are single-homed vs multi-homed? This is important to check, as often the argument against RoV given by various operators in past was that they were losing traffic to their competitors. When I checked, I do not see any of these prefixes visible outside of India behind a transit-free / tier 1 network without AS9498 in the path. It could be because Tata Comm AS6453 drops RPKI invalid already & most of these are not dual-homed via Jio AS64049. So unless a less specific RPKI valid announcement is there, these are anyway largely blackholed for now by networks & IXPs doing RoV outside of India. Let's hope other Indian backbones also start doing RPKI RoV soon. Happy routing! 😀 ## 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 ## Airtel India - Europe routing issues DevFeed: [Airtel India - Europe routing issues]() Original publisher: [Read original article]() Published: 2026-01-28T22:15:04Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [Latency](), [BGP](), [Routing (disambiguation)]() Tags: [2026](), [airtel](), [arelion](), [as1299](), [as9498](), [bgp](), [europe](), [india](), [latency](), [routing]() ### AI overview The article investigates increased latency and significant packet loss between Airtel India and Europe beginning on 28 January 2026. Traceroutes and public BGP route data indicate traffic was taking an indirect path through the United States, while later updates report improved routing and restored connectivity after a MENA cable repair. ### Source excerpt Since 20:08 IST / 14:38 GMT on 28 Jan 2026, the latency between Airtel India and Europe has gone up along with significant packet loss. Here's an example of shortlist 300+ endpoints from Airtel India with European endpoints: Traceroutes Airtel Haryana -> Contabo Europe Start: 2026-01-29T03:52:33+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 6.2 7.7 4.6 17.7 3.7 3. AS??? 172.31.0.155 0.0% 10 12.1 8.4 5.0 12.8 3.2 4. AS9498 173.168.18.125.dhcp.anaronline.net (125.18.168.173) 0.0% 10 5.1 6.5 5.0 8.0 1.2 5. AS??? 182.79.243.34 0.0% 10 266.6 262.7 259.1 276.3 5.3 6. AS1299 lax-b22-link.ip.twelve99.net (62.115.162.62) 0.0% 10 259.4 258.1 256.6 259.9 1.1 7. AS1299 lax-bb2-link.ip.twelve99.net (62.115.140.156) 10.0% 10 256.7 257.9 256.6 259.6 1.2 8. AS1299 dls-b7-link.ip.twelve99.net (62.115.140.247) 20.0% 10 323.4 324.2 322.6 326.2 1.2 9. AS1299 atl-b24-link.ip.twelve99.net (62.115.140.32) 0.0% 10 336.4 336.5 335.4 338.0 0.9 10. AS1299 atl-bb2-link.ip.twelve99.net (62.115.143.236) 0.0% 10 323.1 321.7 320.2 323.4 1.0 11. AS1299 ash-bb2-link.ip.twelve99.net (62.115.137.132) 40.0% 10 320.9 321.1 320.6 321.7 0.4 12. AS1299 prs-bb2-link.ip.twelve99.net (62.115.140.106) 0.0% 10 318.8 318.3 317.2 319.5 0.9 13. AS1299 laut-b2-link.ip.twelve99.net (62.115.136.185) 0.0% 10 325.7 326.0 324.3 327.7 1.3 14. AS1299 contabohubeurope-ic-385701.ip.twelve99-cust.net (213.248.67.11) 0.0% 10 325.8 324.4 322.8 326.4 1.2 15. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 17. AS51167 eu01.anuragbhatia.com (213.199.54.67) 0.0% 10 323.1 323.5 322.4 324.9 0.9 Reading this trace: This is Ambala " Airtel MPLS " Los Angeles Arelion AS1299 handover > Arelion Dallas > Arelion Atlanta > Arelion Ashburn > Arelion Paris > Europe Contabo Europe -> Airtel Haryana (CGNAT IP terminating in Saha (Ambala) Haryana): Start: 2026-01-29T03:53:51+0530 HOST: eu01.anuragbhatia.com Loss% Sn ## 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