26 Oct

K root route leak by AS49505 – Selectel, Russia

There seems be an ongoing route leak by AS49505 (Selectel, Russia) for K root server.
K root server’s IP:
Origin Network: AS25152
Here’s trace from Airtel Looking Glass, Delhi PoP

Mon Oct 26 16:21:18 GMT+05:30 2015
Mon Oct 26 16:21:22.053 IST
Type escape sequence to abort.
Tracing the route to
 1   * 19 msec  4 msec
 2 14 msec  3 msec  1 msec
 3 ( 7 msec  3 msec  2 msec
 4 26 msec  45 msec  26 msec
 5  ix-0-100.tcore1.MLV-Mumbai.as6453.net ( 151 msec  153 msec  152 msec
 6  if-9-5.tcore1.WYN-Marseille.as6453.net ( [MPLS: Label 383489 Exp 0] 160 msec  163 msec  155 msec
 7  if-2-2.tcore2.WYN-Marseille.as6453.net ( [MPLS: Label 595426 Exp 0] 161 msec  162 msec  162 msec
 8  if-7-2.tcore2.FNM-Frankfurt.as6453.net ( [MPLS: Label 399436 Exp 0] 149 msec  151 msec  155 msec
 9  if-12-2.tcore1.FNM-Frankfurt.as6453.net ( 164 msec  163 msec  159 msec
 10 153 msec  151 msec  160 msec
 11 spb03.transtelecom.net ( 190 msec  192 msec  189 msec
 12 Selectel-gw.transtelecom.net ( 185 msec  185 msec  185 msec
 13 k.root-servers.net ( 183 msec  204 msec  196 msec

The routing information (show route 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.

anurag@server7:~/temp$ awk -F ‘|’ ‘$5==6453’ rrc03-table-26-Oct-2015.txt|grep
TABLE_DUMP_V2|10/26/15 08:00:03|A||6453||6453 20485 49505 25152|IGP

Let’s analyse this AS_PATH

  1. AS25152 is orignating prefix to AS49505 (Selectel Russia)
  2. AS49505 is “leaking” route to it’s upstream AS20485 (Trans Telecom, Russia)
  3. AS20485 is further propagating route to Tata Communications AS6453 making route visible globally via Tata Communications IP backbone

What impact of it?
Impact is much higher latency with K root from India. Here’s how RIPE Probe 170111 hosted at my home finds latency to K root:
As per graph change, leak started on 24th Oct at 9am UTC and this resulted in jump of latency of over 180ms.
Disclaimer: Post, comments, thoughts and analysis is in personal capacity and in no way linked to my employer.

23 Oct

Night fun task: OpenVPN, Quagga, Rasberry Pi and more!

I have been using OpenVPN from quite sometime and very much like it. Earlier I was running OpenVPN client on TP Link 1043nd router and that worked great. But recently I switched home routing to Microtik Map2N which has much better VLAN & IPv6 support. Since then I had trouble in getting VPN back live. I can always use VPN client on laptop but that’s ugly for daily use specially when this is my primary work location!
It’s hard to put in this blog but there are number of issues and limitations which come up if I try to use Microtik itself as OpenVPN client. Eventually gave up on that. Now, comes Raspberry Pi which is just a tiny Debian box running quite nicely. I configured OpenVPN on it and connected it as client to my server. It works fine. Next, pointed a static route for a sample test IP from core router to Rasberry Pi, and it did not work. I realized IPv4 forwarding isn’t enabled on it by default. 🙂
Once IPv4 forwarding is enabled, still connectivity doesn’t works because of usual private addressing issues. Both home LAN and VPN tunnel works over private IPs and hence packets do hit my server but it cannot return since it’s unsure on return path. This brings me to do usual source NAT on home LAN pool going towards VPN server via tunneled interface. And vola! it works.

iptables -t nat POSTROUTING -s -o tun0 -j SNAT –to-source

Now, a big issue which comes here is that for private addresses which I use for random applications/testing etc it works fine but there are certain public IPs as well which I route via OpenVPN. In this setup, I have to put static route at router end to push towards Raspberry Pi for each case and worst – if VPN tunnel breaks, connectivity will go down completely for those pools.
Thus I decided to rather use “dynamic routing” here. My lovely Quagga comes to rescue. Next, I configured a iBGP session between Quagga and core router and passed “redistribute kernel” in BGP config to redistribute all routes Raspberry Pi learn while connecting to VPN (in form of pushed routed in openvpn config on the server). And it works! 🙂
In this way as long as VPN is up, it’s prefered for public pools and when VPN is down, they take their usual path without having to manually disable any static routes.
So here comes a “State of Art” site to site VPN using OpenVPN, Quagga and Raspberry Pi. Time taken to setup: ~5 mins (Less then time taken to write this post 😛 😉 )
Quagga Config:

raspberrypi# sh run
Building configuration...
Current configuration:
log syslog
service integrated-vtysh-config
interface eth0
 ipv6 nd suppress-ra
interface lo
interface tun0
 ipv6 nd suppress-ra
router bgp 58901
 bgp router-id
 redistribute kernel
 neighbor remote-as 58901
 neighbor next-hop-self
ip forwarding
line vty

Have fun!