Interesting days as always. Recently I was handed over “Alumni form” from college.
Mixed feelings. This brings me to conclusion that I somewhat missed college life but anyways that’s small price I paid for my high obsession with some long term ideas. (ok may be that explains why I don’t have a Facebook account? Stop asking me about it!)
Hard to come to any conclusion at this stage.
Anyways post for today…
Last night I was looking at routing tables and saw a interesting case where for a specific route.
Here’s what I got from Tata’s AS6453 looking glass:
Router: gin-ldn-core4
Site: UK, London, LDN
Command: show ip bgp 117.219.227.229
BGP routing table entry for 117.219.224.0/20
Bestpath Modifiers: deterministic-med
Paths: (4 available, best #4)
Multipath: eBGP
17 18 19
33765 1299 3549 9829, (received-only)
ix-3-1-2.core4.LDN-London. from ix-3-1-2.core4.LDN-London. (ix-3-1-2.core4.LDN-London.)
Origin IGP, valid, external
4755 9829
mlv-tcore2. (metric 3605) from l78-tcore2. (66.110.10.234)
Origin IGP, valid, internal
Community:
Originator: 66.110.10.215
4755 9829
mlv-tcore2. (metric 3605) from l78-tcore1. (66.110.10.237)
Origin IGP, valid, internal
Community:
Originator: 66.110.10.215
4755 9829
mlv-tcore2. (metric 3605) from ldn-mcore3. (ldn-mcore3.)
Origin IGP, valid, internal, best
Community:
Originator: 66.110.10.215
The first route in table seems pretty weird. AS path is 33765 1299 3549 9829 i.e clearly AS33765 sitting in middle of AS6453 and AS1299. This must be a route leak since Tata AS6453 and Telia AS1299 are way too bigger then Tanzania telecom and hence there’s no possibility of Tata transitting via Tanzania telecom. Though issue seems for just one specific route for BSNL which Tanzania telecom is learning from Telia, which further is getting from Global Crossing AS3549 (one of upstreams of BSNL).
And college started after pretty good holi holidays. Again having bit painful time due to hot weather and this is just start of summers. Well all I can hope is that there won’t be voltage issues in village again (like last time). And just to make sure on that part - I have put 2 RTI’s asking Power department about their preparation details. :)
Anyways coming on blog post topic for the day - the effect of “next-hop-self” at an IXP when there are peers as well as transit customers of a network. Just to be clear in start - this post will stick to technical side of it and without going into IXP policy side of it.
Just was looking at routing tables of BSNL. They have a significant address space in /10 - 117.192.0.0/10. Overall this /10 address space is divided into /18 and /20 subnets.
Let’s pick two of such subnets and observe routing tables from route-views:
Routing table for 117.192.0.0/18:
* 117.192.0.0/18 193.0.0.56 0 3333 3356 6453 4755 9829 9829 9829 i
* 194.85.102.33 0 3277 3216 6453 4755 9829 9829 9829 i
* 194.85.40.15 0 3267 174 6453 4755 9829 9829 9829 i
* 129.250.0.11 6 0 2914 6453 6453 4755 9829 9829 9829 i
* 128.223.253.10 0 3582 3701 3356 6453 4755 9829 9829 9829 i
* 4.69.184.193 0 0 3356 6453 4755 9829 9829 9829 i
* 209.124.176.223 0 101 101 3356 6453 4755 9829 9829 9829 i
* 69.31.111.244 3 0 4436 2914 6453 6453 4755 9829 9829 9829 i
* 207.46.32.34 0 8075 6453 4755 9829 9829 9829 i
* 66.59.190.221 0 6539 6453 4755 9829 9829 9829 i
* 12.0.1.63 0 7018 6453 4755 9829 9829 9829 i
* 208.74.64.40 0 19214 2828 6453 4755 9829 9829 9829 i
* 203.181.248.168 0 7660 2516 6453 4755 9829 9829 9829 i
* 66.185.128.48 111 0 1668 6453 4755 9829 9829 9829 i
* 134.222.87.1 0 286 6453 4755 9829 9829 9829 i
* 157.130.10.233 0 701 6453 4755 9829 9829 9829 i
* 114.31.199.1 0 0 4826 6939 1299 6453 4755 9829 9829 9829 i
* 89.149.178.10 10 0 3257 6453 4755 9829 9829 9829 i
* 154.11.98.225 0 0 852 3561 6453 4755 9829 9829 9829 i
* 202.249.2.86 0 7500 2497 6453 4755 9829 9829 9829 i
* 154.11.11.113 0 0 852 3561 6453 4755 9829 9829 9829 i
* 144.228.241.130 0 1239 6453 4755 9829 9829 9829 i
* 217.75.96.60 0 0 16150 1299 6453 4755 9829 9829 9829 i
* 207.172.6.20 0 0 6079 3356 6453 4755 9829 9829 9829 i
* 206.24.210.102 0 3561 6453 4755 9829 9829 9829 i
* 195.66.232.239 0 5459 6453 4755 9829 9829 9829 i
* 208.51.134.254 2523 0 3549 6453 4755 9829 9829 9829 i
* 207.172.6.1 0 0 6079 3356 6453 4755 9829 9829 9829 i
* 216.218.252.164 0 6939 1299 6453 4755 9829 9829 9829 i
* 203.62.252.186 0 1221 4637 6453 4755 9829 9829 9829 i
*> 66.110.0.86 0 6453 4755 9829 9829 9829 i
* 164.128.32.11 0 3303 6453 4755 9829 9829 9829 i
* 202.232.0.2 0 2497 6453 4755 9829 9829 9829 i
Routing table for 117.192.0.0/20:
A quick blog post on a interesting issue coming up due to combined problem of CDN failure on Google Public DNS and bad Akamai performance due to Tata-NTT peering issue.
I was trying Zembra mail since there’s no more free Google Apps edition and one of my friend asked me to basic email on his domain up. It was more or less a straight task by installing Zembra with decent GUI.
An interesting evening here in village. From today sessional tests started at college and so does my blog posts too (to keep myself with positive energy!) ;)
Learned something new while troubleshooting. :)
I am used to getting latency of ~350ms with my server in Europe as I have mentioned in my past blog posts.
My connection > Server goes direct but return path goes via US and this is what increases latency. Today all of sudden I saw latency of 200ms with my server. 150ms less - that’s significant.
Yesterday it was reported across networking community that Google’s prefixes were having issue due to an Indonesian ISP Moratel AS23947.
From data logged by routeviews it seems like it wasn’t exactly a prefix hijack. AS23947 did not originated prefixes but rather had a route leak leading to path leak of AS23947 > AS15169.
Here’s a view of global routing table for Google’s prefix 216.239.32.0/24 at 15:57 GMT on 4th Nov:
These days Open DNS resolvers are getting quite popular. With Open DNS resolver I mean resolvers including OpenDNS as well as Google Public DNS.
One of major issues these resolvers suffer is failure of integration with CDN providers like Akamai, Limelight etc. In this post I will analyse sample client site of Akamai - Malaysia Airlines website - http://www.malaysiaairlines.com.
Looking at OpenDNS, Google Public DNS and my ISP (BSNL’s) DNS resolver for its DNS records:
Super dull time here. No classes going on due to “TCS Placement session” at college and this makes me to sit in my room most of time of my day.
Yesterday I tested connectivity to all 13 Global Root DNS Servers and found i root was giving issue.
Here’s a my yesterday’s traceroute to i root:
traceroute to i.root-servers.net. (192.36.148.17), 30 hops max, 60 byte packets
1 router.local (10.0.0.1) 1.470 ms 1.965 ms 2.452 ms
2 117.200.48.1 (117.200.48.1) 26.030 ms 28.857 ms 31.243 ms
3 218.248.173.46 (218.248.173.46) 34.673 ms 37.091 ms 41.025 ms
4 218.248.246.130 (218.248.246.130) 72.853 ms 75.272 ms 77.959 ms
5 * * *
6 * * *
Since i root is another root server hosted within India by NIXI, I was quite sure this was issue again due to NIXI’s regional route enforcement policy along with missing transit link on i root. You can see my last blog post about same issue with F root here.
I can see BSNL having pretty high latency again with most of Europe again. It seems like they are using Level3 Communications AS 3356 along with Tata-VSNL for upstream. With Level3 transit BSNL has badly screwed up reverse path causing very high latency and awful bandwidth.
anurag@laptop:~$ ping server7 -c 5
PING server7.anuragbhatia.com (178.238.225.247) 56(84) bytes of data.
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=1 ttl=52 time=320 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=2 ttl=52 time=320 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=3 ttl=52 time=319 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=4 ttl=52 time=327 ms
64 bytes from server7.anuragbhatia.com (178.238.225.247): icmp_req=5 ttl=52 time=320 ms
--- server7.anuragbhatia.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 319.880/**321.765**/327.384/2.828 ms
anurag@laptop:~$
Expected latency values here should be around 150ms. A packet should not take more then 150ms round trip between Radaur, Haryana to Munich located server.