# RIPE RIS Published articles for RIPE RIS. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## The Third App from J2sw: Prefix Advertisement Checker DevFeed: [The Third App from J2sw: Prefix Advertisement Checker]() Original publisher: [Read original article]() Author: j2sw Published: 2026-07-31T12:17:00Z Content type: tutorial Language: en Sources: [Justin Wilson (j2sw)]() Topics: [BGP](), [networking](), [App](), [Cisco](), [MikroTik]() Tags: [application](), [bgp](), [irr](), [j2-networks](), [j2-updates](), [network-engineering-resources](), [network-tools](), [network-troubleshooting](), [prefix-advertisement](), [ripe-ris](), [roa](), [routing](), [routing-policy](), [rpki](), [visibility]() ### AI overview This article describes the J2SW Prefix Advertisement Checker, an application that evaluates an exact IPv4 or IPv6 prefix using live BGP data. It reports observed origin ASNs from RIPE RIS collectors, collector visibility, RPKI/ROA status, and matching IRR route objects, with an optional expected origin ASN for comparison. ### Source excerpt A prefix can appear in the global BGP table and still have a routing problem. The route may originate from the wrong ASN. Its ROA may also authorize a shorter prefix but reject the advertised prefix length. Checking each part normally means pulling data from several routing tools. The J2SW Prefix Advertisement Checker, my 3rd ... Read more The post The Third App from J2sw: Prefix Advertisement Checker appeared first on Justin Wilson (j2sw). ## 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 ## 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.