Isp-Column

On weekend  I was looking at BGP Instability Report data. As usual (and unfortunately) BSNL tops that list. BSNL is the most unstable autonomous network in the world. In past, I have written previously about how AS9829 is the rotten IP backbone.

This isn’t a surprise since they keep on coming on top but I think it’s well worth a check on what exactly is causing that. So I looked into BGP tables updates published on Oregon route-views from 21st May to 27th May and pulled data specifically for AS9829. I see zero withdrawals which are very interesting. I thought there would be a lot of announcements & withdrawals as they switch transits to balance traffic. If I plot the data, I get following chart of withdrawals against timestamp. This consists of summarised view of every 15mins and taken from 653 routing update dumps. It seems not feasible to graph data for 653 dumps, so I picked top 300.

Update - 12 July 2022

While migrating this old post from Wordpress to Hugo I realise that many of old external linked images are not available at source anymore and that breaks many of the external photos references on the blog.

In my previous post, I shared how I am running redundant uplinks at home (in non-BGP based setup) with the primary link on RF and secondary on DOCSIS. One of my good friends asked me the reason for the sudden jump in DOCSIS-based players across India, especially in smaller cities.

A few days some folks in internet community noticed Cloudflare AS13335 announcing F root server’s routes covering prefix 192.5.5.0/24.  

dig version.bind ch txt @f.root-servers.net pic.twitter.com/YLW7hqt170

— Tony Finch (@fanf) April 3, 2017

 

Above tweet shows that case is clearly not a mistake but rather some sort of arrangement between Cloudflare and ISC (which is responsible for F-root). There was another discussion on DNS-OARC mailing list here. From our bgp.he.net tool, one can analyse route propagation for F root’s AS3557.

A while back I posted about routing filter generation via bgpq3 for Cisco (ios and XR) and Juniper JunOS based routers. I have received a number of emails in last few months about automated filter generation for Mikrotik routeros. Since Mikrotik’s CCRs are getting quite popular across small to mid-sized ISPs. So this blog post is about ways for generating filter config for a given ASN via IRR. One can use such logic with some kind of remote login mechanism like rancid (look for mtlogin here). I tried building around bgpq3 but it seems more easy with another popular tool in the domain called IRR Power Tools. Once IRR Power Tools (IRRPT) is setup, it allows us to fetch prefixes based via Internet Routing Registries and also aggregates them.   So, for instance, let’s pick AS54456:

India has a slum problem as many of us know. Slums are a serious problem and there’s just no easy way to fix them. One cannot just push thousands and thousands of people out while at the same time quality of life in slums is terrible. One thing which happens a lot in India is the fact that Govt. does nothing when slums are getting established and once they are established situation gets out of control.    

Earlier this month I got an opportunity to be part of IXP workshop in Kolkata. It was a 3-day event organised by ISOC Kolkata and supported by APNIC. There was also a workshop on DNSSEC and Champika Wijayatunga (from ICANN) was the instructor along with Anand Raje. It was a nice event and I come to know of other interesting projects ISOC Kolkata is doing like Indian IETF capacity building program apart from the IXP they are running in Kolkata. Mr Anupam Aggarwal and Anand showed the IX and it looks very good. I think it’s the first and only IX I know in India which is a real IX with proper policy. It’s an IX by a non-for-profit group, allows anyone to connect, a real layer 2 IX and welcomes anyone including ISPs, content players and root DNS servers. Presently IIFON-IX in Kolkata has few member ISPs besides the L root from ICANN and one of Verisign gTLD nodes (which host zones for .com, .net etc). I also saw a rack with some of Akamai CDN servers. This brings decent content right there. IX’es play an extremely important part of current internet infrastructure ecosystem. It’s very likely that content of this blog is travelling from my server to your browser from an Internet Exchange. :)  

Today BGPmon reported about possible BGP prefix hijack of Amazon’s IP address space. Amazon announces 50.16.0.0/16 from AS14618.

At 13:45:44 UTC / 19:15:44 IST D-Vois broadband started originating a more specific 50.16.226.0/24 in the table from AS45769. One of example AS_PATH of this announcement: 198290 197264 197264 197264 29467 1299 9583 45769 Clearly, this leak was carried over by AS9583 (Sify) to AS1299 (Telia) and was carried over to rest of internet from there. There was a visible withdrawal of this request by 14:17:37 UTC / 19:47:37 IST.  

And here goes my first post for 2017. The start of this year did not go well as I broke my hand in Jan and that resulted in a lot of time loss. Now I am almost recovered and in much better condition. I just attended HKNOG 4.0 at Hong Kong followed by APRICOT 2017 at Ho Chi Minh, Vietnam. an event and I enjoyed the both. Here’s my presentation from APRICOT 2017. I recently I came across some of crazy confusing traceroutes as passed by one of my friends. I cannot share that exact traceroute on this blog post but can produce the same effect about which I am posting by doing a trace from one of large network like Telia London PoP to one of the Indian destinations via their looking glass

Today Google (AS15169) seem to be facing issues in their Indian network due to tropical cyclone Vardah. Their traffic at PoPs in Mumbai dipped considerably for a number of ISPs. My guess is that it’s likely because of outage in a large Govt. operator’s network who has overhead fibres along with utility lines.

It’s very important to note that “Google PoP” faced the issue and it’s no where close to saying that Google services went down. Google has a large network across the globe where they peer with networks. If one segment of this network goes down, traffic is re-routed via other parts and as per design even if the network goes down completely in say Mumbai or Chennai, services should stay live. While in real practice considerable degradation occurs because most of the Indian networks get a very large amount of traffic from Google and usually do not have that much extra capacity on their IP transit links, resulting in choking of transits during issues on their PNI with Google.   This shows how traffic of an ISP connected to Google in Mumbai dipped during peak time around at 4pm on Monday 12th Dec (IST) and went to zero little before midnight. I triggered a trace to aspmx.l.google.com. which is outside India from RIPE atlas probes in India and in general routing to that goes via Google’s backbone. Cluster with hostname aspmx.l.google.com (and few others) carry the Gmail/Google Apps traffic and it’s published by Google Apps users in their domain’s MX records.

One of frequent email and contact form message I get my blog is about available content networks in India and where one can peer. There are certain content networks in India and of course most of the content networks have open peering policy and are usually happy with direct inter-connection (we call as “peering”) with the ISP networks (often referred to as “eyeball networks”). Some of these networks have a backbone which connects back to their key datacenter locations on their own circuits via Singapore/Europe, some other have simply placed their caching server where cache fill happens over IP transit. Based on publically known information across community and of course peeringdb, following content players are available in India and known to be open for peering: