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: 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.

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

 
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:
K_root_Performance
 
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 172.16.18.0/24 -o tun0 -j SNAT –to-source 10.200.105.10

 
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 172.16.18.5
 redistribute kernel
 neighbor 172.16.18.1 remote-as 58901
 neighbor 172.16.18.1 next-hop-self
!
ip forwarding
!
line vty
!
end
raspberrypi#

 
Have fun!