Jump to Content
Networking

Reliable peering to access Google Cloud

October 17, 2022
Dave Schwartz

Senior Product Manager, Google Global Networking

Peering is often seen as a complex and nuanced topic, particularly for some of our Cloud customers. Today we’d like to demystify peering’s inner workings and share how a peering policy update that requires local redundancy helps improve reliability for our users and customers. Redundancy is a well understood and documented concept to improve reliability. We have talked previously about how our significant investments in infrastructure and peering enables our internet content to reach users and how we are making our peering more secure

Google Cloud on the internet

Every day Google Cloud customers collaborate with colleagues using Workspace, leverage Google Cloud CDN to serve content to users worldwide or choose to deploy a Global Cloud Load Balancer to leverage our anycast IPs. Each use case has the same thing in common: these and many other Google products rely on peering to connect Google’s global network to ISPs worldwide to reach their destination, users like you and me. 

Peering delivers internet traffic

Peering is the physical fiber interconnection between networks such as Google and your Internet Service Provider (ISP), or between Google and cloud customers, which occurs at various facilities all around the world. Its purpose is to exchange public internet traffic between networks to optimize for cost and performance. Google has built our network to over 100 facilities worldwide to peer with networks both large and small. This is how Google provides a great experience for all of our users, reduces costs for ISPs, and is one of several ways our cloud customers can connect to the Google network. One of the other common ways enterprises connect to Google Cloud that is often confused with peering is Dedicated Interconnect, which offers private connectivity between your on-premise environment and Google Cloud. 

Think of peering like part of a city water system where the pipes are the fiber optic cables and the water is the bits of data coming to your phone, computer, or data center. Just as your city's water system needs to interconnect to your house plumbing, Google’s global network needs to interconnect to your neighborhood ISP to deliver all types of Google traffic. The water flowing out of your sink faucet is analogous to being able to use Google services on your home Wi-Fi. 

Peering infrastructure

Thousands of networks including Google are peering with each other all over the world every day. Networks who peer mutually agree on the locations and capacity to address traffic demand, cost, and performance. Since there are so many networks worldwide it is not practical for every network to peer with each other so most networks retain some type of IP transit that allows users to reach the entirety of the internet. Essentially, IP transit is a paid service offered to networks to ‘transit’ another well connected network to reach the entirety of the internet. This transit also acts as a failover path for when a peering connection is unavailable, and plays an important role in ensuring the universal reachability of every endpoint on the Internet. One potential downside to transit is that traffic may traverse an indirect and costly path to reach an end user which therefore can decrease performance compared to peering. Google’s preference is to deliver all traffic on the most optimal peering paths to maximize performance.

When peering goes down

With any type of physical infrastructure, components can malfunction or need to be taken out of service for maintenance. The same is true for the infrastructure that supports peering. Downtime can sometimes last days or weeks depending upon the cause and time to repair. During downtime, internet traffic to and from Google gets rerouted to failover paths. Sometimes these paths are another peering location in the same city, sometimes they are rerouted hundreds or thousands of miles away to peering in a different city or even country, and in some cases to an IP transit connection if no other peering connection is available. Much of this depends upon how and where a network is peered with Google.  The further the traffic is physically rerouted from the intended peering connection, and if any IP transit connections are in the traffic path, the higher the likelihood of increased latency, packet loss, or jitter, all of which can translate into a frustrating or poor user experience. 

A deep and diverse peering footprint

Over many years we have built our peering with ISPs and cloud customers to be both physically redundant and locationally diverse to ensure an optimal user experience for all Google services. This translates to a deep and diverse peering interconnection footprint with networks and customers around the world. As Google Cloud services like Premium Network Tier, Cloud VPN, and Workspace use peering to reach their end users, this type of planning helps to avoid user experience issues mentioned above. 

A more stable and predictable peering interconnect

To help achieve our goal of a reliable experience for all Google users we have recently updated our peering policy to require physical redundancy on all Google private peering connections within the same metropolitan area. This update will allow Google and ISPs to continue to exchange traffic locally during peering infrastructure outages and maintenance under most circumstances. For our customers and users this means more predictable traffic flows, consistent and stable latency, and a higher effective availability of peering that provides an overall more predictable experience with Google services, while still offering cost savings to ISPs. There are a multitude of factors that can influence performance of an application on the internet, however this change is designed so that outages and maintenance on our peering infrastructure will be a less noticeable and impacting experience.  You can read more details about the change on our peering page.

https://storage.googleapis.com/gweb-cloudblog-publish/images/redundant-links.max-2200x2200.jpg
Fig A - Two examples of metropolitan area peering redundancy. A redundant peering link (green) in the same metropolitan area helps keep traffic local during peering infrastructure maintenance or outages.

Working with our peering partners and customers

We are working closely with our existing and new Google Cloud customers and ISP peers to ensure we build out locally redundant peering interconnects. We also know that many networks have challenges to build this configuration so we are identifying ways to work with them.  We encourage Google Cloud customers and any ISPs who are interested to review their redundancy topology with Google to contact us, and to also review our best peering practices. To learn more about peering and to request peering with Google please visit our Peering website

Posted in