疑難排解

這份疑難排解指南可協助您解決使用 Cloud Interconnect 時可能遇到的常見問題:

如需 Cloud Interconnect 架構和功能的常見問題解答,請參閱「Cloud Interconnect 常見問題」。

如需本頁面所用詞彙的定義,請參閱「Cloud Interconnect 重要詞彙」。

如要查看記錄和監控資訊,以及 Cloud Interconnect 指標,請參閱「監控連線」。

一般疑難排解

查看 Cloud Interconnect 服務中斷情形

無法連線至其他地區中的資源

根據預設,虛擬私有雲 (VPC) 網路屬於區域性,也就是說,Cloud Router 只會 advertise 所在區域的子網路。如要連線至其他區域,請將虛擬私有雲網路的動態轉送模式設為全域,讓 Cloud Router advertise 所有子網路。

詳情請參閱 Cloud Router 說明文件的「動態轉送模式」一節。

無法連線至對接虛擬私有雲網路中的 VM

在這個情境中,您已在地端部署網路和虛擬私有雲網路「網路 A」之間設定 Cloud Interconnect 連線。您也已在網路 A 和另一個虛擬私有雲網路 (網路 B) 之間設定虛擬私有雲網路對接。不過,您無法從地端部署網路連至網路 B 中的 VM。

如虛擬私有雲網路對接總覽的限制所述,系統不支援這項設定。

不過,您可以使用虛擬私有雲網路中 Cloud Router 的自訂 IP 範圍 advertisement,與對接網路中的目的地共用路由。此外,您必須設定虛擬私有雲網路對等互連連線,才能匯入及匯出自訂路徑。

如要進一步瞭解如何在地端部署網路和虛擬私有雲對接網路之間 advertising 路由,請參閱下列資源:

連線中缺少子網路

如要 advertise 所有可用的子網路,請使用自訂 advertise 路由指定缺少的路由,並透過全域動態轉送,在區域之間 advertise 所有子網路路由。詳細步驟如下:

  1. 在 Cloud Router 和邊界閘道通訊協定 (BGP) 工作階段中,指定自訂 advertise 路由。

    如要輸入缺少的路徑,請設定下列參數:

    --set-advertisement-groups = ADVERTISED_GROUPS
    --set-advertisement-ranges = ADVERTISED_IP_RANGES
    

    更改下列內容:

    • ADVERTISED_GROUPS:Google 定義的群組,Cloud Router 會動態 advertise 這個群組;這個群組的值可以是 all_subnets,模擬 Cloud Router 的預設行為
    • ADVERTISED_IP_RANGES:新 IP 位址範圍陣列的內容,可包含一或多個您選擇的值

    如需更多詳細資料和範例,請參閱「advertise 自訂 IP 範圍」。

  2. 啟用全域動態轉送模式。

無法對 Cloud Router 進行連線偵測 (ping)

如果無法從地端部署路由器連線偵測 (ping) Cloud Router,請在下表中找到您的產品,並執行該產品的疑難排解步驟。VM 無法連線至 169.254.0.0/16。

疑難排解步驟 Dedicated Interconnect 與 L3 合作夥伴建立 Partner Interconnect 與 L2 合作夥伴建立 Partner Interconnect
如果是 Partner Interconnect,Cloud Router 可能永遠無法連線,因為部分合作夥伴會篩選傳送至 Cloud Router IP 範圍 (169.254.0.0/16) 的流量。如果是 L3 合作夥伴,合作夥伴會自動設定 BGP。如果 BGP 未啟動,請與合作夥伴聯絡。 不適用 是 不適用
確認本機裝置已取得連線 Google Cloud 端的正確 MAC 位址。詳情請參閱「排解 ARP 問題」。 是 不適用 不適用
確認 Cloud Router 具有介面和 BGP 對接。除非介面和 BGP 對等互連已完整設定 (包括遠端 ASN),否則無法對 Cloud Router 執行連線偵測 (ping)。
  • 如果是 Dedicated Interconnect,請參閱「BGP 工作階段無法運作」。
  • 如果是 L2 Partner Interconnect,Google 已自動為 Cloud Router 新增介面和 BGP 對等互連,但您必須設定遠端 ASN。
是 不適用 是

疑難排解 ARP

如為 Dedicated Interconnect,請執行下列 gcloud 指令,找出正確的 MAC 位址:

  gcloud compute interconnects get-diagnostics INTERCONNECT_NAME

裝置具有「指派給 Cloud Router 之 IP 位址」的 ARP 資料表,該資料表中應存在的 MAC 位址會包含在 googleSystemID 中。

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

如果裝置未學習 MAC 位址,請確認子介面已設定正確的 VLAN ID 和 IP 位址。

如果是 Partner Interconnect,當裝置顯示錯誤的 MAC 位址時,請確認您未橋接兩個 VLAN 連結的第 2 層區段。Cloud Interconnect 連線的 Google Cloud 端設定了 ip proxy-arp,會回覆所有 ARP 要求,可能導致地端部署路由器取得不正確的 ARP 項目。

無法建立 VLAN 連結

如果您嘗試為 Dedicated Interconnect 或 Partner Interconnect 建立 VLAN 連結,但違反組織政策,就會看到錯誤訊息。請參閱下列執行 gcloud compute interconnects attachments partner create 後出現的錯誤訊息範例:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

詳情請參閱「限制 Cloud Interconnect 的使用」和「使用自訂組織政策」,並與組織管理員聯絡。

與我所屬組織中的其他專案共用連線

使用 Shared VPC 共用連線,例如主專案中的 VLAN 連結或 Dedicated Interconnect 連線。

如要進一步瞭解如何設定 Shared VPC 虛擬私有雲網路,請參閱「佈建 Shared VPC」。

