examlab .net 用最有效率的方法，考取最有價值的證照
支持
本篇導覽 約 21 分鐘

Cloud Router 與 BGP

4,200 字 · 約 21 分鐘閱讀 ·

GCP Professional Cloud Network Engineer 深入解析 Cloud Router 與 BGP：ASN 選擇、MD5 驗證、keepalive 與 hold timer、custom advertisement、MED、BFD、HA VPN、Cloud Interconnect 與 NCC 整合的繁體中文學習筆記。

立即做 20 題練習 → 免費 · 不用註冊 · PCNE

簡介

Cloud Router 是 Google Cloud 全代管服務，使用 RFC 4271 定義的 Border Gateway Protocol (BGP) 在你的 VPC 與外部網路（地端、分公司或其他雲端）之間交換路由。與你手動維護 VPC route table 的靜態路由不同，Cloud Router 會在 TCP/179 BGP session 上動態學習遠端 prefix，並把 VPC 子網域再通告 (re-advertise) 回 peer。當新增子網域、區域離線、或 Interconnect attachment failover 時，Cloud Router 會自動更新 routing table，不需人員介入。

Cloud Router 僅存在於控制平面 (control plane)。實際封包轉送由 Google 的 Andromeda 資料平面執行，所以 Cloud Router 程式本身故障並不會直接讓流量被黑洞——已安裝的路由會繼續運作，直到 BGP hold timer 過期或 peer 撤回路由為止。

白話文解釋（Plain English Explanation）

在拆解 ASN、MED、BFD 之前，三個生活化比喻能幫助你掌握 Cloud Router 究竟在 Google 底層網路上做什麼事。

比喻 1 — GPS 導航系統（靜態路由 vs 動態路由）

靜態路由像一張印刷紙本地圖。你只在地圖上畫一次台北到高雄的高速公路路線，後續就再也不更新。如果濁水溪上的橋斷了，地圖仍然寫「直行」——你的封包就直接開進河裡。Cloud Router 搭配 BGP 則是 Google Maps 加上即時路況。地圖服務每秒和上千輛其他車（其他 BGP speaker）溝通，得知橋斷後就靜靜把你導向台三線。橋修好以後，Maps 注意到國道又通暢就切回去。gcloud compute routers update-bgp-peer 指令並沒有真的搬動封包；它只是告訴導航服務「請優先走這條」——實際的駕駛動作（forwarding）是由 Andromeda 完成。

比喻 2 — 陸上邊界的兩位海關官員（BGP peering session）

一個 BGP session 就是兩位站在陸上邊境兩側的海關官員，隔著柵欄互相喊話交換文件。一位穿著 Google Cloud 制服（Cloud Router，IP 在 169.254.0.1 這類 link-local 上），另一位穿著你地端 router 的制服（169.254.0.2）。他們先確認彼此的員工編號不同（不同的 ASN），再確認暗號正確（MD5 authentication）。每 20 秒互傳一張「我還在」的紙條（keepalive）；如果 60 秒內沒收到紙條，就假設對面被炸了，停止接受那邊送來的文件（hold timer 到期，路由撤回）。BFD 則像額外一支對講機，每 300 毫秒嗶一聲——比海關紙條快得多——所以線路斷掉時兩邊都能在一秒內知道，而不是一分鐘後才發現。

比喻 3 — 長途客運站的多個發車月台（Route Priority 與 MED）

想像一個有四個發車月台（兩個 Cloud Router 與兩個地端 peer 之間共四條 BGP session）的長途客運站。客運站調度員的規則是：BGP route priority 較低者勝（用 --advertised-route-priority=100 設定），所以 priority 100 的月台是主要，priority 200 的月台是備援。從反方向——客運從地端開進總站——地端 router 用 MED (Multi-Exit Discriminator) 對 Cloud Router 低聲說：「請優先選 MED=100 那個月台，而不是 MED=200。」如果兩個月台 priority 與 MED 都一樣，調度員就把乘客分配到兩邊（ECMP，預設最多 4 條 path，可申請放寬到 16 條）。AS Path prepending 則是一種被動式手法：地端 router 把自己的員工編號連寫三次（65001 65001 65001），讓 Cloud Router 以為這條路徑經過三個辦公室、自然就避開它。

Cloud Router 架構與控制平面邊界

Cloud Router 以區域代管資源的形式運作。你用 gcloud compute routers create my-router --region=asia-east1 --network=vpc-prod --asn=64512 建立。建立完成後就附加 BGP peer——每條 VPN tunnel 或 VLAN attachment 配一個 peer。Cloud Router 本身在其區域的多個 zone 上具備高可用；Google 不公開底層 replica 數量，但服務 SLA 假設單一 zone 故障不會讓 router 離線。

控制平面 vs 資料平面

Cloud Router 中的 Control Plane 與 Data Plane — 控制平面是維護 BGP adjacency 並重新計算 routing table 的 BGP speaker 行程；資料平面是 Google 的 Andromeda 虛擬交換 fabric，依照已寫入的路由實際轉送封包。Cloud Router 只佔據控制平面。BGP session reset 會從 data plane 撤回路由，但控制平面軟體升級通常不會造成 forwarding 中斷，因為 Andromeda 在升級期間仍會保留 last-known good 路由。

動態路由模式（VPC 層級設定）

Cloud Router 的行為由 VPC 的動態路由模式控制，用 gcloud compute networks update vpc-prod --bgp-routing-mode=GLOBAL 設定：

  • REGIONAL（預設）：Cloud Router 只通告與自己相同區域的子網域，且學到的路由只對該區域的 VM 可用。
  • GLOBAL：Cloud Router 通告 VPC 中所有區域的子網域，學到的 prefix 安裝到每個區域。任何使用 HA VPN 或 Partner Interconnect 的多區域 production 部署都應該採用此設定。

從 regional 切到 global 不會中斷，但會引發一波重新通告——若你和敏感的電信業者 peer，請排在維護視窗執行。

區域佈署與 HA 模式

每個區域通常至少需要一個 Cloud Router 給 HA VPN（HA VPN gateway 本身有兩個 interface），以及第二個 Cloud Router 給冗餘的 Interconnect attachment。標準 HA 模式是：兩條 HA VPN tunnel 終接於同一個 Cloud Router 的兩個 interface，並與兩個不同電力與冷卻網域的地端 router peer。雙 tunnel 上線且雙 BGP session 都已建立、且 prefix 不重疊時，可達 99.99% SLA。

ASN 選擇：私有範圍與 4-byte ASN

每個 BGP session 都需要兩個相異 ASN。Cloud Router 同時支援 2-byte ASN（RFC 4893 私有範圍 64512-65534）與 4-byte ASN（4200000000-4294967294，RFC 6996）。Public ASN（不在上述私有範圍、也不在 23456 等保留區的編號）API 接受，但建議只在你向 ARIN、APNIC 等 RIR 註冊持有的 ASN 才使用。

選擇 2-byte 還是 4-byte ASN

  • 2-byte 私有 ASN：適合地端網路規模小、過去沒有 ASN 配置的情境。64512 與 65000 是常見起點。
  • 4-byte 私有 ASN：適合企業 WAN 已經用 64512-65534 配給分公司、雲端需要另一段不衝突範圍的情境。4200000000 是典型錨點。
  • 絕對不要兩邊用同一個 ASN。 BGP 對 eBGP session 要求兩端 ASN 相異，若 peer-asn 等於 router 自己的 --asn，Cloud Router 會拒絕該 peering 嘗試。

ASN 唯一性以 peer 為單位執行：Cloud Router 自己的 ASN 在建立時設定且不可變更。Peer ASN 在每個 BGP peer 用 --peer-asn 設定。若你從同一台地端裝置接兩條 HA VPN tunnel，兩個 peer 必須使用同一個 peer ASN；若從兩台不同地端裝置接 tunnel，每個 peer 可以有各自的 ASN——但那兩台地端裝置之間的 iBGP 就變成你的責任，不是 Google 的。

應避開的保留 ASN

  • 0 與 65535 由 RFC 保留。
  • 23456 是 4-byte ASN 對 2-byte speaker 通告時的轉接 ASN——絕對不要直接拿來用。
  • 65534 過去是部分 Google Cloud 文件範例的預設值；為了避免共用環境中產生混淆，請改用其他編號。

MD5 驗證與 BGP 安全性

Cloud Router 在每個 BGP session 都支援 RFC 2385 MD5 authentication。雖然 MD5 以現代密碼學標準來看相對脆弱，它仍是 BGP 業界標準，並能有效提高針對 off-path TCP 注入的攻擊門檻，特別是 Interconnect attachment 上鏈路與電信業者其他租戶共用的情境。

在 peer 上啟用 MD5

gcloud compute routers add-bgp-peer my-router \
  --peer-name=peer-onprem-east-1 \
  --interface=interface-0 \
  --peer-ip-address=169.254.0.2 \
  --peer-asn=65001 \
  --md5-authentication-key="redacted-shared-secret-32-chars"

金鑰存放於 Google 加密的 metadata store，建立後無法透過 API 以明文取回。輪替需要用 gcloud compute routers update-bgp-peer 設定新金鑰；變更期間 BGP session 會短暫 flap。

盡可能搭配地端 peer 的 GTSM (Generalized TTL Security Mechanism)：GTSM 要求所有 BGP 封包到達時 TTL=255，意即必須由直接相連的 neighbor 發出。Cloud Router 本身不曝露 TTL 設定，但在多數電信 Interconnect 部署中 peer 只隔一跳，所以在地端啟用 GTSM 可作為縱深防禦。

金鑰長度與輪替

使用 20 字元以上的隨機金鑰——Google 沒有強制最小長度，但多數安全基線要求至少 16。每當具有存取權的網路工程師離職時就要輪替；請把 BGP MD5 金鑰視為等同於服務帳戶金鑰的共享密鑰。

Keepalive 與 Hold Timer

掌管 BGP session 存活的兩個計時器在 session 建立時協商——兩邊各自提出值，最終採用較小者。

預設值與調校

  • Keepalive：Cloud Router 預設 20 秒。API 接受範圍為 20-60。
  • Hold timer：預設 60 秒（依 RFC 4271 建議為 keepalive 的 3 倍）。4-byte ASN session 接受範圍為 6-60，但 Cloud Router 強制最小 hold 為 20。

設定方式：

gcloud compute routers update-bgp-peer my-router \
  --peer-name=peer-onprem-east-1 \
  --advertised-route-priority=100 \
  --keepalive-interval=20

注意 Cloud Router 沒有獨立的 --hold-time 旗標；hold time 由 keepalive 的 3 倍推導而來，上限 60 秒。若要達成次秒級故障偵測，請使用 BFD，而不是調激進的 BGP timer。

把 keepalive 設成 60 想「節省 peering session 的頻寬」會讓 peer 失效偵測拖到 180 秒。這三分鐘內封包會被靜默黑洞，因為 data plane 仍把死掉的 next-hop 安裝著。任何 production HA VPN 都應該保留預設 20，或啟用 BFD。

Custom Route Advertisement（自訂路由通告）

Cloud Router 預設會通告相關範圍內的所有 VPC 子網域（依動態路由模式決定 regional 或 global）。對多數企業部署這太多了——你會想要通告一個 summary range、隱藏只給內部用的子網域、或通告非任何子網域的外部靜態路由（例如以 Private Service Connect 存取 Google 受管服務的範圍）。

Default 模式 vs Custom 模式

  • Default 模式：通告 router 看得到的所有子網域。
  • Custom 模式：只通告你列出的內容，可選擇是否加上預設子網域集合。

切換方式 --advertisement-mode=CUSTOM：

gcloud compute routers update-bgp-peer my-router \
  --peer-name=peer-onprem-east-1 \
  --advertisement-mode=CUSTOM \
  --set-advertisement-ranges=10.100.0.0/16,10.101.0.0/16 \
  --set-advertisement-groups=ALL_SUBNETS

通告非 VPC 子網域的 prefix

Custom advertisement 可以包含完全不是 VPC 子網域的 prefix——例如讓地端存取 private.googleapis.com 用的 199.36.153.4/30，或 IAP TCP forwarding 用的 35.199.192.0/19。這就是地端主機學會把 Google API 流量導向 HA VPN tunnel 而非公網的方式。

摘要與過濾

Cloud Router 不會做自動摘要。若你分別通告 10.0.0.0/16 與 10.1.0.0/16，peer 會看到兩條路由。請手動通告 supernet 10.0.0.0/15 並在地端 router 設定只接受該 supernet。

Per-peer 通告 vs Per-router 通告：Cloud Router 兩者都有。Router 層級的 custom advertisement 套用到每個 peer；peer 層級的 custom advertisement 會覆蓋該 session 的 router 設定。需要某個地端站點只看到 VPC 子集（例如 DMZ 合作夥伴只看到 10.200.0.0/16 的合作夥伴範圍，而不是內部 10.0.0.0/8）時，就用 peer 層級覆寫。

Route Priority 與 MED

Cloud Router 的 BGP route selection 遵循標準 BGP best-path 演算法，並有兩個 Google 特定行為。

入站方向：通告的 route priority

Cloud Router peer 的 --advertised-route-priority 旗標會以 BGP MED 屬性 送給地端 peer。值越低越優先。可用此設定一條 tunnel 為主、另一條備援：

# 主要 tunnel
gcloud compute routers update-bgp-peer my-router \
  --peer-name=peer-onprem-tunnel-a --advertised-route-priority=100

# 備援 tunnel
gcloud compute routers update-bgp-peer my-router \
  --peer-name=peer-onprem-tunnel-b --advertised-route-priority=200

地端 router 現在會優先選 tunnel A 作為回程流量。若 A 故障，BGP 撤回路由，B（priority 200）接管。

出站方向：來自 peer 的 inbound MED

對稱地，地端 router 通告 prefix 給 Cloud Router 時會在每條路由上設定 MED。Cloud Router 接受 MED 並把 MED 較低的路由安裝為實際 forwarding entry。若地端送來的 MED 相同，Cloud Router 退回 AS path length 比較，最後以 router ID 作為決勝。

同 priority 時的 ECMP

兩條 path priority/MED 相等、AS path length 相等、origin code 也相等時，Cloud Router 預設啟用 ECMP（Equal-Cost Multi-Path），最多 4 條 path。Hash 是 5-tuple（src-ip、dst-ip、src-port、dst-port、protocol），所以每個 flow 黏在單一 path 上，但不同 flow 會分散到不同 tunnel。

Local route 永遠勝過 learned route。 若你從地端通告 10.10.0.0/16，但 VPC 有一個子網域 10.10.0.0/24，VPC 內的 VM 會把 10.10.0.5 路由到本地子網域，而不是經過 VPN。這是 RFC 4271 local preference 的設計，無旗標可覆寫——必須重新規劃 IP plan。

BFD（Bidirectional Forwarding Detection）

BGP timer 偵測故障需要數十秒。對延遲敏感的應用——語音、即時交易、同步資料庫複製——這太慢了。BFD (RFC 5880) 在 BGP 旁邊執行，透過在 UDP port 3784 上傳送輕量探測封包，在次秒等級偵測 path 故障。

Cloud Router BFD 參數

  • Mode：ACTIVE（Cloud Router 主動發起）或 PASSIVE（等候 peer 發起）。
  • min-transmit-interval：Cloud Router 發 BFD 封包的頻率。範圍 1000-30000 微秒（1ms-30s），預設依 attachment 類型而定。
  • min-receive-interval：Cloud Router 從 peer 接受的最小 interval。範圍同上。
  • multiplier：宣告 session down 之前允許連續遺失的封包數。範圍 5-10，預設 5。

當 transmit=300000us (300ms)、multiplier=5 時，故障偵測約為 1.5 秒——比預設 BGP hold timer 快約 40 倍。

gcloud compute routers update-bgp-peer my-router \
  --peer-name=peer-onprem-east-1 \
  --bfd-session-initialization-mode=ACTIVE \
  --bfd-min-transmit-interval=300 \
  --bfd-min-receive-interval=300 \
  --bfd-multiplier=5

BFD 何時值得導入

  • Dedicated Interconnect：高價值、延遲敏感——建議啟用 BFD。
  • 走高品質網際網路的 HA VPN：BFD 有幫助但較不關鍵，因為底層 IPsec tunnel 本身有 heartbeat。
  • Partner Interconnect：視電信業者而定；部分業者不支援端到端 BFD。

Cloud Router 在 HA VPN、Interconnect、跨 VPC 的角色

Cloud Router 是 Google 提供的所有動態路由 attachment 的 BGP 端點。Peer 類型不同，但 router 本身就是同一個代管服務。

HA VPN

