Peering

Peering Operations Contact: noc@fastly.com

Peering Policy Contact: peering@fastly.com

Fastly is a global Content Delivery Network (CDN) with POP (point of presence) locations across the United States, Europe, Asia, and Australasia. Fastly peers with other Internet Service Providers (ISPs) and Content Networks with IPv4 connectivity on Autonomous System (AS) 54113 for the purpose of exchanging traffic between these networks.

Selective Peering Policy

Fastly has a selective but generally open peering policy - peers are selected based upon performance, capability, and where traffic needs to be delivered. Peers are subject to certain operational, technical, and legal requirements.

Operational Requirements

To maintain optimum service levels for our customers and their clientele, peers shall meet the following set of requirements:

• 
  

  Exchange traffic with Fastly at all available IXPs that are shared in common for optimal traffic distribution and redundancy.

  
  


• 
  

  Maintain congestion free interconnection with Fastly. Fastly and peers must work quickly and diligently to augment capacity between networks or to the relevant IXP, as needed.

  
  


• 
  

  Must maintain a Network Operations Center capable of responding operational problems and security incidents 24 hours per day, 7 days per week.

  
  


• 
  

  Be responsive to activities considered malicious and/or detrimental to the Internet as a whole, its own network, and to its customers, including but not limited to, sending unsolicited bulk email, hacking, and denial of service. Fastly expects peers to provide a qualified engineer to help trace and mitigate attacks in a reasonable amount of time.

  
  


• 
  

  Provide an escalation path for resolving operational problems and/or security incidents in a timely fashion.

  
  


• 
  

  Meet all requirements at the time the peering request is made, and must continue to be met for the duration of the peering session.

  
  

Due to the nature of our Content Delivery Network (CDN) service, we:

• 
  

  Scope our routing announcements according to the point of interconnect; providing access to local market POP specific prefixes as well as selected regional and/or global anycast prefixes.

  
  


• 
  

  Do not have a backbone, and therefore do not announce a consistent set of prefixes across IXPs. Peers will not receive a consistent routing table from Fastly across multiple points of interconnection.

  
  


• 
  

  Have a dominantly outbound traffic profile.

  
  

Technical Requirements

The following technical requirements also apply to peering with Fastly. Peers must:

• 
  

  Have a publicly routed ASN.

  
  


• 
  

  Not advertise prefixes with a mask longer than /24 for IPv4.

  
  


• 
  

  Demonstrate that announced publicly routable prefixes and/or aggregates are currently visible in the DFZ.

  
  


• 
  

  Announce a consistent set of prefixes to Fastly at all points of interconnection, unless otherwise agreed upon.

  
  


• 
  

  Only send traffic destined for prefixes announced by Fastly.

  
  


• 
  

  Not point a default route at Fastly or use static routes to send traffic to our AS.

  
  


• 
  

  Set default maximum prefixes per session to 250 prefixes.

  
  


• 
  

  Register their prefixes with appropriate route/route6 objects at an appropriate IRRDB, and maintain a full and accurate PeeringDB listing. Fastly will use this data to build BGP prefix lists.

  
  


• 
  

  Generate prefix lists from the AS-Macro AS-FASTLY, registered at RADB.

  
  

Important Notices

To ensure quality of operations, Fastly reserves the following rights under its Peering Policy and Requirements:

• 
  

  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.

  
  

Additionally:

• 
  

  By advertising prefixes to Fastly, a peer will expressly waive any right to compensation for accepting / delivering traffic originated from Fastly’s ASN.

  
  


• 
  

  Peers with significant traffic with the Fastly AS will be considered for bilateral sessions via IXPs or private (cross-connect) peering.

  
  


• 
  

  Fastly customers interested in a peering connection for origin transit offload should send an email to sales@fastly.com for more information.

  
  

General Peering Information

Peering Contact Information