Redundancy in Google Interconnect Connections
PacketFabric’s infrastructure supports redundancy in both dedicated and partnered connections with Cloud Interconnect. Google recommends multiple ports to prevent traffic from being interrupted in the case of a failure. To this end, users should duplicate connections for dedicated interconnects and VLAN attachments for partnered interconnects.
Provisioning a secondary connection
Users must create redundant connections in the same metro as the existing port in order to achieve redundancy.
Ensure that connections have sufficient capacity
Users should make sure that the capacity is the same across connections and that each connection has the capacity to sustain all traffic in the event of a failover. Additionally, each Google Cloud Virtual Private Cloud (VPC) network should have enough VLAN attachment capacity to carry all traffic in the case of a failover.
Selecting ideal availability zones
When creating VLAN attachments, users should select Google’s metros and availability zones to minimize the risk of outages and decrease latency. Both Google and PacketFabric use the term “availability zone” but they may not mean the same thing. This document’s use of “availability zone” only applies to Google’s use of the term.
Each metropolitan area (metro) contains at least two availability zones. These represent important measures to ensure redundancy; no two domains within the same metro will shut down for scheduled maintenance at the same time. However, because Google does not coordinate maintenance windows between metros, singular connections between metros do not establish redundancy.
This connection is redundant. When zone A goes offline for maintenance or other regular downtime, zone B will remain online.
This connection is not redundant. Because the two connected zones are in different metros, it is possible that both connections can go offline at the same time.
This connection is not redundant. Only zone A is in use, so there is no alternative if zone A goes offline.
Pairing keys for VLAN attachments
Google issues pairing keys that correspond to individual VLAN attachments. These pairing keys contain:
- Randomized key
- VLAN attachment metro
- Edge availability domain
PacketFabric offers users the option to purchase diverse services. For customers purchasing Google Cloud Interconnect services, diverse services constitute services that must be properly connected to at least two access ports in different edge availability domains within a metro.
Google recommends using active/active VLAN attachments
While it is possible to configure redundant VLAN attachments as either active/active or active/passive, active/active attachments are strongly recommended. Although active/passive attachments can also prevent interruptions to service, it is easier to make sure active/active attachments are working correctly.
For more information on configuring active/active and active/passive forwarding, see Configuring devices for active/active forwarding.
Graceful restart and redundant on-premises routers
While not required, Google’s Cloud Router can receive graceful restart messages from a user’s on-premises router, limiting disruptions to traffic in the case that a router must be restarted. By default, Cloud Router sets the timer for expecting new keepalive heartbeats at 1 second. Users should set their own router’s graceful restart timers to an appropriate value for their needs.
If graceful restarts are not supported on the user-end, then restarts on either side of the BGP session cause the session to fail. Google’s Cloud Router sets its BGP timeout at 60 seconds by default, after which routes are withdrawn and traffic is redirected.
Users should configure two separate devices with one connection each, in case a Cloud Router or on-premises router fails.