HA VPN gateway 有兩個 interface（0 與 1），每個 interface 終接一條 tunnel。同一個 gateway 的兩條 tunnel 必須與同一個 Cloud Router peer，才能拿到 99.99% SLA。若要更高層級的地理冗餘，可在第二個區域佈署第二個 HA VPN gateway 搭配自己的 Cloud Router，並用 BGP route priority 控制主要區域。

Dedicated 與 Partner Interconnect

每個 VLAN attachment 只能綁定一個 Cloud Router。Cloud Router 透過 Google 從 169.254.0.0/16 配置的 link-local 位址在 layer-2 attachment 上跑 BGP session。你不能自己指定 attachment 的 BGP IP——Google 會挑選相鄰的兩個 /29 位址。

Cross-Cloud Interconnect

Cloud Router 可與遠端雲的 BGP speaker peer（AWS Direct Connect VIF、Azure ExpressRoute Microsoft peering、OCI FastConnect）。此時 ASN 選擇變得關鍵，因為每個雲端都保留某些私有 ASN 範圍給自家使用——請挑一個遠離所有雲端業者保留範圍的 4-byte ASN。

Cloud Router 與 VPC Peering 不相容

Cloud Router 不會在 VPC Peering 上通告路由。VPC Peering 直接透過 Google 控制平面交換子網域路由，與 BGP 無關。若要在三個 VPC 之間做傳遞性路由，請使用 Network Connectivity Center，而不是串接 peering。

Network Connectivity Center (NCC) 整合

Network Connectivity Center (NCC) 為 Google 網路連線引入輻射狀 (hub-and-spoke) 抽象。Cloud Router 在掛上 HA VPN、Interconnect 或 Router Appliance spoke 時，會以 spoke 的身分參與其中。

Hub、Spoke 與路由交換

Hub 是區域或全域的容器，會在 spoke 之間重新通告路由。每個 spoke 為以下之一：

  • HA VPN spoke：一對 HA VPN tunnel。
  • VLAN attachment spoke：一個 Interconnect VLAN。
  • Router appliance spoke：第三方 NVA（例如 Palo Alto 或 Cisco VM）以 BGP peer 形式設定。
  • VPC spoke：一個 VPC 網路（目前限定特定 NCC 模式）。

Cloud Router 在每個非 VPC spoke 上擔任 BGP speaker。把一條 tunnel 加入 hub 時，hub 會自動學到 Cloud Router 通告的 prefix 並再散佈到其他 spoke——讓 Google 網路變成傳遞性 WAN backbone，你不必自己跑 iBGP。

使用場景

  • 分公司之間經 Google 互通：每個分公司用 HA VPN 接到 Google，NCC 串起來。
  • 插入虛擬防火牆：用 router-appliance spoke 跑 NVA，NCC 把 east-west 流量導過去。
  • 取代 MPLS：NCC 加 Premium Tier 可在 Google backbone 上提供多數 MPLS 等級的行為。

路由傳播與 BGP Dampening

路由如何在 VPC 內傳播

Cloud Router 上學到的 BGP route 會變成 VPC route table 中的動態路由 (dynamic route)，可用 gcloud compute routes list --filter="nextHop:projects/.../routers/my-router" 看到。動態路由優先級高於隱含預設，但低於 custom 靜態路由（預設 priority 1000）。它們會傳播到相關區域內的每台 VM（regional 模式），或每個區域（global 模式）。

路由傳播延遲

收到 BGP UPDATE 後，Cloud Router 通常會在幾秒內把路由寫入 data plane。傳播時間沒有公開 SLA，但實務經驗顯示，學到的路由要在整個 global VPC 變成 forwarding 有效大約需要 5-30 秒。

BGP Dampening

Cloud Router 不實作 BGP route flap dampening。 RFC 2439 dampening 是為了 full-internet table BGP speaker 而存在；在私有企業 BGP 中很少有用，Google 也刻意省略。若你遇到鏈路 flap，請處理根因（線路、光模組、IPsec rekey storm），而不是調 dampening——根本沒有東西可以調。

若地端 peer 實作了 dampening 並抑制了你的 VPC 路由，症狀會是「每次 BGP flap 後所有 VM 失去對地端的連線約 15 分鐘」。請在地端關閉對 cloud peer 的 dampening，或把 Cloud Router 通告的 prefix 加入 dampening 白名單。

監控、Logging 與疑難排解

Cloud Logging

透過 gcloud compute routers update my-router --set-advertisement-mode=... 啟用 BGP session 狀態 logging（logging 透過 API 欄位 bgpPeers[].enable 以 per-router 方式控制）。BGP UPDATE 訊息會流向 Cloud Logging，資源類型為 cloud.googleapis.com/router_logs。

Cloud Monitoring 指標

關鍵指標：

  • router.googleapis.com/bgp/session_up：建立中為 1，斷線為 0。
  • router.googleapis.com/bgp/sent_routes_count 與 received_routes_count：若意外掉到 0 就告警。
  • router.googleapis.com/bfd/session_up：與 BGP 分開——兩者都應為 1。

設定 alert policy：session_up 為 0 超過 60 秒就觸發；忽略對應到正常 IPsec rekey 的短暫飄移。

Connectivity Tests

使用 Connectivity Tests（前 Network Intelligence Center 元件）驗證指定 source/destination 是否真的會經過預期的 Cloud Router。Test 模擬 forwarding 而不送真實封包，會列出每個路由 hop，包括哪個 Cloud Router 寫入哪條路由。

考試陷阱、提示與最佳實踐

  • 陷阱：Cloud Router 是區域性的。若動態路由模式為 REGIONAL 且 router 放在 us-central1，europe-west1 的 VM 看不到學到的路由——任何跨區域 production 都要切到 GLOBAL。
  • 陷阱：不能在 VPC Peering 上跑 BGP。考試會把這個拿來當干擾選項。要用 NCC。
  • 提示：要拿 HA VPN 99.99% SLA，兩條 tunnel 必須終接於同一個 Cloud Router 且兩邊 BGP 都已建立。兩個 router 只有在搭配兩個 gateway 時才能達到 99.99%。
  • 提示：用 gcloud compute routers get-status my-router --region=... 看 BGP peer 即時狀態以及學到/通告的 prefix 數——這是最快的疑難排解指令。
  • 最佳實踐：把每個 ASN 都記錄在共用清單。併購情境下的 ASN 衝突是多日 BGP 中斷最常見的單一原因。

常見問題（FAQs）

問：如果我有兩條 MED 與 AS-path length 都相同的 BGP path 會怎樣？

答：Cloud Router 會在最多 4 條 path 上執行 ECMP 負載分散，使用 5-tuple hash，每個 flow 會黏在單一 path。可申請配額提高到最多 16 條 ECMP path。

問：可以在 VPC Peering 上跑 BGP 嗎？

答：不行。VPC Peering 透過 Google 內部控制平面交換路由，並非 BGP。VPC 之間若需要傳遞性路由，請改用 Network Connectivity Center，讓 Cloud Router 以 spoke 形式參與並把 VPC 串起來。

問：Cloud Router 建立後可以改 ASN 嗎？

答：不行。ASN 在 router 建立時設定且不可變更。要更改的話必須建立新的 Cloud Router 並指定目標 ASN，然後逐一遷移 BGP peer（要在維護視窗，因為每次遷移會 flap 一次 session），最後刪除舊 router。

問：Cloud Router 本身要收費嗎？

答：Cloud Router 代管服務本身免費。費用發生在底層 attachment——HA VPN tunnel-hours、Interconnect port 與 attachment 費、egress 流量。沒有 per-route、per-prefix、per-BGP-session 費用。

問：Cloud Router 本身有 SLA 嗎？

答：Cloud Router 的可用性納入它所服務的 attachment SLA：HA VPN 雙 tunnel 上線時為 99.99%，Dedicated Interconnect 視拓樸為 99.9% 或 99.99%，Partner Interconnect 為 99.9%。沒有獨立的 Cloud Router SLA。

問：Cloud Router 能在同一條 tunnel 上和多個地端 router peer 嗎？

答：不行——每條 tunnel 或 VLAN attachment 只能有一個 BGP session、每個 session 只能有一個 peer。若需要多個地端 peer，請建立多條 tunnel 或多個 VLAN attachment，每個都各自有 Cloud Router BGP peer 條目。

問：BFD 故障偵測在實務上多快？

答：在 min-transmit-interval=300ms、multiplier=5 設定下，故障偵測約 1.5 秒。更激進的設定（min-transmit-interval=100ms、multiplier=3）可以壓到 300 毫秒，但在雜訊鏈路上有 false positive 風險。

官方資料來源

更多 PCNE 主題