Google PCNE: 混合式連線、Cloud Router 與 BGP — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

屬於 Google Professional Cloud Network Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Google Cloud 上的混合式連線能力，能在 VPC 網路與外部網路（例如地端資料中心或其他雲端）之間，建立私密且受控的通訊。其核心建構模組為 HA VPN 與 Cloud VPN 閘道、使用 BGP 進行動態路由的 Cloud Router，以及帶有 VLAN attachment 的 Interconnect。設計時必須在頻寬、延遲、可靠性、維運複雜度和成本之間取得平衡，同時遵循確定性的路由行為和故障域隔離原則。本節將涵蓋設計與維運的考量、常見的故障模式，以及系統性的疑難排解方法。

混合式連線能力：HA VPN、Cloud Router 與 Interconnect

HA VPN 與 Cloud VPN
- HA VPN 是一種區域性、高可用性的 IPsec VPN，支援 IKEv2 並需要 Cloud Router 來進行動態路由 (eBGP)。一個 HA VPN 閘道有兩個介面；為了達到 SLA 和 ECMP 的要求，每個介面應建立兩個通道連至不同的對等端點。
- Classic Cloud VPN 支援 IKEv1 或 IKEv2 以及靜態或基於路由的通道；它不支援 HA VPN 的 SLA。只有在對等端點缺乏 BGP 支援，或您必須使用基於政策的選擇器時才使用它。
- 對等閘道 (Peer gateway) 是遠端的 VPN 設備/IP。對於 HA VPN，請定義一個具有一或多個公用 IP 的對等 VPN 閘道，以模擬不同的介面或設備來實現備援。
- SLA 設計：要符合 HA VPN 99.99% 的 SLA 資格，需跨獨立的地端設備或介面部署備援通道，並使用動態路由。Classic VPN 沒有 SLA 的支援。
- 吞吐量擴展：單一 IPsec 通道的吞吐量有限。可使用 ECMP 跨多個通道來增加總吞吐量。要實現此目的，可將額外的通道終止於獨特的對等公用 IP 上。
Cloud Router 與 BGP
- Cloud Router 是一種區域性的控制平面服務，它與 VPN 通道或 Interconnect 的 VLAN attachment 建立 BGP 會話，並動態交換路由。
- 動態路由模式 (VPC 層級) 決定了學習到的動態路由可在何處使用，以及哪些 VPC 子網路路由會被通告出去：
  - Regional：僅在相同區域學習和使用/匯入動態路由。
  - Global：在所有區域學習和使用/匯入動態路由；並向對等點通告所有 VPC 子網路路由 (全域)。
Dedicated Interconnect 與 Partner Interconnect
- Dedicated Interconnect 在主機託管設施中提供直接連到 Google 的實體 10 Gbps 或 100 Gbps 線路。您會取得一份授權書－連接設施分配 (LOA‑CFA) 以啟用 cross‑connect。接著建立 VLAN attachment (interconnect attachment)，將 802.1Q 標籤對應到與 Cloud Router 關聯的區域性 L3 連線。
- Partner Interconnect 透過服務供應商提供邏輯連線。您向合作夥伴請求 VLAN attachment；頻寬會在合作夥伴的邊緣交付。同樣需要將 attachment 與 Cloud Router 關聯以進行 BGP。
- 備援與 SLA：在同一區域使用兩個位於不同邊緣可用性網域 (以及適用情況下，位於不同實體 interconnect) 的 attachment，以達到更高的 SLA (例如 99.99%)。單一 attachment 或鏈路會降低 SLA。對於 Partner Interconnect，整體 SLA 也取決於合作夥伴。
Cross‑connects 與 VLAN attachments
- Cross‑connects 是在 meet‑me room 中，連接您的機櫃/設備與 Google 機櫃之間的實體光纖連線。將 LOA‑CFA 提交給您的供應商以完成連線。
- VLAN attachments 是到 VPC 區域的邏輯 L2 分界點。每個 attachment：
  - 透過一個 Cloud Router，僅與一個 VPC 和區域關聯。
  - 成對設定以實現備援和 ECMP。
  - 僅承載 L3 流量；不支援 L2 延伸。

簡短範例：

