このページは Cloud Translation API によって翻訳されました。

ネットワークのトラブルシューティング

このページには、一般的なネットワークの問題のトラブルシューティング方法の詳細が記載されています。

ネットワークブートストラップのトラブルシューティング

このセクションでは、ネットワークブートストラッププロセスの完了時に発生する可能性のある一般的なエラーについて説明します。

構成生成エラー

ネットワークインストールを完了するには、ネットワーク構成ファイルがブートストラッパーマシンにインストールされます。構成生成エラーが発生した場合は、/root/cellcfg にある YAML ファイルで、失敗したスイッチ構成を確認します。

ブートストラップがフェーズ 1 の ping で停止する

ネットワークブートストラッププロセスがフェーズ 1 の ping で停止した場合は、次の手順で問題を見つけます。

ブートストラップログから生成されたスイッチ構成の場所を取得します。/tmp/network-bootstrap/ID
IP アドレスを使用してスイッチ構成ファイルを確認し、停止したスイッチを見つけます。
スイッチにログインして、オペレーションログを確認します。

ブートストラップがフェーズ 2 の ping で停止する

ネットワークブートストラッププロセスがフェーズ 2 の ping で停止した場合は、次の手順で問題を見つけます。

ブートストラップログから生成されたスイッチ構成の場所を取得します。/tmp/network-bootstrap/ID
管理 IP アドレスを使用してスイッチ構成ファイルを確認し、停止したスイッチを見つけます。
管理ネットワークでアクセスに関する問題が発生する可能性がないか、管理スイッチの構成を確認します。

ネットワークの Day 2 の調整のトラブルシューティング

概要

GDC は、スイッチの調整中に Cisco NX-OS が提供する構成置換機能を使用して、スイッチの実行中の構成を完全に新しい構成に置き換えます。構成の置換オペレーションが内部的に行う手順は次のとおりです。

現在の実行構成とユーザーが指定した構成の差分を計算します。
実行中の構成と入力構成の差分であるパッチファイルを生成します。
パッチファイルに対してセマンティック検証を行います。
パッチファイルを適用します。
実行中の構成と入力構成を比較して、パッチファイルが正しく追加されたことを確認します。それ以外の場合は、以前の構成に戻ります
コマンド configure replace commit を実行するか、新しい構成を元に戻す前に、タイマーが開始されます。

エラーは前の各手順で発生する可能性がありますが、最も頻繁に発生するのは手順 3、4、1 です。構成の置換に関するエラーのトラブルシューティング方法は次のとおりです。

一般的なトラブルシューティングの手順

スイッチの全体的なステータスを確認する

ルート管理サーバーで kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system を実行します（スイッチ名を必要なスイッチ名に置き換えます）。

ルート管理クラスタの switch Kubernetes オブジェクトは、最後の構成の置換が失敗した場合、オブジェクトの説明に exec ログと検証ログを表示します。

最後の構成置換オペレーションのステータスを確認する

スイッチコンソールで show config-replace status を実行します。

ステータスには次の情報が表示されます。

全体的なステータス（「完了」、「失敗」など）。
構成の置換がコミットされたか、コミット待ちであるか。
最後の構成置換オペレーションの開始時刻と終了時刻

最後の構成置換オペレーションで適用された構成を確認する

スイッチコンソールで show config-replace log exec を実行します。

構成置換実行ログには、構成置換オペレーションでパッチ構成として決定された構成（実行中の構成と入力構成の差分）を適用する際に生成されたログが表示されます。

これらのログにはエラーが含まれている場合がありますが、構成の置換オペレーションでは無視されるため、構成の置換全体が失敗することはありません。エラーが [Executing Patch] セクションの実行ログの最後の行でない限り、構成の置換の失敗の原因ではない可能性があります。

最後の構成置換オペレーションの検証が成功したかどうかを確認する

スイッチコンソールで show config-replace log verify を実行します。

構成置換の実行ステップの後、構成置換オペレーションは、スイッチの新しい実行構成を入力構成と比較します。これらの構成は一致している必要があります。一致しない場合は、構成の置換が失敗し、構成が以前の構成にロールバックされます。

検証ログには 2 つのセクションがあります。

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）: データプレーンボーダーリーフスイッチと管理アグリゲーションスイッチを介して、GDC データセンターからネットワークオペレーションセンターに相互接続します。

次の API オブジェクトが存在します。

InterconnectLink: この API オブジェクトは、外部スイッチに接続する物理ポートを定義します。
InterconnectAttachment: この API オブジェクトは、構成された InterconnectLink の上に存在するアタッチメントを定義します。添付ファイルごとに含まれる情報によって、次のことが定義されます。
1. 相互接続のタイプ
2. BGP 情報
3. VLAN ID 情報
4. 構成されているルートポリシー
RoutePolicy: この API オブジェクトは、インターコネクト BGP ピアとのルートの共有に使用されるポリシーをモデル化します。

トラブルシューティング

InterconnectLink と InterconnectAttachment のステータスを確認する

InterconnectLink API オブジェクトと InterconnectAttachment API オブジェクトは、現在のステータスを把握できる豊富な情報を公開します。

InterconnectLink: 外部スイッチに接続する各物理ポートについて、次の情報が公開されます。
1. Up: ポートがアップかダウンかを示すステータス情報。
2. DownReason: ポートがダウンしている理由。
InterconnectAttachment: 構成された各 Interconnect アタッチメントについて、次の情報が公開されます。
1. BGPStatus: BGP セッションのステータス（Up、Down など）。
2. UpTime: BGP セッションが最後に起動したときのタイムスタンプ。
3. PrefixCounters: プレフィックス Received、Sent、Withdrawn の合計数を示すカウンタ。

ルートポリシーを確認する

RoutePolicy は、接頭辞のリストと実行するアクション（許可や拒否など）を定義します。InterconnectAttachment リソースに関連付けられているすべてのルートポリシーを一覧表示して、IP アドレスが有効な RoutePolicy の一部であるかどうかを確認します。

ファイアウォール経由のボーダーリーフスイッチで BGP ルートプレフィックス/トラフィックを確認する

相互接続データパスは、侵入検知 / 防御システム（IDPS）ファイアウォールと境界ファイアウォールの 2 つの PANW ファイアウォールも通過します。ルートプレフィックスが BGP セッションから学習された場合でも、ファイアウォールによって破棄される可能性があります。

さまざまな `VRFs` で学習されたルート接頭辞を確認する

外部トラフィックは、さまざまなファイアウォールを通過する際に、アグリゲーションスイッチで複数の VRF を通過します。これらの VRF で学習した BGP ルートプレフィックスを確認すると、ファイアウォールでドロップされたルートプレフィックス/トラフィックが示されます。

すべての外部トラフィックは、境界リーフスイッチのトラフィックの送信元または宛先クラスタに応じて、外部 VRF *-external-vrf に配置されます。例: 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
```
nodepool オブジェクトが作成されていないか、準備ができていない場合は、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 セッションをデバッグする

ピアリングされた TOR スイッチのいずれかに SSH で接続します。

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

ネットワークのトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

ネットワーク ブートストラップのトラブルシューティング