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