本頁面由 Cloud Translation API 翻譯而成。

排解網路問題

這個頁面詳細說明如何排解常見的網路問題。

排解網路啟動問題

本節列出完成網路啟動程序時可能遇到的一些常見錯誤。

設定生成錯誤

如要完成網路安裝，請在啟動程序機器上安裝網路設定檔。如果發生設定產生錯誤，請檢查 /root/cellcfg 中的 YAML 檔案，瞭解失敗的交換器設定。

啟動程序在階段 1 的 Ping 停滯

如果網路啟動程序在第 1 階段的 Ping 停滯不前，請按照下列步驟找出問題：

從啟動程序記錄取得產生的交換器設定位置：/tmp/network-bootstrap/ID
查看含有 IP 位址的交換器設定檔，找出停滯的交換器。
登入交換器並檢查作業記錄。

啟動程序在第 2 階段的 Ping 階段停止

如果網路啟動程序在第 2 階段的 Ping 停滯不前，請按照下列步驟找出問題：

從啟動程序記錄取得產生的交換器設定位置：/tmp/network-bootstrap/ID
使用管理 IP 位址查看交換器設定檔，找出停滯的交換器。
檢查管理交換器設定，確認管理網路是否有任何潛在存取問題。

排解第 2 天網路對帳問題

總覽

在交換器對帳期間，GDC 會使用 Cisco NX-OS 提供的設定取代功能，以全新設定取代交換器中的執行設定。設定取代作業在內部執行的步驟如下：

計算目前執行中的設定與使用者提供的設定之間的差異。
產生修補程式檔案，其中包含執行中設定與輸入設定之間的差異。
對修補程式檔案執行語意驗證。
套用修補程式檔案。
比較 running-config 與輸入設定，確認修補程式檔案是否已正確新增。否則會還原為先前的設定
系統會先啟動計時器，您必須在計時器結束前執行「configure replace commit」指令，否則系統會還原為新設定。

上述每個步驟都可能發生失敗，但最常發生在步驟 3、4 和 1。以下是排解設定取代錯誤的方法。

常見的疑難排解步驟

查看整體切換狀態

在根管理伺服器中執行 kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system (將交換器名稱替換為所需交換器名稱)

如果上次設定取代作業失敗，根管理員叢集中的切換 Kubernetes 物件會顯示 exec，並在物件說明中驗證記錄。

查看上次設定取代作業的狀態

在交換器控制台中執行 show config-replace status：

狀態會提供下列資訊

整體狀態，例如「完成」、「失敗」等。
設定取代作業是否已提交，或正在等待提交。
上次設定取代作業的開始和結束時間

檢查上次設定取代作業套用的設定

在交換器控制台中執行 show config-replace log exec。

設定取代作業會將設定取代執行記錄中產生的記錄，套用為修補程式設定，也就是執行中設定與輸入設定的差異。

請注意，這些記錄有時會發生錯誤，但設定取代作業會忽略這些錯誤，不會導致設定取代作業整體失敗。除非錯誤是「Executing Patch」部分中 exec 記錄的最後一行，否則可能不是設定取代失敗的原因。

檢查上次設定取代作業的驗證是否成功

在交換器控制台中執行 show config-replace log verify。

在設定取代執行步驟之後，設定取代作業會比較交換器的新執行設定與輸入設定。這些設定必須相符。如果沒有，設定替換作業就會失敗，並將設定還原為先前的設定。

驗證記錄分為兩部分。

Configuration To Be Added Missing in Running-config：列出輸入設定中存在，但新執行設定中沒有的設定
Configuration To Be Removed Present in Running-config：列出新執行設定中存在但輸入設定中沒有的設定

檢查交換器上執行的所有指令

在交換器控制台中執行  (將開始時間替換為必要開始時間)show accounting log start-time 2022 Sep 13 20:00:00

會計記錄檔會顯示在交換器上執行的每個指令。這些記錄有助於瞭解透過 NXAPI 或手動在交換器上執行的指令。您也可以藉此瞭解每次設定取代作業的確切執行時間和次數。

查看已對交換器發出的 NX-API 呼叫，以及呼叫來源

在交換器控制台中執行 show nxapi-server logs

NX-API 記錄會顯示與對交換器進行 NXAPI 呼叫相關的記錄。由於自動化堆疊會基於許多原因 (包括執行設定替換) 對交換器發出 NXAPI 呼叫，因此這項功能有助於查看發出的 NXAPI 呼叫，以及呼叫的來源。

互連網路疑難排解

Interconnect API 總覽

Interconnect API 會為 GDC 資料中心單元設定外部連線。互連分為 3 種

資料中心互連 (DCI)：透過資料平面邊界葉片交換器，從一個 GDC 資料中心互連至另一個 GDC 資料中心。
客戶對等互連 (CPI)：從 GDC 資料中心到 ORG 網路的互連，透過資料平面邊界葉片交換器。
網路營運中心 (NOC)：透過資料平面邊界 Leaf 交換器和管理匯總交換器，從 GDC 資料中心互連至網路營運中心。

API 物件如下：

InterconnectLink：這個 API 物件定義連線至外部交換器的實體連接埠。
InterconnectAttachment：這個 API 物件會定義設定的 InterconnectLink 頂端存在的附件。每個附件所含的資訊會定義下列項目：
1. 互連網路類型
2. BGP 資訊
3. VLAN ID 資訊
4. 已設定的路由政策
RoutePolicy：這個 API 物件會模擬用於與互連 BGP 對等互連裝置共用路徑的政策。

疑難排解

驗證 InterconnectLink 和 InterconnectAttachment 狀態

InterconnectLink 和 InterconnectAttachment API 物件會公開大量資訊，有助於瞭解目前狀態。