如要進一步瞭解如何在 Shared VPC 網路中設定連結,請參閱「連線至多個虛擬私有雲網路的選項」。

Dedicated Interconnect

Google 無法在連線佈建程序中對您執行連線偵測 (ping)

請確認您使用的是正確的 IP 和 LACP 設定。在測試過程中,Google 會根據您訂購的是多連結套件還是單一連結套件,為地端部署路由器傳送不同的測試 IP 設定。請勿為這兩項測試設定 VLAN 連結。

  • Google 傳送的第一組 IP 位址,用於測試各個連結的多線路連線能力。請按照 Google 傳送給您的電子郵件中的指示,在每個實體連結上設定測試 IP 位址 (未設定 LACP)。Google 必須成功連線至所有 IP 位址,才能通過這項測試。
  • 進行第二次測試時,請移除第一次測試的所有 IP 位址。即使連線只有一個連結,也請使用 LACP 設定通訊埠通道。Google 會對通訊埠通道位址進行連線偵測 (ping)。連線通過最終測試後,請勿修改通訊埠通道的 LACP 設定。不過,您必須從通訊埠通道介面中移除測試 IP 位址。
  • Google 會傳送最終正式版 IP 位址,用於測試單一線路連線。按照 Google 傳送的電子郵件指示,在套件介面上設定 IP 位址 (已設定 LACP,主動或被動模式)。Google 必須成功連線至套裝組合介面 IP 位址,這項測試才會通過。即使連線只有一個連結,也請使用 LACP 設定通訊埠通道。

無法對 Cloud Router 進行連線偵測 (ping)

  • 請檢查您是否可以對 Google 的通訊埠通道 IP 位址進行連線偵測 (ping)。查看連線詳細資料時,IP 位址會顯示為 googleIpAddress 值。
  • 檢查您的內部部署路由器的子介面上是否有正確的 VLAN。該 VLAN 資訊應與 VLAN 連結提供的資訊相符。
  • 檢查您的內部部署路由器的子介面上是否有正確的 IP 位址。建立 VLAN 連結時,系統會分配一組連結本機 IP 位址。一個用於 Cloud Router 上的介面 (cloudRouterIpAddress),另一個用於地端部署路由器通訊埠通道上的子介面,而非通訊埠通道本身 (customerRouterIpAddress)。
  • 測試 VLAN 連結的效能時,請勿對 Cloud Router 執行連線偵測 (ping)。請改為在虛擬私有雲網路中建立並使用 Compute Engine 虛擬機器 (VM) 執行個體。詳情請參閱效能測試說明。

BGP 工作階段無法運作

  • 在具有至少兩個躍點的內部部署路由器上啟用多重躍點 BGP。
  • 檢查您的內部部署路由器上是否已設定正確的相鄰 IP 位址。使用 VLAN 連結分配的 BGP 對等互連 IP 位址 (cloudRouterIpAddress)。
  • 確認地端部署路由器上的本機 ASN 設定與 Cloud Router 上的對等互連 ASN 相符。此外,請確認 Cloud Router 上的本機 ASN 設定與地端部署路由器上的對等互連 ASN 相符。
  • 每個連結都會從虛擬私有雲網路中的 169.254.0.0/16,分配到專屬的 /29 CIDR。/29 CIDR 中的一個 IP 位址會分配給 Cloud Router,另一個則分配給地端部署路由器。

    確認地端部署路由器介面及其 BGP 鄰居已分配正確的 IP 位址。常見的錯誤是在地端部署路由器介面上設定 /30,而非 /29。 Google Cloud 會保留 /29 CIDR 中的所有其他位址。

    請確認您未將這個 CIDR 的任何其他 IP 位址分配給路由器上的 VLAN 連結介面。

無法連線至虛擬私有雲網路中的 VM

  • 檢查您是否可以對通訊埠通道和 VLAN 連結進行連線偵測 (ping)。
  • 檢查您的 BGP 工作階段是否處於啟用狀態。
  • 檢查地端部署路由器是否正在 advertise 及接收路由。
  • 確認地端部署路由 advertisement 與 Google Cloud 網路範圍沒有重疊。
  • 將地端部署路由器、虛擬私有雲和 VLAN 連結的 MTU 大小設為相同的值。

IPv6 流量未通過 VLAN 連結

如果無法順利連線至 IPv6 主機,請按照下列步驟操作:

  1. 確認 IPv6 路由已正確 advertise。如果未 advertise IPv6 路由,請參閱「排解 BGP 路由和路由選擇問題」。
  2. 檢查防火牆規則,確保允許 IPv6 流量。
  3. 確認虛擬私有雲網路和地端部署網路中的 IPv6 子網路範圍沒有重疊。請參閱「檢查重疊的子網路範圍」。
  4. 判斷您是否已超過 Cloud Router 中 learned 路由的任何配額和限制。如果超過已知路徑的配額,系統會先捨棄 IPv6 前置字元,再捨棄 IPv4 前置字元。請參閱「查看配額和限制」。
  5. 確認與 IPv6 設定相關的所有元件均已正確設定。

    • 虛擬私有雲網路已啟用 --enable-ula-internal-ipv6 旗標,可使用內部 IPv6 位址。
    • 虛擬私有雲子網路已設為使用 IPV4_IPV6 堆疊類型。
    • 虛擬私有雲子網路的 --ipv6-access-type 設為 INTERNAL。
    • 子網路上的 Compute Engine VM 已設定 IPv6 位址。
    • VLAN 連結已設為使用 IPV4_IPV6 堆疊類型。
    • BGP 對等互連已啟用 IPv6,且 BGP 工作階段已設定正確的 IPv6 下一個躍點位址。

測試 VLAN 連結的效能

