Google Cloud Interconnect: VLAN Attachment and BGP - 夜莺博客

Google Cloud Interconnect: VLAN Attachment and BGP

Cloud Interconnect gives you a private, SLA-backed path into a VPC instead of sending traffic over the public internet. The product name is simple; the plumbing is three objects: a physical or partner connection, one or more VLAN attachments inside it, and a Cloud Router that forms a BGP session with your on-premises device. Practically every deployment issue shows up as a BGP session that stays down or a prefix the VPC never learns. This guide follows the path from attachment to working route exchange.

Dedicated versus Partner Interconnect

Dedicated Interconnect is your own 10 or 100 Gbps port in a Google colocation facility, offering 10 Gbps circuits per attachment and an MTU of 1500 bytes. Partner Interconnect reaches Google through a service provider, supports smaller increments (from 50 Mbps) and an MTU of 1440 bytes. The attachment is the unit of BGP: each VLAN attachment has its own VLAN tag, its own pair of BGP peer addresses and its own Cloud Router (or a shared one).

Peer addressing and the Cloud Router

  • Each attachment consumes a /29 from a link-local range for the BGP peer addresses; you pick the block when creating the attachment.
  • The Cloud Router is configured with an ASN - 16550 by default on the Google side. If your design requires a private Google-side ASN, that is requested when the attachment is created.
  • Cloud Router is regional. A router in europe-west1 cannot advertise routes for a subnet in asia-east1 unless the VPC uses global dynamic routing.

Configuring the on-premises router

! Cisco IOS-XE example: 802.1Q subinterface towards the attachment
interface TenGigabitEthernet1/0/0.1128
 encapsulation dot1Q 1128
 ip address 169.254.20.2 255.255.255.252
 mtu 1440
!
router bgp 65020
 bgp log-neighbor-changes
 neighbor 169.254.20.1 remote-as 16550
 neighbor 169.254.20.1 description GCP-CloudRouter-euw1
 address-family ipv4 unicast
  neighbor 169.254.20.1 activate
  neighbor 169.254.20.1 route-map ADVERTISE-TO-GCP out
  neighbor 169.254.20.1 maximum-prefix 5000 90

The VLAN tag and the peer addresses must match the attachment exactly. Google does not accept your own AS path manipulation in the same way as some providers, so keep outbound policy to explicit prefix lists plus, where offered, BGP communities for route priority. MD5 authentication can be enabled on the session during attachment creation and must then be configured on the router or the session will not establish.

What the on-premises router should advertise

  • A deterministic, summarised list of your prefixes - a route-map is better than permitting everything, because anything you leak becomes reachable from the VPC.
  • 0.0.0.0/0 only if you deliberately want the VPC to send internet-bound traffic back through your data centre; Google requires an explicit custom route advertisement for that, and it will clash with Cloud NAT designs.
  • Prefixes of equal length from two attachments are load-shared; to prefer one path, advertise a more specific prefix on the preferred link or use the BGP priority options the platform exposes. The generic selection rules are the same as in any BGP deployment - see BGP Best External and Add-Path: Advertise More Paths.

Verification

  1. Console: Hybrid Connectivity > Interconnect - attachment state should be Active and the Cloud Router's BGP session Established with a non-zero learned route count originating from your ASN.
  2. VPC routes: the on-premises prefixes must appear in the VPC route tables with next hop = Interconnect attachment.
  3. MTU: test with ping -M do -s 1412 across the link (1440 MTU minus 28 bytes) before declaring the path healthy; a Partner Interconnect link that is silently fragmenting will pass small pings and break large transfers.
  4. Firewall: VPC firewall rules still decide reachability after routing succeeds.

Design the second attachment as a genuinely independent path - separate router or separate physical port - before you rely on redundant Google-side circuits. The failure modes that hurt are always shared devices, and the same lesson applies to AWS Direct Connect Private VIF and BGP Setup.

原文链接:https://docs.cloud.google.com/network-connectivity/docs/interconnect/how-to/dedicated/configuring-onprem-routers