# Personal blog of Anurag Bhatia Recent content on Personal blog of Anurag Bhatia 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 ## Incremental backup on AWS Glacier with rustic DevFeed: [Incremental backup on AWS Glacier with rustic]() Original publisher: [Read original article]() Published: 2026-08-19T21:04:01Z Content type: tutorial Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [backups](), [restic](), [Amazon Web Services](), [Amazon S3](), [Rust](), [Open Source](), [Feathers]() Tags: [aws](), [aws-glacier-deep-archive](), [backblaze-b2](), [backup](), [backups](), [client](), [config](), [cost](), [data](), [encryption](), [encryption-at-rest](), [incremental](), [lifecycle](), [open-source](), [password](), [restic](), [restore](), [rust](), [rustic](), [s3](), [snapshots]() ### AI overview A practical guide to using rustic, a Rust implementation compatible with restic, for incremental backups with AWS Glacier cold storage. It explains keeping backup data in cold storage while maintaining metadata in S3 Standard or Backblaze B2 so snapshots, incremental backups, and targeted restores remain possible. ### Source excerpt I have been a heavy restic user for several years. In Jan of this year, I tried making restic work with AWS Glacier deep archive but it did not work out. AWS Glacier Deep Archive, for those who may not know, is one of the cheapest storage options, with costs as low as $1/TB, but with very expensive retrieval due to high egress charges from AWS, in addition to retrieval fees, API charges, etc. It can act as a backup of last resort, kind of like insurance if everything else fails, since it costs roughly 1/7th of what Backblaze B2 charges for the same data ($6.95/TB/month). Restic by design is not compatible with Glacier because it stores a mix of data blobs and tree blobs inside /data. Thus, as AWS lifecycle rules move data from S3 Standard to Glacier, basic repo operations start failing. They do have some experimental support as per FAQ, but it did not work out for me when I tried in Jan. A few days back, I came across an open-source project named rustic -- it's a restic implementation in Rust and supports cold storage. The rustic client is compatible with a traditional restic repo. Rustic and cold storage Rustic supports AWS Glacier as well as OVH cold storage. The way it works is: they keep all data in cold storage and a copy of the metadata in hot storage. This additional copy of metadata in hot storage allows operations like incremental backups, viewing snapshots, and requesting restores where only the specific data blobs needed for the restore are pulled from Glacier. This additional hot storage can sit on S3 standard or even Backblaze B2 (which I prefer due to zero API cost). Demo 1) Create repo Let's create two buckets - one in S3 (to store data in Glacier) and one on Backblaze B2 to hold an additional copy of metadata. > rclone mkdir s3:rustic-demo-cold > rclone mkdir b2:rustic-demo-hot 2) Create rustic config profile This file will define the cold and hot repo locations, along with the password file location, restoration command syntax, etc. [repository] repo ## History of Transit-Free (Tier 1) Networks DevFeed: [History of Transit-Free (Tier 1) Networks]() Original publisher: [Read original article]() Published: 2026-08-05T21:48:07Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Routing (disambiguation)](), [BGP](), [networking](), [Internet]() Tags: [as1](), [as1239](), [as174](), [as701](), [bgp](), [history](), [networks](), [ripe-ris](), [routing](), [tier1](), [transit]() ### AI overview The article examines the history of transit-free, or Tier 1, networks and tracks when autonomous systems became or ceased to be transit-free. It discusses historical evidence from BGP routing table dumps, RIPE RIS, Oregon Route Views, and related records. ### Source excerpt I find the concept of transit-free / Tier 1 networks fascinating. These are networks which, by definition, are transit-free. They do not have any transit and can reach the entire routing table just through peering relationships. The importance of these networks has reduced over time as more and more peering happens directly between eyeball networks and content networks. But regardless, I always find it fascinating that these networks effectively define the full autonomy of the internet routing table. Together with the trust in 13 magical root DNS servers and these transit-free networks define what we call "the internet" today. I was once chatting with my friend and guru Martin Levy (now happily retired) about which networks were possibly transit-free when the internet started. He suggested that Wikipedia history on Tier 1 networks has many of them. The challenge with the Wikipedia page on Tier 1 networks is that the list of transit-free networks appears on 14 Nov 2005. This leaves a gap around which networks were transit-free before Nov 2005. Before Nov 2005, Nov 2005 and till now I had an email exchange with Mr Randy Bush and he kindly replied with some hints. According to him AS701/702/703/704 (UUnet / now Verizon), AS174 (PSI / now Cogent), AS1 (BBN) and AS1239 (Sprint) were transit-free networks before this period. The oldest routing dump on RIPE RIS is from 1999 but those dumps are very small and contain too few routes to establish anything. RIPE RRC00 from September 1999 has "view" files, which are essentially a "sh ip bgp dump" and the following month they seem to have moved to the MRT format. On Oregon Route Views, the oldest I can find is this dump from 08 Nov 1997. This brings me to a possible, although not perfect, method to document the history of transit-free networks. Timeline Method Before-Nov 1997 Assume AS1, AS1239, AS701 and AS174 to be transit-free and find who else was adjacent to all of them along with BGP routing table dumps Pre - Nov 2005 Use ## Use of VRF in dual WAN setup DevFeed: [Use of VRF in dual WAN setup]() Original publisher: [Read original article]() Published: 2026-08-03T20:58:23Z Content type: tutorial Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [networking](), [MikroTik](), [Prometheus](), [Containers]() Tags: [containers](), [mikrotik](), [prometheus](), [router](), [routing](), [routing-table](), [vrf]() ### AI overview This article describes migrating a MikroTik home router from multiple routing tables to a VRF-based dual-WAN design. It explains how shared routing domains caused router-bound traffic to return through the wrong ISP during partial outages and made ISP-specific routing for measurement containers difficult. VRFs provide separate layer-3 routing domains for the WAN links, while Prometheus and Semaphore handle packet-loss-based switchover. ### Source excerpt Over the weekend I migrated my home router from multiple routing tables to a VRF-based design, placing each WAN uplink into its own VRF. While multiple routing tables worked for basic policy routing, they have some limitations and that led to several edge cases that became increasingly difficult to work around. Issues with the setup: If the active default route pointed to ISP1, traffic arriving on ISP1 naturally returned via ISP1. However, traffic terminating on the router and arriving via ISP2 would also be replied to through ISP1, since both uplinks still shared the same routing domain. This did not cause issues for traffic on devices below the router but was bad for traffic terminating on the router interface itself. Due to the above reason, I recently lost access to my home router while I was out of the country because ISP1 had a partial outage (their transit went down, peering stayed up) & due to distributed tooling, the auto switch trigger could not happen either to take care of it. Packets from ISP 2 were being returned via the ISP1 route & thus blackholed. I have a special case where I want most of the devices on a redundant setup but some devices (containers) on specific ISP only. These are measurement containers running blackbox exporter behind a specific ISP as well as RIPE Atlas. I don't want these to switch over for accuracy of measurement. Without VRF it was ugly config-wise, as ISP1 failure will lead to ISP2 routing even when the specific routing table did not have that route. Old Setup My old setup was running multiple routing table pairs: ISP1 only & ISP1 as primary (ISP2 as secondary) ISP2 only & ISP2 as primary (ISP1 as secondary) All WAN interfaces, LAN interfaces and routing tables were in the same single "Main" VRF. This by default takes care of full outage events, fibre cuts, etc. For packet loss-based switchover, I have set up Prometheus + Semaphore as covered in this post last year. Understanding VRF VRF is Virtual Routing and Forwarding. It ## Beyond 5G: The Two Biggest Challenges for India's Internet DevFeed: [Beyond 5G: The Two Biggest Challenges for India's Internet]() Original publisher: [Read original article]() Published: 2026-07-02T19:50:52Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Internet](), [Networks](), [networking](), [5G]() Tags: [5g](), [airtel](), [broadband](), [cgnat](), [ftth](), [india](), [internet](), [jio](), [logging](), [networks](), [pm-wani](), [resilience](), [routing](), [wifi]() ### AI overview This opinion argues that India's internet ecosystem is held back by duplicated fixed-line last-mile infrastructure and difficulty sharing Wi-Fi legally. It proposes neutral last-mile fibre infrastructure, allowing ISPs to compete on service quality, and discusses contention in PON and AON networks. ### Source excerpt The recent debate around Airtel's priority 5G generated plenty of noise. Personally, I'm not a fan of it either but Airtel and Jio are private companies. Their job is to maximise shareholder value, not to maintain market competition. The real question is why competition remains so limited. And by competition, I don't mean another mobile operator. I mean fixed-line broadband. Two long-standing problems continue to hold India's internet ecosystem back. 1. Every ISP builds its own last mile In the early days of FTTH this was understandable. In 2026, it feels increasingly wasteful. At my home in Haryana, around a dozen FTTH providers are available. The pole outside carries 14 fibre cables from different operators -- all solving the same problem independently. The last mile isn't where ISPs differentiate. Fibre from ISP A isn't inherently "faster" than fibre from ISP B. The real differentiation is in the network behind that fibre capacity, routing, peering, resilience and customer support. Yet every provider continues deploying duplicate infrastructure. Even Airtel and Jio increasingly push Fixed Wireless Access because expanding FTTH remains expensive. Instead of parallel deployments, we should encourage neutral last-mile infrastructure. A small number of regulated fibre providers could deploy high core count cables, while ISPs lease strands and compete on service quality rather than digging the same streets repeatedly. This will also help in fixing streets which look quite ugly with excess fibre routing in all directions. Earlier this year, Stefan SchΓΌller published an excellent article, The Free Market Lie: Why Switzerland Has 25 Gbit Internet and America Doesn't comparing broadband infrastructure in Switzerland, the US and Germany. It's well-researched and provides useful context for many of the points discussed here.I do disagree with one aspect of the article - its comparison of Passive Optical Networks (PON) and Active Optical Networks (AON). Contention exists thro ## RFC8950: Announce IPv4 with an IPv6 next-hop DevFeed: [RFC8950: Announce IPv4 with an IPv6 next-hop]() Original publisher: [Read original article]() Published: 2026-06-22T08:34:09Z Content type: tutorial Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP]() Tags: [bgp](), [frr](), [ipv4](), [ipv6](), [rfc8950]() ### AI overview A tutorial-style explanation of RFC8950, which enables IPv4 routes to use IPv6 next hops over MP-BGP sessions. It describes IPv6-only backbone use cases, explains that the change affects the control plane while IPv4 remains unchanged on the wire, and outlines a Container Lab demonstration using FRR. ### Source excerpt For the last few days I have been playing with RFC8950 setup, which allows routing of IPv4 on top of IPv6. While logically it's quite simple, it has a very powerful application towards making "IPv4 an optional" feature riding on top of an IPv6 network (but without any tunnels!) Some of the interesting use cases: A large network can run IPv6 only everywhere on its core and leave IPv4 only on edge devices. This can work without customers doing any tweaking at their end. They still do things the old way but Backbone can run IPv6 only at its core. An IP transit backbone can run IPv6 only while exchanging IPv4 routes with its customers/peers/upstream over IPv6 sessions. So IPv4 as a "feature" stays but the network in itself is IPv6 only without the overhead of IPv4 interface config, BGP session config, firewall config, etc. An IXP can offer services without IPv4 essentually by using a (unique) IPv6 at the IX LAN & running route server to exchange both IPv4 & IPv6 routes over the IPv6 only session. Thus what 464XLAT did to the mobile networks - this has the potential to do that for the backbone networks. How does it work? Multi-protocol BGP (MP-BGP) supports announcement of IPv4 routes over IPv6 sessions with IPv4 next-hops and IPv6 routes over IPv4 sessions with IPv6 next-hops. RFC8950 extends this feature for IPv4 to have IPv6 next-hops. So for IPv4 address, next hop is IPv6, IPv6 reach works via usual NDP and IPv4 rides on ethernet frames to the same MAC as discovered by the NDP. Technically RFC8950 only impacts control plane decisions by using IPv6 as the control plane but keeps the data plane as it is. IPv4 stays IPv4 & goes as IPv4 over the wire unlike say some tunnel or 464xLAT etc. Hardware support As of now it's quite widely supported by a lot of routing platforms like Juniper JunOS, Cisco IOS XR, Nokia SR OS, Mikrotik, Huawei, BIRD, FRR etc. So, it is very likely supported if you are running a recent version of the OS. Demo lab Here's a fun lab with two customer ## Analysis of Telegram IPv6 BGP announcements by Indian ISPs DevFeed: [Analysis of Telegram IPv6 BGP announcements by Indian ISPs]() Original publisher: [Read original article]() Published: 2026-06-17T23:52:47Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [DDoS]() Tags: [as135709](), [as152144](), [as45820](), [bgp](), [ddos](), [lightstorm](), [rfc7999](), [rtbh](), [telegram](), [ttsl]() ### AI overview The article examines unusual BGP announcements for Telegram IPv6 prefixes by several Indian ISPs after a reported Telegram prefix hijack. It proposes that existing BGP blackholing configurations may have been used to block Telegram traffic, while noting this is the author's interpretation. ### Source excerpt Since the Telegram's prefix hijack (4 days ago on 17-Jun-2026) by RCom, there is visible noise in the BGP routing table from multiple other Indian ISPs, including Tata Teleservices (AS45820) / Lightstorm (AS135709/AS152144), etc. mostly in IPv6. Let's look at 2a0a:f280::/48 (Live lookup here) Notice all the ASNs here largely seem to be downstreams or peers of AS45820 in India, no major large peer or upstream that would take this announcement outside of India. Similarly, take the case of aggregate - 2a0a:f280::/32. This has TTSL (AS45820) as well as Lightstrom (AS152144/135709) originating these prefixes to smaller peers. Analysis: Possible reason and impact of this behaviour Today I tested some config in lab to see why this could be happening. Here's what I strongly feel is happening (quite sure, unless someone has a better explanation): Indian Govt. has asked ISPs to block Telegram and unlike past blocks mostly at the DNS layer, ISPs have been asked to drop IPs as well. Technically in these cases ISPs could simply add a blackhole route and that would drop traffic going towards these prefixes (from their customers) and that would not be visible at BGP (control plane) but only in traceroutes (data plane). If any of these customers had a full routing feed from those respective ISPs, they would keep on learning Telegram's route with the correct/expected AS_PATH and expected origin AS. Very likely these players had blackhole config setup for the DDoS protection and ended up using the same i.e they are treating Telegram's IPv6 prefixes like they would treat their own when under attack. Also, blackholing is a common practice during DDoS attacks. Imagine a network with a 100G uplink gets hit by a 400G volumetric attack. It will take up all the link bandwidth and thus in these cases ISPs blackhole their own (or downstream) IPs (often small - single /32s or a few) and they signal this to their BGP adjacencies as well. There is a standard BGP blackhole community: 65535:666 as ## Telegram prefixes hijack by Rcom AS18101 DevFeed: [Telegram prefixes hijack by Rcom AS18101]() Original publisher: [Read original article]() Published: 2026-06-16T19:44:03Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [Routing (disambiguation)]() Tags: [airtel](), [as15412](), [as18101](), [as4755](), [bgp](), [india](), [outage](), [rcom](), [ripe-ris](), [routers](), [routing](), [rpki](), [telegram](), [traffic]() ### 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 ## Mapping major CDNs across the globe DevFeed: [Mapping major CDNs across the globe]() Original publisher: [Read original article]() Published: 2026-06-06T13:17:04Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [Networks](), [Routing (disambiguation)](), [TLS (Transport Layer Security)](), [data](), [Amazon Web Services](), [Google](), [Netflix](), [Microsoft](), [Pingora]() Tags: [akamai](), [apple](), [aws](), [bgp](), [cdn](), [data](), [dns](), [facebook](), [fna](), [ggc](), [google](), [major](), [mapping](), [microsoft](), [netflix](), [networks](), [oca](), [routing](), [tls]() ### AI overview This article maps major content delivery networks worldwide by examining routed IP prefixes, open port 443 services, TLS certificate names, autonomous system numbers, and geographic data. It reports global and India-specific coverage figures for Google GGC, Facebook FNA/MNA, Netflix, Akamai, Apple, Microsoft, and AWS CloudFront, while noting that certificate-based identification may miss some deployments. ### Source excerpt In Dec 2022 I mapped popular CDNs like Google GGC, Facebook FNA, Akamai, etc. across Indian networks (post here). Since it's been close to 4 years now, I wanted to do that again. This time, I decided to expand the scope to the entire globe instead of just the Indian networks. Mapping logic The logic here is simple: get unique prefixes from the global routing table, break them into /24s, uniquely sort out /24s, and this gives all routed IP addresses in the world in batches of /24s (256 IPs). Next, identify the ones with an open port 443 and then connect to each of them to figure out the TLS certificate common name. Next, map those IP addresses to AS numbers, locations, etc., using Maxmind's GeoIP Lite databases. Essentially, I am using the BGP routing table instead of scanning the entire 0.0.0.0/0 to avoid scanning for prefixes which are not routed in the global table as well as reserved private IPs, etc. Global stats CDN Provider No. unique ASNs TLS domain Details list URL Google GGC 4247 googlevideo.com csv & json Netflix OCA 2903 oca.nflxvideo.net, assets.nflxext.com csv & json Facebook FNA 2548 'fbcdn.net', fna.whatsapp.net csv & json Akamai 1094 edgesuite.net, edgekey.net, akamaized.net, akamaihd.net, akamaized.net, akamai.net csv & json Microsoft 1655 microsoft.com csv & json Apple 974 apple.com & itunes.apple.com csv & json AWS Cloudfront 217 *.amazonaws.com & *.awsstatic.com csv & json ASN-CDN Mapping table I have mapped ASNs with the presence of each of these CDNs like last time. This makes it easy to read the data instead of going through each of the files separately. Full data in Google Sheet link here and raw CSV is also published here. Notes: Facebook FNA serving Facebook with *.fbcdn.net is almost the same if I look for *.fna.whatsapp.net. Apple seems to have presence in over 236 locations with PCH/Woodynet for hosting their DNS over HTTPS endpoint: doh.dns.apple.com (detailed list here) GGC has a global coverage across 215 countries across the world, f ## Measuring IPv6 deployment on Indian Govt websites DevFeed: [Measuring IPv6 deployment on Indian Govt websites]() Original publisher: [Read original article]() Published: 2026-06-04T20:19:53Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Network](), [Internet](), [Website](), [Google](), [Cloudflare](), [amazon](), [Amazon Web Services]() Tags: [airtel](), [akamai](), [aws](), [cloudflare](), [dns](), [google](), [india](), [ipv6](), [jio](), [nixi](), [websites]() ### AI overview The article measures IPv6 support on Indian government websites using certificate transparency logs and checks for working IPv4 and IPv6 endpoints. Among 4,924 examined domains under gov.in and nic.in, 174, or about 3.5%, had working IPv6 web endpoints. ### Source excerpt India has done well on IPv6 deployment thanks to Jio taking the lead in 2016, along with Airtel & VI aggressively catching up. Many of us in the industry are very proud of the work done by these players, resulting in over 78% deployment of IPv6 when measured by APNIC / Google, etc. Jio and Airtel numbers are as high as 95% IPv6 preferred at this point in time. But that's one part of the Indian metrics. IPv6 deployment, DNSSEC usage or even Internet Exchange peering - one can find very different metrics depending on how one is measuring. Both APNIC & Google rely on Google's network and judge how (largely mobile) end users across India are connecting to their (IPv6-enabled) services, and this gives the "eyeballs" side of specs. One key element missing in the picture is IPv6 support on the Government of India websites. I am using "Govt. of India" loosely here. I mean the Central Govt, state governments, as well as UTs and any of their departments. I have always felt that deployment is very poor, as randomly looking across the critical government websites. The service either shows no DNS AAAA record or may have a AAAA record but does not respond to port 80/443, giving an idea of a broken deployment. Measuring deployment is hard since (as far as I know) there is no authoritative source of government domains. Likely NIXI or ERNET, etc. may hold them but then getting them may be a long process and may not work at all. Then I thought of certificate transparency logs. Most of the CAs would log TLS certificates issued in public logs. One can read these logs for *.gov.in and *.nic.in to get a list of all government. used domains under those well-known TLDs and the ones which took a TLS certificate. I did some extra checks, like verifying the A record, working website on IPv4, before looking for IPv6. That way I remove all non-existent/old/expired websites. Also, looked for and www. in some cases as TLS may be issued for both. In case of wildcard TLS certificates like *..gov.in ## 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 ## 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 ## Netflow for home router & Linux servers DevFeed: [Netflow for home router & Linux servers]() Original publisher: [Read original article]() Published: 2026-04-09T20:20:00Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [netflow](), [Linux](), [Monitoring](), [MikroTik](), [Docker]() Tags: [akvorado](), [docker](), [linux](), [mikrotik](), [monitoring](), [netflow](), [pmacct](), [router]() ### AI overview The author describes running an open-source NetFlow collection setup for a home MikroTik router and Linux servers. They compare Pmacct and Akvorado, use Akvorado as the main system and Pmacct as a Linux exporter, and filter collected traffic to examine regular end-device usage. ### Source excerpt For the last few weeks, I have been running a NetFlow collector for the home router. This is something I wanted to do for a long time, but I was missing the time to invest. There are a few open source options, and I guess many commercial solutions offering NetFlow, often bundled with other products. My personal monitoring is 100% open source and presently running Prometheus + Thanos + Node Exporter + Blackbox Exporter + SNMP Exporter + Grafana + Grafana Loki + a few more exporters. So I started looking for open source options which are still under active development and supported. Two of them are quite popular - Pmacct and Akvorado. Pmacct is extremely advanced, flexible, but at the same time overall complicated to set up (and maintain). Even their quickstart file 3100-line file is full of setup options. On the other hand, Akvorado seems simpler to maintain. Some complications, anyway, are expected with NetFlow because the goal is not just to collect the data but also to have a system to store it, analyse it, map IPs to location/AS numbers, etc., dashboards, etc. It's a tool developed by French ISP Free, which is part of the Iliad group, which also owns Scaleway. Setting up Akvorado is easy if you are familiar with Docker. They have a simple 4 command quick-start which deploys all their containers as part of the stack. They deploy a few containers as part of the overall stack. The big picture page on their demo site documentation covers the overall architecture. I started feeding it data from the home (Mikrotik) router and later also added various Linux servers/VMs I manage for R&D, DNS, as well as to host this blog and other infrastructure. For Linux, I am using Pmacct as an exporter, as Akvorado's documentation suggests using it in exporter mode and has a sample config which works. Some data Now that it's been running for a few weeks, I can see major sources of data coming to the home. Before jumping to data, it's important to note that I have regular camera feeds ## Who can light fibre in India? DevFeed: [Who can light fibre in India?]() Original publisher: [Read original article]() Published: 2026-02-21T20:49:05Z Content type: article Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Internet](), [Cloud](), [hosting](), [datacenter]() Tags: [backhaul](), [cloud](), [connectivity](), [datacenter](), [hosting](), [india](), [infrastructure](), [mpls](), [regulatory](), [routers](), [vlan]() ### AI overview The article discusses Indian telecom licensing rules for deploying, lighting, and reselling fibre outside a building. It explains that IP-1 providers may lease passive dark-fibre infrastructure but may not light it, while appropriately licensed ISPs may light fibre for end-user internet access and their own backhaul, not point-to-point connectivity. ### Source excerpt Friend and his two homes... Recently, a friend of mine mentioned his plan to procure dark fibre to connect two of his homes. His idea was straightforward - get LCO to give a dark strand between both homes and run Bidi optics over it. I ended up telling him that while his idea is technically fine, as modern optics can easily cover that sort of distance, it would be illegal as per Indian telecom laws! It wasn't just him, but numerous content players, hosting companies, and Cloud players find it a bit odd when they find this out. In this post, I will document what is allowed and what is not allowed. Advance warning: I am a technical person & do not know much about regulatory. Whatever I am sharing here is what I have learned from my friends who have expertise in the subject. Indian telecom rules are overly complex and can have a different set of interpretations, and often go into the grey area. I welcome readers to share feedback if they are aware of something which isn't correct as per the regulation. With that warning out of the way, I will proceed with the post. Understanding licensing In India, when fibre is going outside of a given building, one needs to have a license to light it. In fact, not just "lighting up a dark fibre" but to deploy and resell dark fibre, one needs a license (IP-1). Infrastructure Provider Category 1 (or IP-1) is considered an easy license which can be used to sell passive assets such as dark fibre, ducts, towers, etc. Active infra i.e lighting up fibre, is not allowed under this license, and it's expected that an IP-1 holder leases their dark fibre only to a license holder who is authorised to light the fibre. Within a building, campus, datacenter, home etc one can deploy a light fibre but as soon as it goes outside of that it becomes a bit of a grey area depending on the use case. An Internet Service Provider (ISP) holding an ISP license or Unified License with ISP authorisation can light fibre but only for two specific purposes: Offering i ## 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 ## Investigating an Apparent BGP Route Origin Anomaly Involving Liberty Global DevFeed: [Investigating an Apparent BGP Route Origin Anomaly Involving Liberty Global]() Original publisher: [Read original article]() Published: 2026-01-20T18:32:42Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [Routing (disambiguation)](), [Networks]() Tags: [as12302](), [as35505](), [as44682](), [as6830](), [as8751](), [bgp](), [internet](), [liberty-global](), [network](), [ripe-ris](), [routing]() ### AI overview The article investigates why bgp.he.net appeared to show Liberty Global (AS6830) originating Vodafone Romania (AS12302) prefixes. A Liberty Global looking glass showed that the network was learning a sample prefix from Vodafone C&W (AS1273), while a RIPE RIS path suggested the route was being propagated through AS8751, AS44682, and AS35505. The author suspects a false route generated by a route optimiser but cannot determine which of those networks held it. ### Source excerpt Earlier in the day, I came across Liberty Global (AS6830) seemingly originating several Vodafone Romania (AS12302) prefixes. Source: https://bgp.he.net/AS6830#_prefixes This is highly unusual because AS6830 is a large transit-free network. I have seen some transit-free networks leaking routes, but originating a large number of prefixes is not common. It has massive stakes from Belgium-based Telenet to Virgin Media, etc. To verify if they are actually originating these or not, let's check from their looking glass for one of the prefixes here: 46.97.104.0/24 via their PoP at Interxion FRA6 Frankfurt: This clearly shows that their own router is learning it from Vodafone C&W AS1273 and not holding the fake route. The origin is AS12302 (Vodafone Romania). So why does that prefix appear in bgp.he.net? Let's look at real-time lookup from super-lg: Reading this AS_PATH: 35505 44682 8751 6830 So RIPE RIS RRC22 in Bucharest, Romania "learns" this from AS35505 (Pronet Solutii IT SRL) which learns it from AS44682 (SIL-MIRO COM SRL) which learns it from AS8751 (MEDIA SAT SRL) which "claims" to have learnt it from AS6830. This very much smells like a "fake route" generated by someone here likely from a route optimiser. From the Liberty Global looking glass, it's clear that AS6830 does not have it. So it has to be either AS8751 or AS44682 or AS35505 having this route in their table. It's hard to verify and be 100% sure who since those three ASNs don't have a looking glass or a RIPE Atlas probe for me to see their routing. Thus when BGP lies, the internet believes! Disclaimer: This is my personal blog, and hence, posts made here are in my personal capacity. These do not represent the views of my employer. ## Opentofu + Tailscale = Bootstrapped DevOps environment with VPN DevFeed: [Opentofu + Tailscale = Bootstrapped DevOps environment with VPN]() Original publisher: [Read original article]() Published: 2026-01-17T21:28:46Z Content type: tutorial Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [opentofu](), [tailscale](), [DevOps](), [Virtual Private Network](), [Deployment](), [Cloud](), [Server](), [Terraform]() Tags: [cloud](), [deployment](), [devops](), [hetzner](), [opentofu](), [tailscale](), [terraform](), [vpn]() ### AI overview The article demonstrates using OpenTofu with Tailscale to bootstrap a private network across development VMs. It presents configuration for deploying three IPv6-only servers and installing Tailscale with cloud-init, while noting that the approach is intended mainly for quick testing rather than permanent production servers. ### Source excerpt For the last few days, I have been playing with OpenTofu. For those who may not know, it's a fork of last Terraform as Terraform's license was changed due to IBM's acquisition of Hashicorp and is a Cloud Native Foundation project. It can be used to quickly deploy (and remove) resources from various cloud players. Yesterday came across this tweet from Tailscale about tailscale's module for deployment. Cloud-init can be tough, and we've heard all about it. So we built an open-source Terraform module, one that helps provide a more consistent Tailscale experience across AWS, Azure, GCP, and everywhere. No more surprises, OS quirks, or other mysteries: https://t.co/vn1ITU7Fgz pic.twitter.com/stcF6WuiD7 -- Tailscale (@Tailscale) January 15, 2026 It's cool and useful, though I find Cloud init way more useful since for me these tools are more useful for quick testing rather than a permanent production server. The idea of tailscale on devops VMs as they come up is pretty powerful, as it takes care of the private network between these machines, plus underlay doesn't matter, and hence one can use (cheaper) IPv6-only VMs. An example of OpenTofu config (which is similar to Terraform) to deploy three IPv6 only servers on players like Hetzner across Nuremberg, Helsinki, and Ashburn: main.tf terraform { required_providers { hcloud = { source = "hetznercloud/hcloud" version = "~> 1.59.0" } } } provider "hcloud" { token = var.hcloud_token } data "hcloud_ssh_key" "desktop" { name = "desktop" } data "hcloud_image" "ubuntu" { name = "debian-13" most_recent = true } resource "hcloud_server" "vms" { for_each = var.vms name = each.key image = data.hcloud_image.ubuntu.id server_type = each.value.server_type location = each.value.location ssh_keys = [data.hcloud_ssh_key.desktop.id] user_data = <<-EOF #cloud-config package_upgrade: true packages: - curl runcmd: - curl -fsSL https://tailscale.com/install.sh | sh - tailscale up --authkey=${var.tailscale_authkey} --accept-routes EOF public_net { ## NCMC design and technical limitations DevFeed: [NCMC design and technical limitations]() Original publisher: [Read original article]() Published: 2026-01-03T18:46:00Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [Internet](), [Transactions](), [Risk](), [systems]() Tags: [card](), [dmrc](), [internet](), [ncmc](), [npci](), [payment-systems](), [payments]() ### AI overview The article examines India's National Common Mobility Card (NCMC), focusing on its offline-wallet design and how it differs from online UPI and card payments used in other transit systems. ### Source excerpt I was in Mumbai a few months ago for the Equinix India Peering forum. The event happened to be very near the airport & I found that the airport, conference venue, hotel, and a few other locations I was visiting were all near the newly built Mumbai Line 3 (Aqua Line). To save on hassle with regular tickets, I went for an NCMC (National Common Mobility Card). Most people travelling in the Delhi metro would be aware of it by now, thanks to a bit of marketing push inside the metro train with announcements. Mumbai line 3 has a tie-up with SBI for the card, and thus, I got the SBI card. Ended up using it in Mumbai, Delhi and Chennai over the last few months. Lately, I have been reading about way NCMC works, the limitations of the Indian NCMC design compared to other mass transit systems. In many countries, mass transit systems simply use MasterCard/Visa/Apple Pay tap and charge directly from the respective card (credit/debit card, etc.), like the London tube, Stockholm metro, HK airport express, Singapore, etc. Indian deployment is bit different. Indian NCMC offline wallet concept The whole idea of NCMC is to have a single card which can make payment for public transport, including metro, buses etc across the country digitally. It has to be fast and reliable, and this is where the whole tech differs from systems like UPI or Visa/MasterCard/Rupay POS payments. In case of UPI as well as credit/debit card payments on POS machines - entire transaction runs online. Money goes from the person paying the amount to the receiver as part of a settlement facilitated by NPCI. I don't need to go in detailed steps involved there, but the key idea is that there's an active involvement of 1) Payer's APP 2) Payer's bank 3) Receiver's PSP 4) Receiver's bank 5) NPCI UPI switch, etc. All these have to work and most important - internet has to work. πŸ˜€ All this largely works well for casual payments across the vendors, but not for transit payments, especially at metro stations. It easily takes ## 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