Configuring BGP

Where can I find the BGP configuration for a GGC node?

BGP details for each node are shown in the ISP Portal Asset view.

For deployments with ISP owned and managed network devices (switches and routers)

BGP configurations for AS11344 peering (GGC):

  • Our ASN is 11344 (AS65535 is also used for some older deployments).
  • BGP is terminated on one of the GGC servers.
  • Your device must be configured in Passive mode. We do not accept incoming BGP connections to the GGC servers.
  • eBGP Multi-Hop is supported.
  • BGP is used only for Google to receive a list of user prefixes (a.k.a. "prefix-feed") which are candidates to be served by the GGC node
  • BGP is not used for traditional routing. The GGC servers use a default route (first usable IP in the GGC range)
  • The GGC BGP-session operates in passive-mode. Google establishes the BGP-session periodically to collect the prefix-feed. The GGC BGP-session is not intended to be permanently "up" and should not be monitored.
  • We do not advertise any prefixes to you.
  • A maximum of two BGP sessions with AS11344 are permitted at a single GGC node; one for IPv4 and one for IPv6. Consider using a route server if you need to advertise aggregated prefix data from multiple sources on your network.
  • The most-specific prefix size considered by a GGC node is /27 for direct advertisements and /24 for indirect advertisements. For IPv6, the most-specific prefix size is /56 for direct advertisements and /48 for indirect advertisements.

For deployments where Google supplies and manages the network devices (switches and routers)

BGP Configurations for AS36040 peering:

  • Our ASN is 36040.
  • BGP is terminated on our router.
  • Your device may be in Active or Passive mode.
  • eBGP Multi-Hop is supported. Our router will need a route to your BGP peer, either static or via another BGP session.
  • BGP is used both for receiving a list of user prefixes, and for traditional routing.
  • We may advertise the prefix of the the GGC servers to you. You should propagate this advertisement to your users, peers and transit providers. You should also re-advertise a covering prefix to your peers and transit providers, in case the GGC servers prefix is too small to be re-advertised directly.
  • Multiple BGP sessions with AS36040 are permitted at a single location.
  • The most-specific prefix size considered by a GGC node for traffic allocation is /27 for direct advertisements and /24 for indirect advertisements. For IPv6, the most-specific prefix size is /56 for direct advertisements and /48 for indirect advertisements.
  • A maximum of 90000 IPv4 and 15000 IPv6 prefixes can be announced to the GGC router. Announcing more will result in BGP session termination without any notice. In practice, we will start receiving alerts well before these maximum values are reached and will be escalating to you asking to withdraw some prefixes. We may start filtering some advertisements if you don't take action in a timely fashion.

Additional BGP configuration

  • MD5 passwords are supported, but not required, for GGC BGP sessions.
  • Multi Exit Discriminators (MED) are not supported. BGP community tags allow you to provide additional signals to us about prefixes originating in your network. This includes indicating serving preferences for traffic ingressing your network from GGC and peering. For more information, refer to BGP Community Support For Google Serving.

IP Addressing Requirements for Google Routers

GGC nodes that are behind Google routers have additional subnet requirements because of interconnects needed to connect them to the ISP network.

  • Up to 4 interconnects per Google router are supported. Each interconnect may be configured with either IPv4, IPv6, or both address types.
  • Interconnect IPs must be globally routable and reachable.
  • Subnet sizes required for each interconnect type are as follows:
    • A /31 (or larger) IPv4 subnet is required for interconnects with standard configuration.
    • A /29 (or larger) IPv4 subnet is required for interconnects where a redundancy protocol (HSRP, VRRP, etc.) is used at the ISP’s side.
    • A /127 (or larger) IPv6 subnet is required for interconnects.
  • It’s up to the ISP to decide which IP from the allocated interconnect subnet is configured at either side of the interconnect. Google doesn’t have any guidelines or preferences.
  • The interconnects subnet must not overlap the GGC node subnet.

Prefix advertisements to the GGC node

You should advertise all your user prefixes to the GGC node. If you have peers and downstream customers, you may advertise their prefixes too.

For more complex deployments, see the article on multi-node configurations.

Regardless of GGC node type (with or without Google supplied and managed network device) there is a limit on how many prefixes we accept:

  • IPv4: 89900 prefixes
  • IPv6: 14900 prefixes

BGP feeds with more prefixes will be ignored by our systems. This is done to curb potential BGP route leaks in the networks where GGC is deployed.

Prefix advertisements to upstreams 

You should ensure that user prefixes advertised to GGC nodes are also advertised upstream (at AS15169 peering, and via your transit providers), with the same prefix lengths.

Common misconfigurations, which can result in undesirable traffic flows, include:

  • User prefixes seen at GGC, but missing from advertisements to AS15169 or transit
  • User prefixes advertised more specifically at peering / transit than at GGC

You can view information on how we see your prefixes on the ISP portal BGP pages.

Was this helpful?

How can we improve it?
Search
Clear search
Close search
Main menu
5403258647423166221
true
Search Help Center
true
true
true
false
false