如要測試 VLAN 連結的效能,請使用虛擬私有雲網路中的 VM。在 VM 上新增所需的效能工具。請勿使用 Cloud Router 連結本機 IP 位址測試延遲時間,例如 ICMP ping 或路徑 MTU。使用 Cloud Router 可能會產生無法預測的結果。

取得診斷資訊

如要視需要取得 Dedicated Interconnect 連線 Google Cloud 端的最新詳細技術資訊,請參閱「取得診斷資訊」。

授權書 (LOA) 相關問題

以下子節說明授權書相關問題。

訂單確認後 3 個工作天內未收到授權書

請檢查電子郵件的垃圾郵件資料夾。如果還是找不到授權書,請回覆 order_received 電子郵件,向 Cloud Customer Care 尋求協助。

主機代管供應商需要釐清授權書詳細資料

擔任供應商與 Google 之間的聯絡人。請回覆電子郵件通知,並附上供應商的具體問題,Cloud Customer Care 即可協助您釐清細節。

交叉連接安裝不正確

連線必須完全按照最新授權書中的規定建立,任何偏差都會導致連線失敗。通常,因偏離 LOA 而導致的設定問題會傳回「未偵測到光」錯誤。詳情請參閱「收到『未偵測到光線』錯誤」一節。

收到「未偵測到光線」錯誤

如果收到「未偵測到光」錯誤,表示 Google 的自動化測試未從地端部署路由器的一或多個通訊埠偵測到足夠的光。這表示實體層 (第 1 層) 有問題。請按照下列步驟排解問題:

  1. 驗證交叉連接安裝作業:請與主機代管供應商聯絡,並確認下列事項:

    • 交叉連結安裝作業已完成。
    • 連線會遵循 Google 劃分側最新版本 LOA 中指定的通訊埠。
    • 供應商會提供測試結果,包括在 Google 分界點使用光功率計朝向您的設備測得的光線強度讀數。
  2. 檢查實體基礎架構:檢查下列元件:

    • 請確認光纖跳接線類型正確,且已牢牢連接至路由器的通訊埠,以及機架內的所有中繼跳接面板。檢查電線是否有任何損壞、急彎或扭結。
    • 檢查收發器 (例如 SFP 和 QSFP):
      • 確認收發器型號與路由器和您訂購的 Dedicated Interconnect 速度相容。
      • 確認收發器已牢牢插入路由器通訊埠。
      • 請嘗試重新安裝收發器。如有備用收發器,可以嘗試更換。
    • 檢查路由器上的實體通訊埠 LED 燈。如果偵測到訊號,連結燈應該會亮起 (通常是綠色)。如果沒有亮燈或亮起琥珀色燈,通常表示有問題。
    • 請使用適當的光纖清潔工具 (例如清潔筆),清潔光纖纜線末端和收發器光學介面。灰塵和汙染物是造成訊號遺失的常見原因。
  3. 檢查路由器通訊埠的設定:確認路由器上的介面已由管理員啟用。不得處於「shutdown」狀態。請根據路由器使用下列指令檢查狀態:

    • Cisco IOS/NX-OS:使用 show interface [interface] 指令。如果顯示「administratively down」,請進入介面設定模式,並使用 no shutdown 指令。
    • Juniper Junos:使用 show interfaces [interface] 指令。「Admin link」(管理員連結) 應為「Up」(啟用)。如有需要,您可以在設定模式中使用 set interfaces [interface] enable 指令啟用這項功能。
    • Arista EOS:使用 show interface [interface] status 指令。如果顯示「disabled」,請進入介面設定模式,並使用 no shutdown 指令。
  4. 分析路由器的光功率:存取路由器的 CLI,檢查光傳輸 (TX) 和接收 (RX) 功率。您可以根據路由器製造商,使用下列範例指令檢查功率等級:

    • Cisco:show interface [interface] transceiver details
    • Juniper:show interfaces diagnostics optics [interface]
    • Arista:show interface [interface] transceiver dom

    使用指令後,請按照下列指引解讀資訊:

    • TX Power:這是路由器傳輸的功率。應在收發器的規格範圍內 (標準 LR 光學元件通常為 -5 至 +2 dBm)。如果 TX 功率非常低,表示您那端的光纖或通訊埠可能有問題。
    • RX Power:這是路由器從 Google 端接收的功率。請使用下列功率範圍評估連結品質:
      • 良好:介於 -1 dBm 和 -10 dBm 之間。
      • 邊緣:介於 -10 dBm 和 -14 dBm 之間。連結可能不穩定。
      • 無訊號:低於 -15 dBm,通常顯示為 -30 dBm、-40 dBm 或「低」,表示幾乎或完全沒有接收到光。這表示實體線路可能中斷、連接錯誤或極性有問題。
  5. 測試光纖極性:光纖連線需要「交叉」。路由器的 transmit 光纖必須連接 Google 分界點的 receive 光纖,而 Google 分界點的 transmit 光纖必須連接路由器的 receive 光纖。

    如要解決極性問題,請在路由器或跳接面板上,小心「捲動」光纖連接器,交換雙工連接器中兩條光纖的位置。如果連結燈亮起,或 RX 訊號強度大幅提升,表示極性問題已解決。

  6. 執行回送測試:您可以執行本機和遠端回送測試,找出連線問題發生在哪一端:

    • 本機回送:在路由器通訊埠上使用實體光纖回送插頭。這會將路由器的 TX 訊號導回其 RX 連接埠。如果通訊埠狀態變更為「up」,表示路由器通訊埠和收發器可能正常運作。
    • 遠端回送 (與供應商合作):要求主機代管供應商在 Google 分界點的光纖上,朝向您的設備放置實體回送。如果路由器通訊埠出現,表示從路由器到 Google 分界點的路徑正常,問題可能出在 Google 分界點。
  7. 檢查診斷:您可以使用下列指令,從 Google 的連線端取得診斷資訊:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
       --project=PROJECT_ID
    

    更改下列內容:

    • INTERCONNECT_NAME:您為 Dedicated Interconnect 連線指派的不重複名稱。
    • PROJECT_ID:專案 ID。

    在輸出內容中,檢查連結陣列中每個連結的 receivingOpticalPower 和 transmittingOpticalPower 值。這些值代表 Google 設備偵測到的內容。 比較 Google 的 RX 功率與路由器的 TX 功率,以及 Google 的 TX 功率與路由器的 RX 功率,並考量光纖造成的訊號損失。

  8. 收集資訊並提供給客戶服務團隊:如果您已嘗試上述步驟,但問題仍未解決,建議您回覆訂單電子郵件,並提供下列資訊:

    • 主機代管供應商確認已依據最新授權書安裝交叉連接。
    • 供應商提供的任何測試結果 (例如分界點的光度計讀數)。
    • 路由器上相關介面的完整設定。
    • 路由器光線等級診斷指令的完整輸出內容 (例如 show interface transceiver details 的輸出內容)。
    • gcloud compute interconnects get-diagnostics 的完整 JSON 輸出內容。
    • 任何極性交換或回送測試的詳細結果。
    • 路由器記錄針對介面回報的任何警示或錯誤。

