NTT

Analysis of impact of de-peering between NTT AS2914 and Cogent AS174

A few weeks back I got in touch with Marc from Meghalaya. He offered to host RIPE Atlas probe at Shillong and that’s an excellent location which isn’t there on RIPE Atlas coverage network yet. It took around 5 days for the probe to reach Shillong from Haryana. I think probably this probe is the one at the most beautiful place in India. :) Now that probe is connected, I thought to look into routing which is super exciting for far from places like Shillong. Marc has a BSNL FTTH connection & mentioned about not-so-good latency. Let’s trace to 1st IP of the corresponding /24 pool on which probe is hosted:

I recently came across an excellent draft at IETF by Job Snijders & friends. This is to address scenarios where a network might miss communication about a maintenance activity when BGP shutdown happens. Once implemented, this can potentially offer to send peer a message with up to 128 bytes with info about shutdown like “Ticket XXX: We are upgrading the router, will be back live in 1hr” etc.

It depends by appending such data to the sys notification which is part of BGP protocol. This is one which sends a message just before the shutdown of the session. So it similar to the way you see session tearing down due to prefix limits etc. This has already been implemented in some of the open source routing implementations like OpenBGPd, GoBGP, PMacct, Exabgp etc.   Here is the latest draft of this change.

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.

Interestingly routing issues didn’t spare one of top CDN provider - Akamai!

So what’s wrong?

(from my BSNL connection):

PING akamai.com (61.213.189.49) 56(84) bytes of data.  
64 bytes from 61.213.189.49: icmp_req=1 ttl=52 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=2 ttl=52 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=3 ttl=52 time=474 ms  
64 bytes from 61.213.189.49: icmp_req=4 ttl=51 time=492 ms  
64 bytes from 61.213.189.49: icmp_req=5 ttl=51 time=489 ms

\--- akamai.com ping statistics --- 
5 packets transmitted, 5 received, 0% packet loss, time 22236ms  
rtt min/avg/max/mdev = 474.296/488.469/492.837/7.183 ms

~ 500ms is way too high. Even US is at like 300ms latency.

Looking at traceroute: 

traceroute to akamai.com (61.213.189.49), 30 hops max, 60 byte packets  
1 router.local (192.168.1.1) [AS8151/AS28513] 4.223 ms 4.979 ms 5.879 ms  
2 117.200.48.1 (117.200.48.1) [AS9829] 45.241 ms 46.384 ms 52.839 ms  
3 218.248.173.46 (218.248.173.46) [AS9829] 87.089 ms \* \*  
4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755] 74.675 ms 76.970 ms 80.856 ms  
5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [\*] 83.234 ms 84.403 ms 87.742 ms  
6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 230.777 ms 185.553 ms 194.288 ms  
7 \* Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453] 203.104 ms \*  
8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453] 308.973 ms 310.324 ms 311.038 ms  
9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 311.799 ms 333.841 ms 313.348 ms  
10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 499.075 ms 501.158 ms 512.657 ms  
11 ae-5.r24.tokyjp01.jp.bb.gin.ntt.net (129.250.3.221) [AS2914] 484.258 ms 485.401 ms 499.039 ms  
12 \* \* \*  
13 xe-2-3.a17.tokyjp01.jp.ra.gin.ntt.net (61.213.169.214) [AS2914] 488.807 ms 489.543 ms 495.396 ms  
14 61.213.189.49 (61.213.189.49) [AS2914] 506.170 ms 501.504 ms 507.296 ms

So route is like Mumbai (India) - London (UK) - Tokyo (Japan).