為一個 attachment 或 HA VPN 對等點建立 Cloud Router 和 BGP： gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

路由與 BGP 行為

動態與靜態路由
- 使用 Cloud Router 的動態路由提供自動路由學習、收斂和 ECMP。隨著網路規模擴大，它能擴展並減少維運開銷。
- 當對等點缺乏 BGP 或需要範圍狹窄、確定性的路徑時，適合使用靜態路由。在 VPC 中，靜態路由具有數字優先權；對於相同前綴長度的靜態路由，較低的值會被優先採用。
- VPC 中的路由選擇：
  - 最長前綴匹配者勝出。
  - 子網路路由無法被自訂路由覆蓋。
  - 對於相同的前綴長度，靜態路由會依據最低的優先權被選中。在動態路由中，Cloud Router 在安裝路由前就已經解析出最佳路徑。系統預設路由的優先權最低。
BGP 會話、通告與匯入/匯出
- Cloud Router 預設會匯出 VPC 子網路，或是一組自訂的前綴。您可以在需要時通告 0.0.0.0/0 或聚合前綴，但如果政策允許，這樣做會將地端流量拉向雲端；請謹慎設計。
- Cloud Router 會匯入任何允許的地端前綴，並根據 VPC 的動態路由模式將其安裝為動態路由。
- 每個對等點的通告路由優先權可讓您影響地端路由器如何偏好某個 Google 路徑而非另一個；較低的優先權值會轉換為朝向該對等點的、更受偏好的 MED。
ASN、MED 與主動-備援
- 除非有必要使用公有 ASN，否則每個管理網域應使用唯一的私有 ASN。對於多個地端路由器為相同的前綴與同一個 VPC 建立對等關係時：
  - 要啟用 ECMP 或一致的最佳路徑，請在所有通告相同前綴的路由器上使用相同的地端遠端 ASN。不同的遠端 ASN 可能會阻止在 Cloud Router 上安裝等價路徑。
  - 對於主動/備援模式，可從地端操控 MED (較低者更優先)，或調整 Cloud Router 的每個對等點通告路由優先權，使地端偏好主要路徑。AS-path prepending 是另一種選擇，但工具較為粗略。
多路徑設計
- Cloud Router 支援在多個等價的 BGP 路徑上為 HA VPN 和 Interconnect attachment 執行 ECMP。請確保屬性相等 (AS-path 長度、MED、local-pref) 且下一跳不同。對於 HA VPN，請將通道終止於不同的對等點 IP。對於 Interconnect，請使用備援的 attachment。

彈性、偵測與出口服務

BFD 與故障偵測
- BFD 加速了 HA VPN 和 Interconnect 上 BGP 會話的故障偵測。請在兩端啟用 BFD 並設定相容的間隔時間，以根據您的穩定性需求實現亞秒級或低秒級的偵測。可與 IPsec 通道上的 IKE DPD 結合使用。請確保您的對等設備能夠處理更頻繁的控制流量。
- 請注意非對稱偵測：過於積極的 BFD 加上壅塞的鏈路可能導致會話抖動；建議從保守的計時器開始並進行監控。
備援拓撲模式
- HA VPN：每個區域使用一個 HA VPN 閘道，並將通道終止到兩個不同的地端設備或介面。每個區域至少建立四個通道 (每個介面兩個) 和一個 Cloud Router。在提供 ECMP 時，保持遠端 ASN 的一致性。
- Interconnect：在每個區域中，跨越不同的邊緣可用性網域使用至少兩個 attachment。對於 Dedicated Interconnect，盡可能將鏈路部署在不同的邊緣設備和設施中。
Cloud NAT、外部位址與私有工作負載的出口
- Cloud NAT 是針對沒有外部 IP 的資源所提供的區域性、託管式出口服務。它不會對擁有外部 IP 的執行個體進行 SNAT；這些執行個體會直接出口。選擇一個區域中的部分或所有子網路來涵蓋私有工作負載。
- 根據並行連線數和臨時埠口來規劃 NAT IP 池的大小；選擇手動或自動 IP 分配。啟用日誌記錄以供診斷。
- 要私下存取 Google API：
  - 在 VPC 內：在子網路上啟用 Private Google Access，以便沒有外部 IP 的 VM 可以透過 Google 的虛擬 IP 存取 Google API。
  - 從地端：為 Google API 使用 Private Service Connect 端點和混合式 DNS，這樣地端用戶端就能透過私有混合鏈路解析並存取 API，從而避免使用網際網路。
