Cloudflare Peering Policy


Cloudflare operates a global network of more than 165 data centers. Cloudflare (AS13335) has an open peering policy, and will peer with networks that have a presence on mutual exchange points in accordance with the policies described below.

Cloudflare's Peering Portal allows peering partners to see traffic statistics (growth over time, and the relative traffic for each location), peering session statistics (how many sessions are established in various locations), prefix data (IP routes), relative traffic weighting by POP (data flows in and out of connections to Cloudflare from your ASN), plus much more. If you operate a peering network, you can sign up at the Cloudflare Peering Portal or contact us at peering@cloudflare.com


Requirements

Cloudflare uses PeeringDB as a single authoritative source of truth. This means peering partners must have an up-to-date PeeringDB entry before a bilateral peering session can be established.

Cloudflare will use industry standards to secure the peering sessions. This includes industry standard practices and best common practices, including but not limited to BCP-38 and route filtering. Both parties should have a well set-up route-set or AS-SET as well as up-to date prefix maximums defined in PeeringDB. Cloudflare will use this data to filter routes received from the network’s BGP sessions.

Both parties must have an up-to-date NOC contact email, which is responsive to raised issues and concerns.

Private Interconnection (PNI) Requirements

If the network exchanges more than 1Gbps of traffic in a specific (shared) location, either party can request a PNI. We accept single or multiples of 10G or 100G connections. Upgrades to this capacity must happen in a timely manner to ensure congestion-free exchange of traffic.

Important Notices

To ensure quality of operations, we reserve the following rights under our Peering Policy:

  • To alter our peering policy and peering requirements at any time.
  • To accept or decline a peering request at any time for any reason.
  • To suspend, without notice, peering connectivity in the event of a severe quality of service issue such as high latency, packet loss, or jitter pattern is detected and to take appropriate traffic engineering steps to maintain service quality.
  • To selectively withdraw prefixes from public IXP fabrics as needed to protect service quality.
  • To terminate any peering connection at any time without notice.

More details on PeeringDB at https://www.peeringdb.com/asn/13335.

Have Questions?

If you have questions about these terms or anything else about Cloudflare, please don't hesitate to contact us:

Cloudflare, Inc.
101 Townsend St,
San Francisco, CA 94107
USA