Cloudflare Peering Portal - Beta

It can be a big deal for Internet users when Cloudflare rolls into town. After our recent Mongolia launch, we received lots of feedback from happy customers that all of a sudden, Internet performance noticeably improved.

As a result, it's not a surprising that we regularly receive requests from all over the world to either peer with our network, or to host a node. However, potential partners are always keen to know just how much traffic will be served over that link. What performance benefits can end-users expect? How much upstream traffic will the ISP save? What new bandwidth will they have available for traffic management?

Starting today, ISPs and hosting providers can request a login to the Cloudflare Peering Portal to find the answers to these questions. After validating ownership of your ASN, the Cloudflare network team will provide a login to the newly launched Peering Portal - Beta. You can find more information at: cloudflare.com/partners/peering-portal/

If you're new to the core infrastructure of the Internet, the best way to understand peering is to frame the problems it solves:

1. Bandwidth costs money

2. Internet users don't like slow websites

3. Network operators have limited resources

Consider what happens if you request a site hosted on Cloudflare from home:

• The domain resolves to a Cloudflare IP

• Your browser sends an HTTP request to that IP

• Your ISP's routers consult their routing table and route the packets upstream to their transit provider (COSTS MONEY)

• The packets traverse multiple hops to the nearest Cloudflare POP (TAKES TIME)

• Those packets are taking up some of the ISPs capacity, making it unavailable for other competing packets (TRAFFIC MANAGEMENT)

As Cloudflare continues to grow, we represent an ever-increasing share of the Internet's traffic. A Network Administrator reviewing his or her network, will see this represented as an increasing cost of bandwidth, of slower than optimal request times and of bandwidth not able to be allocated for other competing traffic.

To address these problems, large networks, hosting providers and CDNs will peer with each other. That is, to interconnect their networks directly. Put another way, cut out the middleman. If I request a site on Cloudflare and my ISP is already directly connected to the Cloudflare network, the packet will traverse fewer hops, my website will load faster, my ISP will pay less to their transit provider and they can allocate that bandwidth for other sites.

There are a few different types of peering. The simplest way to conceptualize is plugging in a dedicated cable to exchange data directly between two networks. Practically, there a few ways it happens:

Scenario 1: Private Network Interconnect (PNI)

If Cloudflare and the potential peering partner have equipment in the same data center, we can setup a "Private Network Interconnect", which involves dedicated cabling and network configuration.

PNI: Private Network Interconnect

Scenario 2: Internet Exchange Point (IxP)

An Internet exchange point (IxP) is a physical location through which Internet companies such as Internet Service Providers (ISPs) and CDNs connect with each other. It typically involves a switching-fabric, that Cloudflare is already connected to. If our potential peering partner is also present in the IxP, setting up peering is a simple as network configuration, with no additional cabling required.

Internet Exchange Point (IxP)

Scenario 3:  Hosting a Node

There are scenarios where neither PNI nor IxP peering is feasible, such as when Cloudflare and our potential partners are not present in the same physical location. In these cases, our partner can request to host Cloudflare equipment in their own data center racks. Once commissioned, the equipment effectively operates as if it were a Cloudflare data center (PoP). The cache will populate and all of our performance and reliability services will execute right there, close to our peering partner's customer.

Hosting a node

So every network should peer all the time?

Peering still has some costs - particularly an administrative burden. The Network Administrators have to agree the details. Commercial teams may require contractual agreements. The link has to be monitored. Therefore, most large networks will have a peering policy and prioritize peering with the networks with which they exchange the most data and will thus generate the most mutual value.

This is especially true for hosting nodes. In addition to the configuration and contractual agreements, there is the logistical effort of receiving and configuring equipment.

So when should networks peer with Cloudflare?

The Peering Portal - Beta, released today, allows any ASN (Autonomous System Number) network to view detailed statistics on transit data between it and Cloudflare. Existing partners can use it to review existing session data and statistics and prospective partners can use it to estimate potential transit cost savings, performance improvements and the freeing up of upstream bandwidth to use for other traffic.

The Peering Portal allows both existing and prospective partners to see:

Time Series Traffic Statistics

This view shows both growth over time, and the relative traffic for each location.

Time series traffic data

Peering Session Statistics

Peering sessions outline how many sessions are established in various locations.

Session Statistics

Prefix Data

POP Relative Traffic Weighting

At a glance view of where data flows in- and out- of connections to Cloudflare from your ASN.

Relative Traffic Weight by Peering Location

We plan to add many more statistics over time.

So, whether you're a current peering partner who'd like more insight into your current traffic with Cloudflare, or a future partner who'd like to explore the performance, financial and traffic management benefits of peering with Cloudflare, or hosting a node visit cloudflare.com/partners/peering-portal and request a login.

You can also review our peering policy here.