- 如果預設路由指向第三方防火牆，但您希望私有工作負載繞過它來存取 Google API，可以使用 Private Service Connect，或者為已發布的 Google API IP 範圍安裝指向預設網際網路閘道、且優先權更高的靜態路由，並結合在子網路上啟用 Private Google Access。
混合式 DNS 整合
- 使用 Cloud DNS 私有區域進行 VPC 內的名稱解析。可透過以下方式擴展至地端：
  - 入向轉送：地端解析器將 VPC 中託管的私有區域查詢轉送到 Cloud DNS。
  - 出向轉送：VPC 解析器將選定的網域查詢轉送到地端 DNS。
  - 對等區域：用於在 Shared VPC 或多專案環境中進行跨 VPC 解析。
- 為了實現私有 API 的可達性，請建立一個私有區域，將 API 主機名稱對應到 Private Service Connect 端點，或在使用 Private Google Access 時對應到適當的 Google 私有 VIP，並確保這些名稱可以透過 DNS 轉送從地端解析。

規劃與疑難排解

頻寬、延遲與成本的權衡取捨
- VPN: 部署最快，固定成本最低，但每個 tunnel 的吞吐量有限，每位元的 CPU/加密開銷較高，且與私有線路相比，延遲通常較高。
- Dedicated Interconnect: 吞吐量最高，每位元成本最低，延遲可預測；但固定成本和前置時間（cross-connects、主機託管）較高。
- Partner Interconnect: 中間方案；利用供應商的服務據點；SLA 和延遲取決於合作夥伴的路徑。
- 將 attachments 和 gateways 部署在區域上靠近工作負載的位置，以最小化延遲。使用 Shared VPC 將連線能力集中在一個 host project 中，同時服務多個 service projects。
- 考量流量對稱性、檢測需求和故障域。避免在本地端最後一哩和供應商路徑中出現單點故障。
系統化診斷 tunnel、BGP 和路由問題
1. Tunnel 建立
  - 驗證 IKE 版本相容性：HA VPN 需要 IKEv2；如果對等端只支援 IKEv1 或 policy-based VPN，請使用 Classic VPN。
  - 檢查共享密鑰、提議 (加密、DH 群組)、NAT-T，以及 UDP port 500/4500 的可達性。
  - 確認對等 IP，並確保每個 tunnel 指向一個獨立的對等介面以實現備援。
2. BGP session 健康狀態
  - 確認兩端的 BGP 狀態；檢查 Cloud Router 狀態。如果已啟用 BFD 但 session 不穩定 (flap)，請放寬計時器設定。
  - 驗證 ASN 設定；預期不符可能導致 ECMP 無法運作或出現非預期的最佳路徑選擇。
  - 確保 BGP session 的 IP 位址使用在 tunnel 或 attachment 介面上設定的正確 link-local 或 RFC1918 位址。
3. 路由交換與傳播
  - 檢查 Cloud Router 的通告模式 (DEFAULT vs CUSTOM)。確保預期的子網路或匯總路由有被匯出。
  - 檢查 Cloud Router 上收到的路由；評估 AS-path、MED。如果意圖是 active/standby，請確保 MED 或通告的路由優先級反映此意圖。
  - 驗證 VPC 的動態路由模式 (REGIONAL vs GLOBAL)，以便學習到的路由出現在需要的地方。請記住，子網路路由無法被覆寫。
  - 對於衝突情況，如果靜態路由和動態路由符合相同的前綴長度，則優先級最低的靜態路由會勝出。當出現非預期的重疊時，請調整或移除重疊的靜態路由。
4. 資料平面驗證
  - 使用 VPC Flow Logs 和 Cloud NAT logs 來確認出口路徑和位址轉換。如果 VM 仍然使用其外部 IP 出口，請移除該外部 IP 以強制使用 NAT。
  - 對於 Interconnect，驗證 attachment 的操作狀態，並確認兩個 attachments 都已啟用管理員權限且關聯到正確的 Cloud Router。
  - 確認防火牆規則允許 BGP 和應用程式流量；請記住，必須允許 Google health check 的來源範圍到達負載平衡器的後端。