LACP 設定無法運作

請按照本節中的步驟,檢查鏈路聚合控制通訊協定 (LACP) 繫結設定是否有問題。

  1. 驗證路由器上的 LACP 設定:檢查路由器上的下列 LACP 設定:

    • Dedicated Interconnect 連線的所有實體介面,都必須綁定至單一連結匯總群組 (LAG)。
    • 路由器的 LACP 必須設為「ACTIVE」模式。Google 採用 LACP 主動模式。如果將您這端設為 PASSIVE 模式,LACP 組合就無法形成。
    • 將 LACP 計時器設為「FAST (1 second)」(快速 (1 秒)),或在裝置上設定對等的值。計時器速度過慢 (30 秒) 可能會延遲套件形成,導致自動化測試失敗。
    • 視路由器而定,使用下列指令或指令組合設定成員通訊埠:
      • Cisco:interface [interface],之後channel-group [number] mode active
      • Juniper:set interfaces [interface] gigether-options 802.3ad ae[number]
      • Arista:interface [interface],然後 channel-group [number] mode active
    • 如果您使用 Juniper 路由器,請使用下列指令執行 LAG 介面設定:set interfaces ae[number] aggregated-ether-options lacp active,,然後 set interfaces ae[number] aggregated-ether-options lacp periodic fast。
  2. 分析 LACP 狀態:視路由器製造商而定,使用下列指令或指令組合,檢查路由器的 LACP 狀態:

    • Cisco:show lacp neighbor、show lacp internal、show etherchannel summary。
    • Juniper:show lacp interfaces ae[number]。
    • Arista:show port-channel [number] lacp neighbor,然後 show etherchannel。

    • 確認路由器顯示 Google 的系統 ID 做為 LACP 合作夥伴。

    • 確認成員通訊埠應處於「收集發布」狀態 (通常顯示為「已繫結」、「有效」或「運作中」)。如果狀態為「Detached」、「Waiting」、「Init」或「Suspended」,表示 LACP 協商發生問題。

    • 確認 LACP 資料單元 (LACPDU) 計數器正在遞增,這表示路由器和 Google 之間正在交換 LACP 訊息。

  3. 收集資訊並提供給客戶服務團隊:如果您已嘗試上述步驟,但問題仍未解決,建議您回覆訂單電子郵件,並提供下列資訊:

    • 路由器的完整 LACP 設定。
    • LACP 狀態/鄰近指令的完整輸出內容 (例如 show lacp neighbor)。

IP 位址連線無法運作

請按照下列步驟測試 IP 連線能力:

  1. 您必須直接在邏輯 LAG 介面 (例如 Cisco/Arista 上的 Port-Channel、Juniper 上的 AE 介面) 設定 productionConfig 電子郵件中提供的臨時測試 IP 位址和子網路遮罩,而非在實體成員介面上設定。請根據路由器製造商,使用下列指令或指令組合,確認您已正確設定測試 IP 位址:

    • Cisco:show running-config interface port-channel [number],之後show ip interface port-channel [number]
    • Juniper:show configuration interfaces ae[number] unit 0 family inet,然後 show interfaces terse ae[number].0
    • Arista:show running-config interface port-channel [number],然後 show ip interface port-channel [number]
  2. 檢查路由器的 ARP 資料表,確認是否已解析 LAG 介面上 Google 端測試 IP 的 MAC 位址。請使用下列指令:

    • Cisco:show arp | include [Google Test IP]
    • Juniper:show arp no-resolve | match [Google Test IP]
    • Arista:show arp | grep [Google Test IP]

    「不完整」的 ARP 項目表示第 2 層問題,或 Google 未回應 ARP 要求。

  3. 從路由器的 LAG 介面,對 Google 測試 IP 執行連線偵測 (ping) 測試。使用 LAG 介面指派的測試 IP 位址進行連線偵測 (ping)。取得 IP 位址後,請根據路由器製造商使用下列指令:

    • Cisco/Arista:ping [Google Test IP] source [Your LAG Test IP]
    • Juniper:ping [Google Test IP] source [Your LAG Test IP]
  4. 確認路由器上的防火牆、存取控管清單 (ACL) 或安全性政策,並未封鎖 LACP (LACP 使用 EtherType 0x8809) 或 ICMP Echo/Reply (ping)。

  5. 使用下列指令檢查路由器的 LACP 狀態:

    gcloud compute interconnects get-diagnostics INTERCONNECT_NAME
       --project=PROJECT_ID
    

    更改下列內容:

    • INTERCONNECT_NAME:您為 Dedicated Interconnect 連線指派的不重複名稱。
    • PROJECT_ID:專案 ID。

    檢查每個連結的 lacpStatus 欄位。state、googleSystemId 和 neighborSystemId 值會指出 Google 是否將您的路由器視為 LACP 合作夥伴,以及狀態是否同步。接著,檢查 arpCache 陣列,確認 Google 端是否已解析測試 IP 位址的 ARP。

  6. 收集資訊並提供給客戶服務團隊:如果您已嘗試上述步驟,但問題仍未解決,建議您回覆訂單電子郵件,並提供下列資訊:

    • LAG 介面的 IP 設定。
    • LAG 的 ARP 資料表輸出內容。
    • LAG 介面來源式連線偵測 (ping) 測試的結果。
    • 確認沒有任何防火牆/ACL 封鎖 LACP 或 ICMP。
    • gcloud compute interconnects get-diagnostics 指令的完整 JSON 輸出內容。

