Airtel-Tata Comm routing is cold potato in India?
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 be5214.ccr31.oma02.atlas.cogentco.com (154.54.165.133) 126 msec
be2717.ccr41.ord01.atlas.cogentco.com (154.54.6.221) 103 msec 103 msec
10 be5214.ccr31.oma02.atlas.cogentco.com (154.54.165.133) 115 msec 115 msec
be5068.ccr32.oma02.atlas.cogentco.com (154.54.166.73) 116 msec
11 be6904.ccr81.den01.atlas.cogentco.com (154.54.95.97) 124 msec
be8568.ccr82.den01.atlas.cogentco.com (154.54.95.109) 126 msec
be2353.ccr81.slc03.atlas.cogentco.com (154.54.5.102) 132 msec
12 be3906.ccr22.sfo01.atlas.cogentco.com (154.54.5.154) 152 msec
be9563.ccr82.slc03.atlas.cogentco.com (154.54.163.206) 135 msec
be2353.ccr81.slc03.atlas.cogentco.com (154.54.5.102) 159 msec
13 be3906.ccr22.sfo01.atlas.cogentco.com (154.54.5.154) 150 msec
be2902.agr21.sfo01.atlas.cogentco.com (154.54.3.50) 149 msec
be3905.ccr21.sfo01.atlas.cogentco.com (154.54.1.210) 150 msec
14 be2903.agr21.sfo01.atlas.cogentco.com (154.54.6.202) 151 msec
be2902.agr21.sfo01.atlas.cogentco.com (154.54.3.50) 153 msec
be2903.agr21.sfo01.atlas.cogentco.com (154.54.6.202) 151 msec
15 ism01.sfo01.atlas.cogentco.com (66.250.250.146) !A !A !A
The trace shows the first hop timed out, and the second hop indicates a handover to Cogent, which subsequently routes the traffic to the US. This suggests that Cogent is responsible for carrying traffic between Germany and the US when the destination is also on the Cogent network.
Let’s check the reverse:
Cogent San Francisco -> Arelion Frankfurt - 62.115.129.161 (ffm-b11.ip.twelve99.net):
traceroute to ffm-b11.ip.twelve99.net. (62.115.129.161), 30 hops max, 60 byte packets
1 gi100-0-0-40.agr21.sfo01.atlas.cogentco.com (66.250.250.145) 0.673 ms 0.641 ms
2 be2903.ccr22.sfo01.atlas.cogentco.com (154.54.6.201) 0.917 ms 1.010 ms
3 be2379.ccr31.sjc04.atlas.cogentco.com (154.54.42.158) 1.431 ms be2430.ccr31.sjc04.atlas.cogentco.com (154.54.88.186) 1.518 ms
4 palo-b24-link.ip.twelve99.net (62.115.174.64) 1.185 ms 1.190 ms
5 palo-bb4-link.ip.twelve99.net (62.115.139.110) 4.864 ms 4.172 ms
6 den-bb2-link.ip.twelve99.net (62.115.139.113) 354.428 ms 26.677 ms
7 kanc-bb2-link.ip.twelve99.net (62.115.137.115) 39.102 ms chi-bb1-link.ip.twelve99.net (62.115.115.77) 48.806 ms
8 chi-bb2-link.ip.twelve99.net (62.115.136.102) 46.750 ms 46.933 ms
9 ldn-bb1-link.ip.twelve99.net (62.115.139.245) 136.341 ms ewr-bb2-link.ip.twelve99.net (62.115.132.134) 63.423 ms
10 ldn-bb2-link.ip.twelve99.net (62.115.139.247) 134.406 ms 134.345 ms
11 prs-bb2-link.ip.twelve99.net (62.115.133.239) 135.638 ms 135.602 ms
12 * ffm-b11-link.ip.twelve99.net (62.115.124.117) 148.809 ms
As is visible, traffic is handed over to Arelion on the 4th hop to Arelion within the Bay area (San Jose) and then Arelion carries it to Europe. It’s a standard practice and almost all major backbones have it as long as they are peering on multiple continents.
Airtel - Tata Comm routing in India
Coming to the Airtel - Tata Comm routing case, I don’t have access to full tables with BGP tables with BGP communities, but can certainly trace & do some tricks with trace to establish whether it’s hot potato or cold potato routing.
Trace from Airtel Haryana -> Tata Comm Chennai speedtest node:
mtr ookla.cn.as6453.net -wby0 -4
Start: 2026-05-20T18:51:59+0530
HOST: rtk01.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1. AS??? 172.16.16.1 0.0% 10 0.3 0.3 0.3 0.4 0.0
2. AS??? 10.240.9.204 0.0% 10 6.2 6.3 4.2 12.8 2.5
3. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4. AS9498 169.168.18.125.dhcp.anaronline.net (125.18.168.169) 0.0% 10 5.0 8.8 4.9 22.0 5.9
5. AS??? 116.119.164.99 0.0% 10 28.5 30.1 28.5 31.9 1.1
6. AS4755 115.110.234.141.static.Mumbai.vsnl.net.in (115.110.234.141) 0.0% 10 31.9 33.5 31.9 35.8 1.3
7. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. AS4755 115.110.96.156.static-Ahmedabad.vsnl.net.in (115.110.96.156) 0.0% 10 50.4 50.9 49.2 52.1 0.9
Ignore AS6453 in hostname (it’s AS4755), ignore Ahmedabad in reverse DNS as it’s Chennai and also ignore “anaronline.net” in hope 4 - it’s just an Airtel router with this outdated PTR in Saha, Ambala, Haryana. 😀 With those three things out of the way, the trace shows Hop 5 with 28ms latency, indicating a Mumbai-based hop, followed by Hop 6, which is the Tata Comm IP.
So there are two possibilities here:
-
Hop 5 is Tata Comm AS4755 router sitting on Airtet’s IPv4. The chance of it is very low because a) Hop 4 is a known non-peering location (Ambala) for Airtel. It would be very unusual for them to have a circuit from Ambala to Mumbai with Airtel side in Ambala peering with the Tata Comm side in Mumbai. b) Usually networks interconnect over a /30 or /31. If it were a /30 CIDR block, 116.119.164.99 would fall within 116.119.164.96/30, requiring the use of .97 and .98, which is not the case. If it were a /31, it would be 116.119.164.98/31, with one side at .98 (Ambala) and the other at .99 (Mumbai). 116.119.164.99 is in Mumbai for sure as I have servers in Mumbai directly connected to Airtel and it’s 1.7ms away but then .98 from my home in Haryana should be 5ms, but it’s 85ms.
-
Hop 5 is Airtel, hop 6 is Tata Comm and interconnection (PNI) is between hop 5 and hop 6. In this case likely 115.110.234.140/30 is used with .141 on the Tata Comm side and .142 on the Airtel side. It cannot be /31 as in that case it would be .141 and .140 and .140 is not reachable. From my server in Mumbai connected to Tata Comm, I see 4 hops to .141 and 5 hops to .142. So it’s safe to establish that this is indeed the case.
So for traffic from Airtel Haryana to Tata Comm Chennai, traffic handover happened far off in Mumbai with Airtel carrying traffic till Mumbai. Let’s see how it is in reverse: OVH Mumbai (behind Tata Comm) to speedtestsaha1.airtel.in (Airtel Ambala Speedtest):
> Mumbai, IN, AS, OVH (AS16276)
Host Loss% Drop Rcv Avg StDev Javg
1. AS16276 _gateway (148.113.1.252) 0.0% 0 3 0.5 0.0 0.3
2. AS??? 10.164.249.124 (10.164.249.124) 0.0% 0 3 0.3 0.1 0.1
3. AS??? 10.133.49.24 (10.133.49.24) 0.0% 0 3 0.4 0.1 0.3
4. AS??? 10.75.24.26 (10.75.24.26) 0.0% 0 3 0.2 0.0 0.1
5. AS??? 10.75.248.194 (10.75.248.194) 0.0% 0 3 2.3 0.5 1.9
6. AS??? 10.75.248.200 (10.75.248.200) 0.0% 0 3 2.4 0.6 2.0
7. AS16276 bom-ynm1-sbb1-8k.ind.asia (103.5.12.8) 0.0% 0 3 2.2 0.6 1.7
8. AS??? 10.200.4.7 (10.200.4.7) 0.0% 0 3 0.3 0.0 0.2
9. AS??? (waiting for reply)
10. AS??? (waiting for reply)
11. AS4755 115.110.210.66.static-Delhi.vsnl.net.in (115.110.210.66) 0.0% 0 3 52.6 0.1 26.4
12. AS9498 116.119.50.26 (116.119.50.26) 0.0% 0 3 57.2 0.1 28.7
13. AS9498 nsg-corporate-130.219.185.122.airtel.in (122.185.219.130) 0.0% 0 3 57.0 0.1 28.6
Hops 8, 9 & 10 keep timing out no matter how many times I try. Hop 11 - that’s a Tata Comm IP as visible from reverse DNS and ASN mapping. This could actually be Tata Comm IP on Tata Comm router OR Tata Comm IP on Airtel router (part of /30 peering). 115.110.210.66 is from 115.110.210.64/30 with .65 and .66 as usable IPs.
Let’s trace from my home:
HOST: rtk01.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1. AS??? 172.16.16.1 0.0% 10 0.3 0.3 0.2 0.4 0.1
2. AS??? 10.240.9.204 0.0% 10 27.8 17.6 4.2 64.0 18.9
3. AS??? 172.31.0.195 0.0% 10 1171. 1352. 1068. 1656. 231.4
4. AS9498 173.168.18.125.dhcp.anaronline.net (125.18.168.173) 0.0% 10 12.6 8.1 4.9 13.1 2.8
5. AS4755 115.110.210.66.static-Delhi.vsnl.net.in (115.110.210.66) 0.0% 10 11.2 11.7 9.5 13.8 1.5
This strongly hints that 115.110.210.66 is a Tata Comm IP on an Airtel router because hop 4 (Ambala) is not known to be connecting to outside networks. So, it is highly likely that 115.110.210.66 is IPv4 on an Airtel router in Delhi NCR. Let’s check for .65 to see if it adds exactly one hop extra:
HOST: rtk01.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1. AS??? 172.16.16.1 0.0% 10 0.3 0.4 0.2 0.7 0.1
2. AS??? 10.240.9.204 0.0% 10 5.0 7.6 4.5 22.5 5.4
3. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4. AS9498 169.168.18.125.dhcp.anaronline.net (125.18.168.169) 0.0% 10 4.4 6.4 4.4 8.6 1.4
5. AS??? 116.119.161.28 0.0% 10 15.8 19.0 10.6 32.7 6.4
6. AS4755 115.110.210.65.static-Delhi.vsnl.net.in (115.110.210.65) 0.0% 10 13.1 12.4 10.5 14.4 1.3
With this it’s safe to say that in OVH trace, hop 11 is an Airtel router on Tata Comm IP & both .65 (Tata Comm) - .66 (Airtel) are in Delhi NCR. This means routing was as follows: OVH Mumbai > Tata Comm Mumbai > Tata Comm Delhi (one of those hops timing out) > Airtel Delhi > Airtel Ambala. So again, handover happened near destination & not the source - cold potato routing.
One more trace: Tata Comm AS4755 Bangalore -> speedtestggn1.airtel.in (Airtel speeddtest, Gurgaon) from active RIPE Atlas probe (#50525):
RESOLVED speedtestggn1.airtel.in TO 223.224.79.2
STARTED QUERY AT 2026/05/20 14:44:28 UTC
Fetching Measurement: 172850592
Traceroute from 193.32.247.8 to 223.224.79.2 (223.224.79.2):
1 121.242.164.33.static-Bangalore.vsnl.net.in (121.242.164.33) 1.239ms 0.764ms 0.716ms
2 219.65.110.33.static-bangalore.vsnl.net.in (219.65.110.33) 1.837ms 2.054ms 1.606ms
3 172.31.155.74 44.018ms 33.515ms 33.377ms
4 115.110.232.174.static.Delhi.vsnl.net.in (115.110.232.174) 39.724ms 39.559ms 39.534ms
5 116.119.109.16 35.586ms 35.628ms 35.488ms
6 dsl-tn-dynamic-138.223.22.125.airtelbroadband.in (125.22.223.138) 37.125ms 37.273ms 37.094ms
7 223.224.79.2 37.375ms 37.318ms 37.437ms
Again, hop 4 - 115.110.232.174 is Tata Comm’s IP on the Airtel router and thus interconnection happens before that. Hop 3 has to be Tata Comm and since latency is already 33ms, it confirms Tata Comm carried traffic till Delhi NCR and handover happened far from the origin.
Another test: RIPE Atlas probe (#1009203) on Excitel Delhi (behind Tata Comm) > Airtel Mumbai speedtest:
Fetching Measurement: 172853300
Traceroute from 172.21.0.2 to 182.78.248.10 (182.78.248.10):
1 172.21.0.1 0.101ms 0.073ms 0.111ms
2 192.168.1.1 1.222ms 0.678ms 1.024ms
3 103.212.157.10 1.496ms 1.94ms 2.639ms
4 103.212.157.1 4.718ms 4.759ms 9.593ms
5 14.140.113.29.static-Delhi-vsnl.net.in (14.140.113.29) 3.302ms 3.987ms 3.292ms
6 172.23.78.234 25.475ms 25.656ms 25.618ms
7 115.110.234.142.static.Mumbai.vsnl.net.in (115.110.234.142) 29.061ms 53.108ms 29.121ms
8 116.119.121.198 26.656ms 26.289ms 26.564ms
9 speedtestmum1.airtel.in (182.78.248.10) 29.857ms 28.881ms 28.397ms
Excitel hands over to Tata Comm within Delhi (3ms latency). Hop 6 is Mumbai-based on latency (likely Tata Comm’s private IP) and hop 7 is Tata’s IP on Airtel. Again, hop 7 - 115.110.234.142 is part of 115.110.234.140/30 with .141 and .142. Likely .142 is Airtel and .141 is Tata Comm. Let’s verify with trace to see if there’s an exact 1 hop difference:
HOST: bom01.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1. AS31898 140.91.204.7 0.0% 10 0.3 0.3 0.2 0.3 0.0
2. AS4755 121.241.5.170.mumbai-static.vsnl.net.in (121.241.5.170) 0.0% 10 1.0 1.1 0.9 1.6 0.2
3. AS4755 121.241.5.169.mumbai-static.vsnl.net.in (121.241.5.169) 0.0% 10 1.4 1.3 1.1 1.5 0.1
4. AS4755 115.110.234.141.static.Mumbai.vsnl.net.in (115.110.234.141) 0.0% 10 1.9 2.3 1.6 7.1 1.7
HOST: bom01.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1. AS31898 140.91.204.33 0.0% 10 0.2 0.3 0.2 0.4 0.1
2. AS4755 121.241.5.170.mumbai-static.vsnl.net.in (121.241.5.170) 0.0% 10 1.0 1.0 0.8 1.2 0.1
3. AS4755 121.241.5.169.mumbai-static.vsnl.net.in (121.241.5.169) 0.0% 10 1.3 1.4 1.2 1.6 0.1
4. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. AS4755 115.110.234.142.static.Mumbai.vsnl.net.in (115.110.234.142) 0.0% 10 2.3 3.9 2.0 18.5 5.1
This confirms hop 7 in the Excitel trace is Tata Comm’s IP on the Airtel router and hence handover happened between 6 & 7 with 6 in Mumbai itself. So again, Tata Comm carried over traffic over long distance Delhi -> Mumbai when the destination was Airtel.
I think it’s safe to conclude with all these traces that Airtel & Tata Comm follow cold potato routing in India. Each carries traffic over its own backbone over long distances and hands it over only close to the destination.
Why it’s cold potato routing?
Hard to know for sure but I guess the same set of people would have handled Airtel - Tata Comm PNI who also handled NIXI peering. Operators were used to regional route announcement (only) at NIXI and hence the same continued in private peering as well. Likely Airtel is announcing North Indian routes to Tata Comm in Delhi PNI (only), Western routes in Mumbai PNI etc with some overlap between Mumbai & Chennai for Bangalore/Kolkata routes to balance off PNIs. Same with the Tata Comm side as well. Changing it at later stage would need coordination for re-balancing traffic over PNIs which would add to the friction.
This can always lead to some missed routes, resulting in them not being announced at any peering & thus would take a scenic route via transit-free settlement backbones like AS6453 (technical upstream of AS4755, partially of AS9498 as well) and for AS9498 - AS1299/174/AS2914 etc.
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.