Route-Leak

This week I presented in bdNOG 4 on “Misused top ASNs”. It was a study we at Hurricane Electric did to see how many times AS1, AS2 and AS3 appeared in global routing table between 2010 and 2015. This highlights cases where AS1, AS2 or AS3 appeared as a result of wrong prepend.  

My presentation is embedded below:

Overall bdNOG 4 had been a great experience. It’s good to see a nice NOG community actively sharing technical know-how, sharing experiences, and much more. I must say that is something I greatly miss in India. More on bdNOG conference later on.

There seems be an ongoing route leak by AS49505 (Selectel, Russia) for K root server.

K root server’s IP: 193.0.14.129
Origin Network: AS25152  

Here’s trace from Airtel Looking Glass, Delhi PoP

Mon Oct 26 16:21:18 GMT+05:30 2015
traceroute 193.0.14.129
Mon Oct 26 16:21:22.053 IST
Type escape sequence to abort.
Tracing the route to 193.0.14.129
 1   \*
    203.101.95.146 19 msec  4 msec
 2  182.79.224.73 14 msec  3 msec  1 msec
 3  14.141.116.89.static-Delhi.vsnl.net.in (14.141.116.89) 7 msec  3 msec  2 msec
 4  172.23.183.134 26 msec  45 msec  26 msec
 5  ix-0-100.tcore1.MLV-Mumbai.as6453.net (180.87.38.5) 151 msec  153 msec  152 msec
 6  if-9-5.tcore1.WYN-Marseille.as6453.net (80.231.217.17) \[MPLS: Label 383489 Exp 0\] 160 msec  163 msec  155 msec
 7  if-2-2.tcore2.WYN-Marseille.as6453.net (80.231.217.2) \[MPLS: Label 595426 Exp 0\] 161 msec  162 msec  162 msec
 8  if-7-2.tcore2.FNM-Frankfurt.as6453.net (80.231.200.78) \[MPLS: Label 399436 Exp 0\] 149 msec  151 msec  155 msec
 9  if-12-2.tcore1.FNM-Frankfurt.as6453.net (195.219.87.2) 164 msec  163 msec  159 msec
 10 195.219.156.146 153 msec  151 msec  160 msec
 11 spb03.transtelecom.net (188.43.1.226) 190 msec  192 msec  189 msec
 12 Selectel-gw.transtelecom.net (188.43.1.225) 185 msec  185 msec  185 msec
 13 k.root-servers.net (193.0.14.129) 183 msec  204 msec  196 msec
RP/0/8/CPU0:DEL-ISP-MPL-ACC-RTR-9#

The routing information (show route 193.0.14.129 output) from their looking glass doesn’t seems useful since it shows that it’s learning K root Noida route via NIXI. This is likely because routing information is different from actual forwarding information in that device. So the trace looks extremely weird. It’s leading traffic to K root which does has anycast instance in Noida, landing into Russia!   Why is that happening? Let’s look at what Tata Communications (AS6453) routing table has for K root’s prefix. I am looking at feed of AS6453 which it’s putting into RIPE RIS RRC 03 collector.

K root in Noida seems to be not getting enough traffic from quite sometime and connectivity does seems bit broken. This is a blog post following up to Dyn’s excellent and detailed post about how TIC leaked the world famous 193.0.14.0/24 address space used by AS25152. It was good to read this post from RIPE NCC written by my friend Emile (and thanks to him for crediting me to signal about traffic hitting outside!)  

Yesterday I was driving and radio was pretty boring. Next, I connected cell phone to car’s stereo (I use a PT-750 to wirelessly connected my devices to car’s audio system). Next I tuned into Gaana.com app and experience was overall good. The way whole setup was working itself is a wonder - wireless profiles keeping layer 3 link (IP address of device) consistent and handovers happening on layer 1. On top of that a while world of backbone routing across AS9498 backbone the hosting provider’s network of the app. Now an interesting thing in this setup was the IP allocations. I that IP allocated by Airtel was 100.92.215.253.

And my post on 1st April. Don’t take it as April fool post ;)

Multiple times NIXI’s AS24029 has been reported as acting like transit ASN for multiple networks. I have analysed it in past and this is very much because of route leaks by few specific networks. I have explained difference in peering Vs transit routes and their handling previously on my blog.

In short: A network is supposed to re-announce it’s peering and transit routes only to customer and not to any other peer or upstream. Whenever NIXI’s ASN appears in global routing table, its always the case where one or more networks are re-announcing routes learnt via NIXI to their upstream transits.