Partner Interconnect

BGP 工作階段無法運作 (第 2 層連線)

  • 確認地端部署路由器已設定與 Cloud Router 的 BGP 工作階段。詳情請參閱「設定 Partner Interconnect 的地端部署路由器」。
  • 在具有至少兩個躍點的內部部署路由器上啟用多重躍點 BGP。
  • 檢查您的內部部署路由器上是否已設定正確的相鄰 IP 位址。使用 VLAN 連結分配的 BGP 對等互連 IP 位址 (cloudRouterIpAddress)。
  • 確認地端部署路由器上的本機 ASN 設定與 Cloud Router (16550) 上的對接 ASN 相符。此外,請確認 Cloud Router 上的本機 ASN 設定與地端部署路由器上的對接 ASN 相符。

BGP 工作階段無法運作 (第 3 層連線)

  • Cloud Router 必須設定服務供應商的 ASN。請向服務供應商尋求協助。

Partner Interconnect 連線的 VLAN 連結中斷

即使Google Cloud 設定和 Partner Interconnect 連線沒有問題,VLAN 連結的狀態仍可能顯示為「down」(關閉)。

請務必在地端部署路由器上設定 EBGP 多躍點,至少要有四個躍點。如需設定範例,請參閱「設定地端部署路由器」。

Partner Interconnect 連線的配對金鑰問題

嘗試設定 Partner Interconnect 連線時,可能會看到「Google - Provider status not available」(Google - 無法取得供應商狀態) 等錯誤訊息。如要修正這個問題,請按照下列步驟操作:

  1. 確認配對金鑰是由客戶端 VLAN 連結 (PARTNER 類型) 產生。金鑰是一長串隨機字串,Google 會用來識別附件。目的地 Google Cloud 區域和邊緣可用性網域會以配對金鑰編碼,格式如下:

    <random_string>/<region_name>/<domain>
    

    如果 VLAN 連結不限於特定網域,或您未指定邊緣可用性網域,domain 欄位會包含 any 字串。如要進一步瞭解配對金鑰,請參閱「配對金鑰」。

  2. 請確認 Partner Interconnect 連線的邊緣可用性網域與配對金鑰指定的網域相符。

無法對 Cloud Router 執行連線偵測 (第 2 層連線)

  • 確認地端部署路由器的子介面上有正確的 VLAN 連結。VLAN 連結資訊應與服務供應商提供的資訊相符。
  • 檢查您的內部部署路由器的子介面上是否有正確的 IP 位址。服務供應商設定 VLAN 連結後,連結會分配一組連結本機 IP 位址。一個用於相關聯 Cloud Router (cloudRouterIpAddress) 的介面,另一個用於地端部署路由器通訊埠通道的子介面,而非通訊埠通道本身 (customerRouterIpAddress)。
  • 測試連結效能時,請勿對 Cloud Router 執行連線偵測 (ping)。請改為在虛擬私有雲網路中建立並使用 VM。詳情請參閱「效能測試」。

Partner Interconnect 連線通訊埠的光功率損失

如果通訊埠的光功率中斷,可能會發生下列任一問題:

  • 第 3 層連線中斷 (BGP 工作階段中斷) 或無法存取 Google Cloud VM 執行個體。
  • 連結套件效能降低。如果多個 10GE 連接埠綁定在一起,且只有部分連結正常運作,就會發生這個問題。

通訊埠失去光功率,表示硬體無法偵測到另一端的訊號。可能原因如下:

  • 收發器故障
  • 運輸系統故障
  • 實體光纖問題

如要修正這個問題,請與 Partner Interconnect 和/或線路供應商聯絡。他們可以執行下列步驟:

  1. 檢查收發器是否正常運作。
  2. 對 Meet-Me Room (MMR) 執行硬體迴路測試,確認裝置的光線強度是否正常。
  3. 確認問題是出在他們那端,還是 Google 端。隔離介面的最佳方式,是在分界點放置雙向迴路。兩端的介面會將光線傳輸到分界點,然後光線會迴路傳回。故障端就是無法正常啟動的界點端。
  4. 清潔並重新安裝他們那端的所有光纖。

無法透過 L3 Partner Interconnect 連線傳送及學習 MED 值

如果您使用 Partner Interconnect 連線,且由第 3 層服務供應商為您處理 BGP,Cloud Router 就無法從地端部署路由器學習 MED 值,也無法將 MED 值傳送至該路由器。這是因為 MED 值無法通過自治系統。透過這類連線,您無法為 Cloud Router 向地端部署路由器 advertise 的路由設定路由優先順序。此外,您無法為地端部署路由器 advertise 至虛擬私有雲網路的路由設定路由優先順序。

