Networking

IRINN & APNIC inetnum range confusion

Last week I saw an interesting post at APNIC mailing list about IRINN (recently formed NIR in Indian region). 

Poster Jimmy was concerned about IRINN’s netname

inetnum: 0.0.0.0 - 255.255.255.255  
netname: IRINN-BROADCAST-ADDRESSES  
descr: Broadcast addresses  
descr: These addresses cannot (should not) be routed on the Internet.  
country: IN  
admin-c: IH1-IN  
tech-c: IH1-IN  
status: ALLOCATED PORTABLE  
remarks: send spam and abuse report to info@irinn.in  
mnt-by: IRINN-HM  
mnt-irt: IRT-IRINNHM-IN  
mnt-lower: IRINN-HM  
changed: hostmaster2@irinn.in 20130420  
source: IRINN

As per first two lines entire IPv4 address space i.e 0.0.0.0/0 (ranging from 0.0.0.0 to 255.255.255.255) was put as IRINN-Broadcast while expected was IANA broadcast (since IANA sits on top in this RIR & NIR hierarchy).

Transit at IXP & next-hop-self

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.

Dark spot in Global IPv6 routing

Fest time at college - Good since I get lot of free time to spend around looking at routing tables. It’s always interesting since last week was full of some major submarine cable cuts and has huge impact on Indian networks.

Anyways, an interesting issue to post today about Global IPv6 routing . There are “dark spots” in global IPv6 routing because of peering dispute between multiple tier 1 ISPs involving Hurricane Electric (AS6939) & Cogent Communications (AS174).  What’s happening here is that both tier 1 providers failed to reach on agreement to keep peering up in case of IPv6. This has resulted in parts of global IPv6 internet where packets from one network (and it’s downstream) can’t reach other network or their downsteam singled hommed networks. 

SMW4 Cable outage

Today a friend from Pakistan informed about SMW4 outage. He reported about issues in Pakistan.

It seems like SMW4 is damaged near Egypt and that is what causing high load on East Asian routes giving pretty high latency.

I am at my home and sitting BSNL’s network and latency with Europe has jumped terribly to 700-800ms. Right now I do not see a direct route to Europe and it’s rather taking East Asia > US > Europe routes right now on other cable networks.

BSNL routing tables and upstreams

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:

  1. 117.192.0.0/18
  2. 117.192.0.0/20 

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:

BSNL routing messup at NIXI Delhi

Finally back in village location.

Was just looking around and saw BSNL having really crazy routing. I looked around and saw this:

NIXI Looking Glass - show ip bgp neighbors 218.100.48.15 routes

Router: NIXI Delhi (Noida)

Command: show ip bgp neighbors 218.100.48.15 routes

Total number of prefixes 0

Clearly BSNL is NOT announcing any prefix at NIXI Delhi at all. Thus if one has to send packets to BSNL in North area either it will be via transit (Tata/VSNL) or via any other peering NIXI exchange in Mumbai or Chennai.

Airtel hijacking NXDOMAIN queries

Back in India after amazing APRICOT 2013 at Singapore. It was nice to stay in East Asia for a while and look around. :)

Anyways, issue for today - I have been using Airtel DNS servers from quite sometime since BSNL has crappy DNS while Google gives issues with Akamai while OpenDNS doesn’t has any node in India yet.  

Today I noticed a NXDOMAIN redirection for a non-working domain and later investigated. It seems like Airtel is hijacking on NXDOMAIN queries now.

Google Public DNS and Akamai issues in India

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.

Analysis: Inconsistent latency between two end points

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.

Google's routing issues because of an Indonesian ISP

Yesterday it was reported across networking community that Google’s prefixes were having issue due to an Indonesian ISP Moratel AS23947.


Quick analysis

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: