
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
    <channel>
        <title><![CDATA[ The Cloudflare Blog ]]></title>
        <description><![CDATA[ Get the latest news on how products at Cloudflare are built, technologies used, and join the teams helping to build a better Internet. ]]></description>
        <link>https://blog.cloudflare.com</link>
        <atom:link href="https://blog.cloudflare.com/" rel="self" type="application/rss+xml"/>
        <language>en-us</language>
        <image>
            <url>https://blog.cloudflare.com/favicon.png</url>
            <title>The Cloudflare Blog</title>
            <link>https://blog.cloudflare.com</link>
        </image>
        <lastBuildDate>Sun, 05 Apr 2026 17:15:38 GMT</lastBuildDate>
        <item>
            <title><![CDATA[CloudFlare meetup in Hong Kong]]></title>
            <link>https://blog.cloudflare.com/cloudflare-meetup-in-hong-kong/</link>
            <pubDate>Wed, 15 Aug 2012 19:50:00 GMT</pubDate>
            <description><![CDATA[ CloudFlare's Network Engineer, Tom Paseka, will be in Hong Kong at the end of August. During his time there, we wanted to host a meetup for CloudFlare users and anyone interested in web performance and security. ]]></description>
            <content:encoded><![CDATA[ <p></p><p>CloudFlare's Network Engineer, Tom Paseka, will be in Hong Kong at the end of August. During his time there, we wanted to host a meetup for CloudFlare users and anyone interested in web performance and security.</p><p>The event will include a short presentation on what's new at CloudFlare, features we've added, and a preview of what's on the roadmap. Afterwards, Tom will answer any questions that you may have.</p><p>If you're a CloudFlare user, come introduce yourself to Tom. If you're not a CloudFlare customer, but interested in web performance and security, then you are welcome to join as well. We look forward to meeting our users and friends from China!</p>
    <div>
      <h3>Meetup Details</h3>
      <a href="#meetup-details">
        
      </a>
    </div>
    <ul><li><p>Saturday, August 25</p></li><li><p>5:00pm</p></li><li><p>Hong Kong (exact location TBD)</p></li></ul><p>RSVP &amp; More information: <a href="http://www.meetup.com/CloudFlare-Meetups/events/77779312/">http://www.meetup.com/CloudFlare-Meetups/events/77779312/</a></p><p>Note: We are still confirming our venue. If you have a suggestion,please let us know.</p> ]]></content:encoded>
            <category><![CDATA[Community]]></category>
            <category><![CDATA[MeetUp]]></category>
            <category><![CDATA[Cloudflare Meetups]]></category>
            <category><![CDATA[Hong Kong]]></category>
            <guid isPermaLink="false">4ipAoywVvzdXYp2athZR80</guid>
            <dc:creator>Kristin Tarr</dc:creator>
        </item>
        <item>
            <title><![CDATA[Today's Outage Post Mortem]]></title>
            <link>https://blog.cloudflare.com/todays-outage-post-mortem/</link>
            <pubDate>Wed, 02 May 2012 20:41:00 GMT</pubDate>
            <description><![CDATA[ CloudFlare had an outage across much of our network today. The outage began at 20:19 (GMT). It affected approximately 75% of traffic to CloudFlare's network. The length of time for the outage varied depending on region, but the maximum period of downtime was approximately 15 minutes.  ]]></description>
            <content:encoded><![CDATA[ <p>CloudFlare had an outage across much of our network today. The outage began at 20:19 (GMT). It affected approximately 75% of traffic to CloudFlare's network. The length of time for the outage varied depending on region, but the maximum period of downtime was approximately 15 minutes. I wanted to quickly get information out about what happened, why it happened, and what we're doing to ensure it never happens again.</p>
    <div>
      <h3>Routes, Routers and Routing</h3>
      <a href="#routes-routers-and-routing">
        
      </a>
    </div>
    <p>To understand the problem, you need to understand a bit about how Internet routing works. The Internet is a massively interconnected network. Networks send packets to each other across routes. These routes are set for each network by routers. A route defines the path for packets to take to get to a particular IP address. One network will announce that it is responsible for a particular set of IP addresses. That fact is then shared to upstream routers so if they see a packet bound for a particular IP they can send it in the correct direction.</p><p>Routers exchange routes between each other using something called Border Gateway Protocol (BGP). When two networks interconnect, they generally trust each other's routes. If a routing change is announced by one router, the immediately connected upstream routers will pickup the routing change. They will subsequently pass the change on to other routers that are further upstream.</p>
    <div>
      <h3>Bad Route to Hong Kong</h3>
      <a href="#bad-route-to-hong-kong">
        
      </a>
    </div>
    <p>Today we had a scheduled maintenance for our Hong Kong data center while its systems were being upgraded. The data center was taken offline by shutting down all the in-bound Anycast routes. This, as we intended, caused all traffic that would have gone to that data center to hit the next closest facility (either Singapore or Tokyo).</p><p>While the systems were being upgraded, our network team worked to optimize some of the routing in Hong Kong. At some point, the out-bound routes were entered into the in-bound interface. The out-bound routes describe our entire net range so the net effect was the router in Hong Kong was announcing that it was the correct place to send all traffic bound for CloudFlare's IP space.</p><p>Our upstream provider trusts our routes so, via BGP, they were quickly relayed throughout their network and to their upstreams. The result was traffic from around the world was directed to the Hong Kong data center, which was offline. We realized the issue and announced the corrected routes. It took approximately 15 minutes from the beginning of the problem to when the routes were corrected network wide. About 25% of CloudFlare's in-bound traffic comes from direct peers. This traffic was not affected by the routing because the direct peers trusted our routes more than the ones they were receiving from other upstreams.</p>
    <div>
      <h3>Future Prevention</h3>
      <a href="#future-prevention">
        
      </a>
    </div>
    <p>We are implementing systems to run all routing changes through a verification layer that double check before any routes are announced. We are also talking with all our upstream providers to enable additional checks on their networks that do not automatically propogate major routing changes without confirmation.</p><p>This is only the second significant outage in CloudFlare's history (here's our <a href="/post-mortem-the-ugly-the-bad-the-good">post mortem from the other</a>). Any period of downtime is completely unacceptable to us. On behalf of our whole team, I apologize for the problem. We have learned from this experience and are already implementing the safeguards to ensure it will not happen again.</p> ]]></content:encoded>
            <category><![CDATA[Post Mortem]]></category>
            <category><![CDATA[BGP]]></category>
            <category><![CDATA[Outage]]></category>
            <category><![CDATA[Hong Kong]]></category>
            <guid isPermaLink="false">6vJ0V87aC7lu4aNbN5TdYq</guid>
            <dc:creator>Matthew Prince</dc:creator>
        </item>
        <item>
            <title><![CDATA[CloudFlare is Now Part of the Hong Kong Internet Exchange (HKIX)]]></title>
            <link>https://blog.cloudflare.com/cloudflare-is-now-part-of-the-hong-kong-inter/</link>
            <pubDate>Wed, 28 Mar 2012 17:14:00 GMT</pubDate>
            <description><![CDATA[ CloudFlare is now connected to HKIX (Hong Kong Internet Exchange). HKIX is the largest Internet Exchange in Asia transferring around 200Gbit to its 160 ISP, Carrier and Content networks.  ]]></description>
            <content:encoded><![CDATA[ <p></p><p>CloudFlare is now connected to <a href="http://www.hkix.net">HKIX (Hong Kong Internet Exchange)</a>. HKIX is the largest Internet Exchange in Asia transferring around 200Gbit to its 160 ISP, Carrier and Content networks. HKIX is fundamental to the local Hong Kong ISP Market, with every provider in Hong Kong connected, as well as excellent regional coverage with networks from Thailand to Japan to Australia.</p><p>So, what does a connection to HKIX mean for CloudFlare users? Faster performance for your Hong Kong web surfers. Being a part of the HKIX allows us to deliver traffic to all Hong Kong web surfers within Hong Kong. This will improve web browsing performance by keeping the traffic local and the latency low.</p><p>Connecting to HKIX is one of the steps CloudFlare is working on to bring the Internet closer to you. Watch for more news to come over 2012!</p> ]]></content:encoded>
            <category><![CDATA[Hong Kong]]></category>
            <category><![CDATA[Peering]]></category>
            <category><![CDATA[Speed & Reliability]]></category>
            <category><![CDATA[Speed]]></category>
            <category><![CDATA[Cloudflare Network]]></category>
            <guid isPermaLink="false">IpcXLrpp6M65atwmnRELY</guid>
            <dc:creator>Tom Paseka</dc:creator>
        </item>
    </channel>
</rss>