將連結的堆疊類型變更為雙重堆疊後,IPv6 流量無法正常運作

  1. 查看 Cloud Router 狀態,確認顯示 status: UP。

    如果 BGP 未啟動,請執行下列操作:

    1. 確認地端部署路由器 (如果您使用第 3 層合作夥伴,則為合作夥伴的路由器) 已設定 IPv6 BGP 工作階段,且該工作階段使用正確的 IPv6 位址。

    2. 查看 BGP 工作階段設定,並確認 bgpPeers.enable 顯示 Cloud Router 的 'TRUE'。

    如果 BGP 已啟用,請查看 Cloud Router 路徑,確認系統顯示預期的 IPv6 best_routes。

    如果未顯示預期的 best_routes,請確認地端部署路由器 (如果您使用第 3 層合作夥伴,則為合作夥伴的路由器) 已設定正確的 IPv6 路由。

所有其他問題

如需其他協助,請與服務供應商聯絡。如有需要,服務供應商會與 Google 聯絡,修正 Google 端網路相關問題。

採用 Cloud Interconnect 的高可用性 VPN

透過 Cloud Interconnect 部署高可用性 VPN 時,您會建立兩個作業層:

  • Cloud Interconnect 級別,包括 VLAN 連結和 Cloud Interconnect 的 Cloud Router。
  • 高可用性 VPN 級別,包括高可用性 VPN 閘道和通道,以及高可用性 VPN 的 Cloud Router。

每個級別都需要專屬的 Cloud Router:

  • Cloud Interconnect 的 Cloud Router 專用於在 VLAN 連結之間交換 VPN 閘道前置字元。這個 Cloud Router 僅供 Cloud Interconnect 級別的 VLAN 連結使用。無法用於高可用性 VPN 級別。
  • 高可用性 VPN 的 Cloud Router 會在虛擬私有雲網路和地端部署網路之間交換前置字元。您設定高可用性 VPN 的 Cloud Router 及其 BGP 工作階段的方式,與一般高可用性 VPN 部署作業相同。

您可以在 Cloud Interconnect 級別上建構高可用性 VPN 級別。因此,高可用性 VPN 級別需要正確設定並運作 Cloud Interconnect 級別 (基於 Dedicated Interconnect 或 Partner Interconnect)。

如要排解採用 Cloud Interconnect 的高可用性 VPN 部署問題,請先排解 Cloud Interconnect 級別的問題。確認 Cloud Interconnect 正常運作後,請排解高可用性 VPN 級別的問題。

無法為 Cloud Interconnect 的 Cloud Router 建立 BGP 工作階段

如要偵測與 VLAN 連結相關聯的 BGP 工作階段是否中斷,請執行下列指令:

   gcloud compute routers get-status INTERCONNECT_ROUTER_NAME

將 INTERCONNECT_ROUTER_NAME 替換為您為 Cloud Interconnect 級別建立的 Cloud Router 名稱,該級別用於採用 Cloud Interconnect 的高可用性 VPN 部署項目。

如要修正這個問題,請按照下列步驟操作:

  1. 請按照「測試連線」和「取得診斷資訊」中的步驟操作,確保基礎 Cloud Interconnect 連線運作正常。
  2. 確認 BGP 工作階段介面指向正確的連結。
  3. 檢查 Cloud Router 和地端部署路由器上,為 BGP 工作階段介面設定的 IP 位址。
  4. 確認 Cloud Router 和地端部署路由器上的 ASN 號碼設定正確。
  5. 確認 Cloud Interconnect 連線和 VLAN 連結處於 admin-enabled 狀態。

無法建立高可用性 VPN 通道

如要檢查通道狀態,請執行下列指令:

gcloud compute vpn-tunnels describe VPN_TUNNEL_NAME

將 VPN_TUNNEL_NAME 替換為高可用性 VPN 通道的名稱。

如要修正這個問題,請按照下列步驟操作:

  1. 由於 VPN 通道是透過 VLAN 連結轉送,請確認與 VLAN 連結相關聯的 BGP 工作階段已建立。如果沒有,請參閱「無法為 Cloud Interconnect 的 Cloud Router 建立 BGP 工作階段」。
  2. 檢查 Cloud VPN 閘道和地端部署 VPN 閘道上的通道 PSK 和加密編譯是否設定正確。
  3. 確認地端部署路由器的 BGP 公告包含地端部署 VPN 閘道位址。如果沒有,請調整地端部署路由器的 BGP 設定,以通告位址。
  4. 確認通往地端部署 VPN 閘道的路徑未因與現有 BGP 路徑衝突而遭捨棄。如有衝突,請調整 VPN 閘道位址或 advertise 路由。
  5. 確認 Cloud Router 的 BGP 公告包含高可用性 VPN 閘道位址。您可以從地端部署路由器檢查,或檢查 BGP 對等互連的 advertisedRoutes 欄位。如要查看 advertisedRoutes 欄位,請執行下列指令:

    gcloud compute routers get-status INTERCONNECT_ROUTER_NAME
    

    將 INTERCONNECT_ROUTER_NAME 替換為您為 Cloud Interconnect 級別建立的 Cloud Router 名稱,該級別用於採用 Cloud Interconnect 的高可用性 VPN 部署項目。

    如果未 advertise 高可用性 VPN 閘道位址,請確認 VLAN 連結與加密的 Cloud Interconnect 路由器相關聯。確認每個 VLAN 連結都已設定預期的區域性內部 IPv4 位址 (--ipsec-internal-addresses)。

無法為高可用性 VPN 的 Cloud Router 建立 BGP 工作階段

如要檢查與 VLAN 連結相關聯的 BGP 工作階段是否已關閉,請執行下列指令:

