How to Turn Up Peering with Google

Thank you for your interest in peering with Google! This section guides you through the process to turn up peering sessions with Google.

Submit Peering Request

If this is your first time turning up a peering session with Google, submit your request via our partner request form.

Peering Request Approval Process

You’ll get a status update from Google about your peering request within 5 business days. If your request is approved, review the following requirements and recommendations before going through the remainder of the process.

Technical Requirements and Recommendations to Peer with Google

The following technical requirements and recommendations apply for both PNI and IX requests:

• Technical requirements:
  • Publicly routable address space (at least one /24 of IPv4 and/or one /48 of IPv6 space).
  • 24x7 NOC contact.
  • Current Maintainer, ASN, AS-SET, and Route / Route6 objects in an IRR that Google supports. For the AS-SET object, update it at your PeeringDB record. You can find further documentation and resources about our IRR requirements here.
     
• Technical recommendations:
  • We strongly recommend that you enable a BGP graceful restart to avoid any traffic shifts or problems on your side when Google performs automated software updates. Google uses a timer of 300 seconds and suggests that you apply a similar timer.
  • Configure your network and BGP sessions so that your traffic to Google is load balanced across all your peering sessions with Google (this can be achieved by using BGP Multipath or ECMP). Google doesn’t support BGP Multihop.
  • Don’t prepend your ASN in announcements to us. It’s unnecessary and it won’t result in traffic flow changes that meet your expectations. Google operates customized traffic control systems that take BGP information as one of a number of signals.
  • Configure a max-prefix limit of 15000 IPv4 prefixes and 10000 IPv6 prefixes on your sessions with AS15169. 
  • If you’re applying inbound filters and use IRR data, the set of prefixes we will announce are documented in RADB in the AS-SET called AS-GOOGLE. 
     
• During turn up, your primary contact is the peering turnup staff member who helps you to interconnect with Google. Don’t email any previous Google contacts that have helped you with other turnups or other topics.

Turn up an Internet Exchange (IX) Session with Google

Once your peering request is approved, our automated systems guide you throughout the rest of the process. The IX turn up process is as follows:

1. Ping test: 
   1. This process is started by validating IP connectivity to your IX production IPs.
2. Production configuration:  
   1. Once we validate IP connectivity to your IX IPs, we begin with the production configuration. 
   2. Once the production configuration is ready, we run tests and validations. We will notify you if there are any issues.
3. Final validation:
   1. Once BGP is established, we will run final validations on our end.
   2. Once we complete these validations, we start announcing traffic and accepting your prefixes.
4. Following the application of production traffic, you can get 24-hour follow-up support from Google NOC by contacting, [e-mail]. 

Turn up a Private Network Interconnect (PNI) with Google

Once your peering request is approved and the details about capacity and location have been finalized, Google’s service provisioning team will work with you throughout the rest of the process. The PNI turn up process is as follows:

1. Cross connects:
   1. Our service provisioning team will reach out to you if further clarification of demarcation information is needed.
   2. If physical cabling faults, we will work with the appropriate cross connect providers to resolve issues, but we also need coordination and cooperation from you.
2. Physical link(s) test:
   1. Once cross connects are completed and the link(s) comes up, Google requires a test for each physical link that is enabled. 
   2. The physical link test consists of a ping test. Our automated systems run the ping tests with the testing IPs provided by Google or by you.
   3. If you are blocking or rate-limiting ICMP, our service provisioning team will contact you to request removal of limitations which prevent successful testing. 
   4. As part of our testing, we send 1500 byte ICMP ECHO_REQUEST (ping) packets with the fragment bit set. 
   5. We expect you to run a 1500 byte MTU on the interfaces used to interconnect with Google. 
   6. If the 1500 byte ping packets fail, we can’t proceed with the turn up until the issue is corrected.
3. Production configuration:  
   1. Once all the individual links have passed their tests, we start the production configuration.
   2. The production IP addresses are provided by whoever orders the cross-connects (either Google or you). 
   3. Assemble the LACP bundle with production IP addresses.
   4. Configure BGP (Google requires MD5 to be configured). 
4. Once the production configuration is ready, we run tests and validations. We will notify you if there are any issues:
   1. During the LACP bundle testing phase, the LACP protocol is enabled / disabled for each individual member link. 
   2. You might see messages in your router’s system log as the LACP bundle and member links run through our testing processes. This is normal, and to be expected.
   3. Once testing successfully completes, the interface state transitions stops.
   4. We will run ping tests using the production IPs.
   5. Finally, we validate that BGP has been established.
5. Final validation:
   1. Once BGP is established, we run final validations on our end.
   2. Once these validations are complete, we start announcing traffic and accepting your prefixes.
6. Following the application of production traffic, you can get 24-hour follow-up support from Google NOC by contacting, [e-mail].