InterconnectLink：系統會針對連線至外部交換器的每個實體連接埠，公開下列資訊。
1. Up：通訊埠是否正常運作的狀態資訊。
2. DownReason：通訊埠停機的原因。
InterconnectAttachment：系統會顯示每個已設定互連附件的下列資訊。
1. BGPStatus：BGP 工作階段的狀態，例如「Up」或「Down」。
2. UpTime：上次 BGP 工作階段啟動的時間戳記。
3. PrefixCounters：顯示前置字串總數的計數器，包括 Received、Sent 和 Withdrawn。

驗證路徑政策

RoutePolicy 定義前置字串清單和要採取的動作，例如「允許」或「拒絕」。列出與 InterconnectAttachment 資源相關聯的所有路徑政策，確認 IP 位址是否屬於有效的 RoutePolicy。

透過防火牆驗證邊界 Leaf 交換器上的 BGP 路徑前置字元/流量

互連資料路徑也會經過兩個 PANW 防火牆：入侵偵測與防範系統 (IDPS) 防火牆和邊界防火牆。即使路徑前置碼是從 BGP 工作階段取得，防火牆仍有可能捨棄這些前置碼。

驗證各種 `VRFs` 上學到的路徑前置字串

外部流量在匯總交換器上經過多個 VRF，因為流量會通過不同的防火牆。檢查透過這些 VRF 點學到的 BGP 路徑前置字元，以路由前置字元/流量在防火牆遭到捨棄。

所有外部流量都會放入外部 VRF *-external-vrf，具體取決於邊界 Leaf 交換器上的流量來源或目的地叢集。示例：root-external-vrf 的流量來源或目的地是根管理員叢集。

流量通過 IDPS 防火牆後，會進入下列其中一個互連 VRF：

oc-vrf
dci-vrf
cp-vrf

對於目的地為 NOC 的流量，在流量抵達 octransit-vrf 之前，還會經過額外的周邊防火牆。

登入邊界葉片交換器，然後使用下列指令顯示在各種 VRF 上學到的路由前置字元：

show bgp vrf <vrf_name> all

其中 vrf_name 可以是其中一個 VRF。

ANG BGP 疑難排解

叢集 kubeconfig 檔案

請確認您有下列 KUBECONFIG_FILE 值，可檢查物件：

ROOT_ADMIN_KUBECONFIG：根管理員叢集的 kubeconfig 檔案。
ORG_ADMIN_KUBECONFIG：機構管理員叢集的 kubeconfig 檔案。
ORG_SYSTEM_KUBECONFIG：機構系統叢集的 kubeconfig 檔案。
ORG_USER_KUBECONFIG：機構使用者叢集的 kubeconfig 檔案。

叢集卡在佈建狀態

確認 NodePool 物件已準備就緒。
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A
```
如果節點集區物件未建立或未就緒，請檢查 NodePoolClaim 和節點連線。

確認 ClusterBGPPeer 物件已準備就緒。

確認已為 flat-ip-bgp-x、lb-bgp-x 和 node-x 建立 ClusterBGPPeer 物件：

kubectl --kubeconfig KUBECONFIG_FILE \
    get clusterbgppeers -A
...
ORG_NAME-system-cluster   flat-ip-bgp-peer-0                   16h
ORG_NAME-system-cluster   lb-bgp-peer-0                        21h
ORG_NAME-system-cluster   node-10.251.100.10-peer-10.0.224.0   21h

如果未建立物件，請檢查 NetworkGatewayGroup 和 BGPPeer 物件。

確認 BGPSession 已啟動。
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A
```
如果 BGP 工作階段未啟動，請參閱「BGP 工作階段未建立」。

未建立 BGP 工作階段

查看 `TORSwitchInternal` 上的 `EBGPNeighbor`

檢查 ClusterBGPRouter，取得每個介面的對等 TOR 交換器。

ORG_NAME ClusterBGPRouter 的介面用於對等互連 ORG_NAME 的所有叢集。

 apiVersion: network.private.gdc.goog/v1alpha1
 kind: ClusterBGPRouter
 metadata:
 labels:
     clusterbgpreconciler.system.private.gdc.goog/overlay-network: external
 name: external-vrf-cluster-bgp-router
 namespace: ORG_NAME
 spec:
 clusterASN: 64513
 interfaces:
 - ip: 10.0.252.48
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw01
 - ip: 10.0.252.49
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw02
 networkASN: 65014

針對每個 TORSwitchInternal，請檢查 spec.ebgpNeighbors，確認是否已設定所有 ClusterBGPPeer 物件。

在 TOR 交換器上偵錯 BGP 工作階段

透過 SSH 連線至其中一個對等互連的 TOR 交換器。

驗證 ORG_NAME 的 ANG BGP 鄰居：

> sh run bgp
router bgp 65014
...
  vrf ORG_NAME-external-vrf
    ...
    neighbor 10.251.100.3
      inherit peer ANG
      update-source loopback200
    neighbor 10.251.100.4
      inherit peer ANG
      update-source loopback200
    ...
  vrf ORG_NAME-internal-vrf
    ...
    neighbor 172.20.128.5
      inherit peer ANG
      update-source loopback100
    neighbor 172.20.128.6
      inherit peer ANG
      update-source loopback100
  ...

檢查 BGP 工作階段狀態：

> sh bgp ses vrf ORG_NAME-external-vrf
> sh bgp ses vrf ORG_NAME-internal-vrf

查看 BGP 記錄：

> debug ip bgp all
> no debug ip bgp all (disable log mode)

使用 bash 進行偵錯：

> run bash
> sudo tcpdmp -i any port 179 -vvv

排解網路問題 透過集合功能整理內容 你可以依據偏好儲存及分類內容。