gcloud compute routers get-status VPN_ROUTER_NAME

將 VPN_ROUTER_NAME 替換為您為採用 Cloud Interconnect 的高可用性 VPN 部署作業的高可用性 VPN 級別建立的 Cloud Router 名稱。

如要修正這個問題,請按照下列步驟操作:

  1. 由於 BGP 流量是透過 VPN 通道轉送,請確認 VPN 通道已建立。如果沒有,請按照「無法建立高可用性 VPN 通道」中的步驟操作。
  2. 檢查 Cloud Router 的 BGP 工作階段介面是否指向正確的 VPN 通道。
  3. 確認 Cloud Router 和地端部署 VPN 裝置上的 BGP 工作階段介面 IP 位址設定正確。
  4. 確認 Cloud Router 和地端部署路由器上的 ASN 號碼設定正確。

虛擬私有雲流量未傳送至地端部署網路,反之亦然

從 VM (例如 ping 或 iperf) 產生的流量無法連至地端部署網路,或地端部署網路無法連至從 VM 產生的流量。

如要修正這個問題,請按照下列步驟操作:

  1. 由於 VM 流量是透過 VPN 通道轉送,請確認從 VM 到 VPN 通道的路由是由 Cloud Router 傳送。

  2. 確認高可用性 VPN 的 Cloud Router 工作階段已建立。如果沒有,請參閱「無法為高可用性 VPN 的 Cloud Router 建立 BGP 工作階段」。

封包遺失或處理量偏低

從虛擬私有雲網路上的 VM 傳送至地端部署網路的流量,或從地端部署網路傳送至虛擬私有雲網路的流量,都會遭到捨棄。

您透過 ping、iperf 和其他網路監控工具,觀察到封包遺失或處理量偏低。

如要修正這個問題,請按照下列步驟操作:

  1. 檢查 VLAN 連結的流量是否過載。如果是,請將流量分散至更多 VLAN 連結,或更新連結的容量。
  2. 檢查高可用性 VPN 的流量是否過載。如果是,請透過 VLAN 連結建立額外的 VPN 通道,重新分配流量。
  3. 確認流量沒有非預期或突然暴增的情況。TCP 串流可能會受到其他串流影響,例如突發性 UDP 流量。
  4. 檢查超過通道 MTU 的封包是否已分割。請確認 MTU 已正確設定 VLAN 連結,並檢查 UDP 流量是否未受到 MSS 限制。

VLAN 連結指標顯示因BANDWIDTH_THROTTLE而捨棄

監控連線時,如果查看 VLAN 連結指標,可能會看到因BANDWIDTH_THROTTLE而下降。如果透過連結傳送流量的速度過快,就會發生這種情況,導致部分流量受到限制。這是正常行為,通常會由 TCP 重新傳輸處理。

不過,查看對應的輸入和輸出使用率圖表時,並未顯示流量尖峰。這是因為系統會以 60 秒的取樣間隔擷取指標,因此可能會遮蓋短暫的流量高峰或突發流量。

如果流量很少受到限制,您可能不需要解決這個問題。不過,如果頻寬節流經常發生,您可以實作指數輪詢,並加入抖動,避免節流用戶端同步重試。

無法刪除加密的 VLAN 連結

嘗試刪除 Dedicated Interconnect 或 Partner Interconnect 的加密 VLAN 連結時,收到下列錯誤訊息:

ResourceInUseByAnotherResourceException

如要修正這個問題,請務必先刪除與加密 VLAN 連結相關聯的所有高可用性 VPN 閘道和通道。詳情請參閱「刪除採用 Cloud Interconnect 的高可用性 VPN」。

加密 VLAN 連結的 IP 位址類型不相符

嘗試建立高可用性 VPN 閘道,以便在採用 Cloud Interconnect 的高可用性 VPN 部署作業中使用時,收到下列錯誤訊息:

One of the VLAN attachments has private IP address type, while the other one
has public IP address type; they must have same IP address type.

如果為高可用性 VPN 閘道指定兩個加密 VLAN 連結,且高可用性 VPN 通道介面的 IP 定址配置不同,就會發生這項錯誤。兩個 VLAN 連結的 IP 位址類型必須相符。

建立 VPN 閘道時,請指定使用兩個私人 IP 位址或兩個公開 IP 位址的 VLAN 連結。如果在建立 VPN 閘道時收到這項錯誤,請使用正確的位址類型重新建立 VLAN 連結。

高可用性 VPN 閘道介面缺少 VLAN 連結

如果部署的是採用 Cloud Interconnect 的高可用性 VPN,則高可用性 VPN 閘道的兩個介面都必須指定加密 VLAN 連結。

如果只指定一個 VLAN 連結,系統會顯示下列錯誤:

VPN Gateway should have VLAN attachment specified in both interfaces or in none.

如要修正這個問題,請建立高可用性 VPN 閘道,並指定兩個 VLAN 連結。

VLAN 連結類型無效

加密 VLAN 連結的類型必須是 DEDICATED 或 PARTNER。

如果您為加密的 VLAN 連結指定無效類型,系統會顯示下列錯誤訊息:

VLAN attachment should have type DEDICATED or PARTNER.

如要修正這個問題,請只建立類型為 DEDICATED 或 PARTNER 的加密 VLAN 連結。

VLAN 連結的 MTU 值有誤

為 Dedicated Interconnect 建立加密 VLAN 連結時,系統會顯示下列錯誤訊息:

Wrong MTU value [mtuValue] for VLAN attachment.
The supported MTU for IPsec packets for HA VPN over Cloud Interconnect is 1440.

如要修正這個問題,請使用正確的 1440 值 (預設值) 重新建立附件。

VLAN 連結類型不同

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