5. Interconnect 啟用細節
  - 從主控台或 NOC 聯絡電子郵件取得 LOA-CFA。在啟用 BGP 之前，與供應商確認 cross-connect 的光纖訊號強度和 VLAN tagging。

實務問題情境

Contoso 製造公司正在將 ERP 工作負載遷移到 Google Cloud，同時保持本地工廠的線上運作。需求：20 Gbps 的私有連線能力，具備次秒級的容錯轉移、集中式路由控制、從本地到雲端的 active/standby 出口、無需透過公用網際網路即可私密存取 Google API，以及最小化的維運開銷。

解決方案：

在同一個都會區內，跨越不同的邊緣可用性網域和設施部署兩個 Dedicated Interconnect 線路；每個區域建立兩個 VLAN attachments (主要和次要)，並將它們關聯到一個區域性的 Cloud Router。
- 理由：Dedicated Interconnect 提供所需的總吞吐量和可預測的延遲。備援線路和 attachments 可隔離故障，並符合更高 SLA 的資格。多個 attachments 可實現 ECMP 並在不中斷流量的情況下進行維護。
每個區域設定一個 Cloud Router，並配置兩個 BGP peer (每個 attachment 一個)，然後啟用 BFD。
- 理由：單一 router 簡化了控制平面的管理，同時仍支援透過多個 next hop 實現 ECMP。BFD 將故障偵測時間縮短至數秒內，改善了 ERP 應用程式的收斂 RTO。
在與 Google 對接的兩個工廠邊緣路由器上，標準化使用相同的本地端遠端 ASN，並從每個路由器通告相同的 prefix。
- 理由：匹配的遠端 ASN 允許 Cloud Router 在需要時安裝等價路徑 (equal-cost paths) 並進行負載平衡。如果使用不同的 ASN，可能只會安裝一組路由，從而無法實現多路徑。
使用 MED 實作從本地到 Google 的 active/standby 偏好，並使用 Cloud Router 的通告路由優先級實作從 Google 到本地的偏好；在主要路徑上設定較低的值。
- 理由：雙向策略確保了確定的方向性：工廠偏好使用主要都會區來連線到雲端，而 Contoso 的 VPC 則偏好使用主要工廠的資料中心來處理回程流量。這避免了非預期的不對稱性。
在 shared VPC 中為 Google API 啟用 Private Service Connect，並建立一個私有 DNS zone 將 API 主機名稱對應到 PSC 端點；設定 Cloud DNS inbound forwarding，以便本地解析器可以私密地解析這些名稱。
- 理由：PSC 提供對 Google API 的私有、VPC 內部存取。混合式 DNS 使得這些端點可以從工廠透過 Interconnect 存取，消除了 ERP 支援服務對網際網路的曝險和對防火牆的依賴。
對於 VPN 備份，在每個區域新增一個 HA VPN gateway，並建立兩個 tunnel 連接到不同的本地設備；在 BGP session 上啟用 BFD 並允許 ECMP。
- 理由：如果 Interconnect 受損，HA VPN 可維持私有連線能力。每個設備的雙 tunnel 維持了 SLA 和吞吐量的連續性，而 BFD 加速了容錯轉移。
對於私有工作負載到網際網路和非 Google 目的地的出口，在 ERP 子網路上設定區域性的 Cloud NAT；不要為 VM 分配外部 IP。
- 理由：Cloud NAT 無需管理 VM 即可擴展轉換規模，並保留私有位址。移除外部 IP 可確保使用 NAT 並簡化出口控制。
透過分階段測試來驗證路由和容錯轉移：拔掉一個 attachment，然後拔掉一個本地路由器，接著模擬線路降級；監控 BGP、BFD 和應用程式的 SLO。如果發生不穩定 (flaps)，則調整 BFD 計時器。
- 理由：受控的故障注入可驗證設計是否符合恢復目標，並防止在生產環境中發生意外。調整計時器可在穩定性和反應速度之間取得平衡。