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.

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.

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.