VLAN attachments should both have same type DEDICATED or PARTNER.
But found one DEDICATED and one PARTNER.

如要修正這個問題,請指定兩個相同類型的 VLAN 連結,也就是 DEDICATED 或 PARTNER。

專屬 VLAN 連結不在同一個都會區

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

Dedicated VLAN attachments should be in the same metropolitan area.

如要修正這個問題,請在同一個都會區為 Dedicated Interconnect 建立兩個加密 VLAN 連結。

高可用性 VPN 閘道與 VLAN 連結不在同一個網路

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

VPN Gateway should be in the same network as VLAN attachment.
VLAN attachment network: [networkName], VPN gateway network: [networkName]

如要修正這個問題,請在與加密 VLAN 連結相同的網路中,建立高可用性 VPN 閘道。

VLAN 連結的加密類型有誤

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

Wrong encryption type for VLAN attachment [interconnectAttachmentName],
required IPSEC.

如要修正這個問題,請僅指定加密類型設為 IPSEC 的加密 VLAN 連結。如有需要,請建立加密的 VLAN 連結。

VLAN 連結可用區與 interfaceId 不符

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

VLAN attachment zone should match interfaceId: interface 0 - zone1,
interface 1 - zone2, but found interface [interfaceId] - [zone] for
[interconnectAttachmentName].

第一個高可用性 VPN 閘道介面 (interface 0) 必須與可用區 1 的加密 VLAN 連結相符,第二個介面 (interface 1) 則必須與可用區 2 的加密 VLAN 連結相符。

如要修正這個問題,請從與高可用性 VPN 閘道介面正確配對的可用區,指定加密的 VLAN 連結。

VPN 閘道與 VLAN 連結不在相同區域

為高可用性 VPN 閘道介面指定加密 VLAN 連結時,會出現下列錯誤訊息:

VPN Gateway should be in the same region as VLAN attachment.
VLAN attachment region: [region], VPN gateway region: [region].

如要修正這個問題,請在相同區域建立高可用性 VPN 閘道和加密 VLAN 連結。

合作夥伴 VLAN 連結未處於有效狀態

為高可用性 VPN 閘道介面指定 Partner Interconnect 的加密 VLAN 連結時,會出現下列錯誤訊息:

Interconnect Attachments [name] must be in active state.

您必須先啟用 Partner Interconnect 的 VLAN 連結,才能將其與高可用性 VPN 閘道介面建立關聯。

詳情請參閱「啟用連結」。

為 VLAN 連結指定的 Cloud Router 類型有誤

嘗試建立加密 VLAN 連結時,系統會顯示下列錯誤訊息:

Router must be an encrypted interconnect router.

如要修正這個問題,請使用 --encrypted-interconnect-router 旗標建立 Cloud Router。這個 Cloud Router 專用於透過 Cloud Interconnect 建立的高可用性 VPN。

接著,建立加密的 VLAN 連結,並提供加密的 Cloud Router。

Cross-Cloud Interconnect

本節說明 Cross-Cloud Interconnect 可能發生的問題。

Google 支援的連線範圍,最遠可達其他雲端服務供應商的網路。Google 不保證其他雲端服務供應商的運作時間,也無法代您建立支援單。在您授權後,客戶服務 可直接與其他雲端服務供應商的支援團隊聯絡,加快解決問題。不過,您必須向其他供應商提交支援單。

備援通訊埠不相符

訂購 Cross-Cloud Interconnect 連接埠後,請向 Google 提供資訊,說明您希望如何將連接埠連至遠端雲端連接埠。稍後設定資源時,也會用到這項資訊。如果遇到連線問題,其中一個原因可能是您未提供正確的連線詳細資料。

例如,您可以提供類似下列的指示:

  • 將 gcp-1 連結至 azure-1。

  • 將 gcp-2 連結至 azure-2。

不過,設定資源時,您可能會假設通訊埠的連線方式如下:

  • 將 gcp-1 連結至 azure-2。

  • 將 gcp-2 連結至 azure-1。

檢查 ARP 快取,或許能偵測到這種情況。不過,更簡單的解決方案是前往遠端雲端,嘗試交換指派給兩個 BGP 對等互連的 IP 位址範圍。

舉例來說,假設 azure-1 的 VLAN 連結對等互連位於 169.254.0.2,azure-2 的 VLAN 連結對等互連位於 169.254.99.2。交換 IP 位址範圍,讓 azure-1 連結使用 169.254.99.2,azure-2 連結使用 169.254.0.2。

如果您在每個通訊埠上為連結使用不同的 VLAN ID,則也需要交換連結使用的 VLAN ID。如果是 Azure,這種情況不可能發生,因為每個連結的兩個通訊埠都必須使用相同的 VLAN ID。

VLAN ID

有時連線能力問題可追溯至 VLAN ID 值錯誤。VLAN ID 是 Cross-Cloud Interconnect VLAN 連結中的欄位。

Azure

Azure 要求一對連接埠的 VLAN ID 必須相同。建立 VLAN 連結時, Google Cloud 控制台會強制執行這項規定。不過,如果使用 Google Cloud CLI 或 API 設定連結,則可分配不同的 VLAN ID。如果您在建立連結時自動指派 VLAN ID,這種風險會特別高。如未明確設定 ID,系統會自動指派。

AWS

連線至 AWS 時,可以使用自動指派的 VLAN ID。不過,設定 AWS 資源時,您必須手動設定 VLAN ID,使其與 Google Cloud 自動指派的 ID 相符。此外,請務必確認每個通訊埠應使用的 VLAN ID,以免混淆。如果通訊埠設定的 VLAN ID 有誤,虛擬路由器就無法通訊。

驗證連線

如果您尚未驗證 Google Cloud 和遠端雲端網路之間的連線,請按照下列步驟操作: