Cloudflare

Last year had many interesting developments and one of that has been object storage. For those unaware, object storage is de-facto cloud storage which stores data as objects instead of file system architecture. This gives the option of simple plug-and-play horizontal scalability. It became popular when Amazon Web Services (AWS) launched S3. The idea was straightforward - pay-as-go storage with a few cents/GB/month charge to store data and a few cents/GB to egress data. No need to plan storage, no need to plan hard disk, storage servers, or rack capacity but a simple pay-as-you-go opex cost. Plus top tier cloud players do offer redundancy of data. The API replies with “success” on uploads only when data is replicated to multiple datacenters.

I am in Noumea in New Caledonia in the Pacific Islands. Next week we have APNIC 46 conference and I would be moderating an exciting panel discussion with friends from Akamai, Cloudflare, Facebook and more about working of CDNs. 

If attending APNIC 46, please come & join this session.

If you are interested in connecting to Hurricane Electric (AS6939) in this region, please do drop me a message.

(List of our PoPs in the region here)

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.

BCP38 - also known as “Network Ingress Filtering” is concept where we filter incoming packets from end customers and allow packets ONLY from IP’s assigned to them.   Before going to BCP38, let’s first understand how packets forwarding work:

Here User 1 is connected to User 2 via a series of router R1, R2 and R3. Here R1 and R3 are ISP’s edge routers while R2 is a core router. In typical way the network is setup, entire effort is given on logic of routing table i.e for packets to reach from User 1 to User 2, we need to ensure that User 1 has default route towards R1, knows that User-2’s IP is behind R3 which is reachable via R2. So path User 1 > R1 > R2 > R3 > User 2 comes up. And same for User 2 > R3 > R2 > R1 > User 1 as return path. Now e.g IP pool for User-1 is 192.168.1.0/24 and is using 192.168.1.2 out of it while IP pool for User-2 is 192.168.2.0/24 and is using 192.168.2.2 out of it.  

And I am back from Malaysia after attending APRICOT 2014. It was a slightly slow event this time as less people came up due to change of location from Thailand to Malaysia. But I kind of enjoy the APRICOT in start of year. :)

It has been quite sometime when I blogged. After getting into Spectranet I got relatively more busy along with bit of travelling to Delhi NCR which has been taking lot of time. I wish to blog more over time.