Cisco Japan Blog
Share
tweet

Cisco Japan Blog > クラウド

クラウド

エンドツーエンドのフロー状態の検証に役立つ Nexus Dashboard Insights の接続性分析機能


2022年1月13日

この記事は、DC Switching Marketing の Distinguished Technical Marketing Engineer である Tim Stevenson によるブログ「End-to-End Flow State Validation with Nexus Dashboard Insights Connectivity Analysispopup_icon」（2021/11/4）の抄訳です。

IT 運用担当者にとって、「アプリケーションのパフォーマンスが悪い」、「ネットワークが遅い」、「いつもではないが、時々パフォーマンスが落ちる」といったあいまいな表現はなじみ深いものです。ネットワークパフォーマンスの問題を診断しようとしたとき、多くの場合、利用できる明らかな情報はほとんどありません。さまざまなデバイスにさまざまな原因が存在し、全体的または部分的な問題を引き起こしていることもあり得ます。そこで生じるのが、「問題を迅速かつ確実に特定するにはどうすればよいか」という問題です。

まずは明らかなものから（そうでない場合もありますが）ネットワークの問題の兆候を探ります。具体的には、インターフェイスでドロップカウンタが大量に増えていないか、QoS やセキュリティポリシーの適用ミスがないか、マイクロバーストが発生していないか、などです。問題の兆候が見つからないことも珍しくありません。そうなると後は、ネットワークファブリックの内部を詳しく調べ、コントロールプレーンとデータプレーンの両方で送信元と宛先間のすべてのデバイスとパスが適切なネットワーク状態を維持できていることを確認するほかありません。

従来の方法

こうした問題に、IT 運用担当者はどう対処しているのでしょうか。「従来の方法」では、ネットワークが意図したとおりに動作していることを検証するために、手間がかかってエラーが発生しやすい、いくつもの手順からなるワークフローを実行します。

この場合、まず問題が発生している送信元デバイスと宛先デバイスが接続されているリーフスイッチを特定する必要があります。しかし、マルチテナント、仮想マシンモビリティ、動的なワークロード配置が当たり前の今、エッジデバイスを特定するのはそう簡単ではありません。通常は、リーフスイッチにランダムにログインし、ローカルの Address Resolution Protocol（ARP）テーブルをチェックします。スイッチ上で稼働している Virtual Route Forwarding（VRF）インスタンスのいずれかにターゲット IP が直接接続されているかどうかを確認するためです。

この方法でうまくいかない場合は、VRF のルーティングテーブルを確認します。もしうまくいけば、IP が接続されているリモートスイッチを特定できます。次に、特定したスイッチにログインしてローカル ARP テーブルを確認し、エンドポイントの仮想 LAN（VLAN）を特定します。その後、Media Access Control（MAC）テーブルを確認して物理インターフェイスを見つけます。以上のプロセスを、宛先 IP アドレスに対して繰り返し実行します。面倒ですが、最終的に関連するリーフスイッチを特定するには必要な作業です。

図 1 は、特定のエンドポイントがネットワークファブリックのどこに接続されているかを特定する一般的なワークフローを示しています。この例では、VRF「tenant1」でホスト 172.16.112.96 を探しています。

図 1：エンドポイントが接続されている場所の特定

図 1：エンドポイントが接続されている場所の特定

ターゲットエンドポイントが接続されたエッジスイッチが特定できたら、次に、それらのエンドポイントによって通信に使用される可能性のあるファブリック経由のパスすべてと、各パスに配置されているデバイスを特定します。ここでは、シンプルなスパインリーフトポロジを取り上げます。各リーフスイッチを 4 つのスパインスイッチに接続して、リーフ間の相互接続を実現するものです。

エンドポイントの 1 つがスイッチ「leaf5-ex」上にある場合は、まず「show ip route」を使用して他のエンドポイントの宛先となっている仮想トンネルエンドポイント（VTEP）を特定します。そのうえで、VTEP に到達するために利用できるアンダーレイ ルーティング パスを特定します。トポロジがシンプルであれば、どのデバイスがエンドツーエンドパスの一部なのかは明らかです。はっきりしない場合は、Cisco Discovery Protocol（CDP）または Link Layer Discovery Protocol（LLDP）のネイバーの詳細を使用することで、中継デバイスのデバイス ID とホスト名を特定できます。

図 2：パスとデバイスの特定

図 2：パスとデバイスの特定

トポロジによっては、関連するすべてのデバイスとパスを特定するために、上記のプロセスを複数回繰り返す必要があります。目標は、エンドポイントが接続されているリーフスイッチ、エンドポイントを相互接続するスイッチ、利用可能なパスを構成するインターフェイスを特定することです。

次に、各パスに沿った全デバイスのコントロールプレーンのルーティングおよび転送の状態が適切であることと、データプレーンの状態と整合性が取れていることを検証する必要があります。各デバイスに接続し、ルーティングプロトコルの状態、ルーティング情報ベース（RIB）の状態、スパニングツリーの状態、インターフェイスの状態、正常性など、さまざまな要素を確認しなければなりません。また、整合性チェッカー（NX-OS に組み込まれているロジック）を 1 つ以上実行する必要がある場合もあります。これにより、コントロールプレーンが認識している転送状態が、転送情報ベース（FIB）や、ASIC ハードウェアにプログラムされている他のハードウェアテーブルと整合性が取れていることを確認します。ですが、この検証方法は時間がかかるうえにエラーが発生しやすいものです。もっと簡単な方法はないものでしょうか。

簡単な方法

実は、もっと簡単な方法があります。Nexus Dashboard Insights には強力な接続性分析ツールが備わっているため、ネットワークファブリック内の 2 つのエンドポイント間のエンドツーエンドパスを検証する際に手間のかかる作業を行う必要がなく、人的エラーが発生しません。接続性分析ツールを使えば、最新の診断機能をすべてのファブリックデバイスに対して実行できます。必要な操作は最小限です。また、ターゲットエンドポイントが接続されているリーフスイッチと、エンドポイント間で利用可能なすべてのパスを特定することが可能です。さらに、コントロールプレーンとデータプレーンの状態が有効で整合性があり、関連するすべてのデバイスを介したエンドツーエンドのネットワーク接続を実現できていることも確認できます。

注：Nexus Dashboard Insights バージョン 6.0 以降では、NX-OS ベースのファブリックについて接続性分析ツールを使用できます。今後のリリースで、アプリケーション セントリック インフラストラクチャ（ACI）のファブリックに対応した同様の機能が導入される予定です。

接続性分析ツールは、エンドツーエンドのネットワーク状態を検証するだけではありません。パス内のすべてのネットワークデバイスを示す直感的なパスビューを生成し、ターゲットエンドポイント間の正常な通信に影響を及ぼす可能性がある問題を強調表示します。

図 3 は、Nexus Dashboard Insights を開いたときのメインの [接続性分析（Connectivity Analysis）] 画面です。これまでの分析ジョブの概要と現在のジョブの状態（[完了（Completed）]、[失敗（Failed）]、[進行中（In Progress）] など）が表示されるほか、新しい接続性分析ジョブを作成するためのボタンがあります。もちろん、Representational State Transfer（RESTful）API を使用して新しい分析ジョブの作成を自動化し、ステータスを確認することもできます。

図 3：Nexus Dashboard Insights の接続性分析ツール

図 3：Nexus Dashboard Insights の接続性分析ツール

先に挙げた例であれば、既知の送信元エンドポイントと宛先エンドポイント間の問題をデバッグしようとする場合、新しい接続性分析ジョブを作成して、送信元 IP、宛先 IP、VRF 情報を入力するだけです。このツールは、仮想拡張 LAN/イーサネット VPN（VXLAN/EVPN）フローと「従来型」のレイヤ 2 またはレイヤ 3 フローの両方を分析できます。また、実行する分析のモードとして [クイック（Quick）] と [フル（Full）] のどちらかを選択できます。図 4 は、[接続の分析（Analyze Connectivity）] 画面です。必要な情報を入力すると、さまざまなジョブオプションを制御できます。

図 4：接続性分析のユーザー入力

図 4：接続性分析のユーザー入力

[クイック（Quick ）] モードの場合、基本的なコントロールプレーンを検証し、すべてのオーバーレイルート、アンダーレイルート、インターフェイスを含む関連デバイスの正常性を転送します。また同時に、送信元と宛先間のパストポロジを可視化します。[フル（Full）] モードの場合、さらに複数のチェックが実行されます。関連するすべての転送テーブルでのソフトウェアとハードウェアの転送状態の間の整合性に関する包括的な分析などです。

図 5 の画面には、完了したジョブの概要、送信元と宛先の間のすべてのネットワークデバイスとパスのトポロジビュー、ジョブの詳細を含むすべてのイベントログが表示されています。

図 5：完了した接続性分析ジョブの概要

図 5：完了した接続性分析ジョブの概要

任意のネットワークノードをダブルクリックすると、デバイスの詳細が表示されます。図 6 の画面は、概要データ、パス情報、関連するインターフェイスの詳細情報などを含む詳細ビュー（この例のデバイスは「spine2-fx2」）です。分析の一環として実行された各検証チェックの説明と状態も表示されています。

図 6：各スイッチのジョブの詳細

図 6：各スイッチのジョブの詳細

上記の例では、問題は発見されませんでした。もし 1 つ以上のノードでジョブに問題が発生している場合は、障害と影響のあるデバイスの詳細がすべて表示されます。たとえば図 7 の画面には、スパインノードのソフトウェアの状態とハードウェアのプログラミングの間に不整合が検出され、失敗したジョブが表示されています。

図 7：接続性分析問題の検出

図 7：接続性分析問題の検出

障害が発生したノード（spine1-fx2）をダブルクリックすると、障害の原因を確認できます（図 8 を参照）。見ると、コントロールプレーンのルートがハードウェアに正しくプログラムされておらず、不整合が発生していました。障害が発生しているのはスパインノードであり、こうしたプログラミング障害は散発的な問題につながる可能性があります。他のスパインノードにハッシュするフローについては、パフォーマンスへの影響はありません。ただ、誤ってプログラムされたスパインにハッシュするフローはブラックホール化する可能性があります。

図 8：障害が発生したノードの詳細

図 8：障害が発生したノードの詳細

こうした状況を明らかにすることで、大規模なファブリックで生じた転送問題の根本原因分析に要する時間を大幅に短縮できます。Nexus Dashboard Insights のオプションを使用すれば、ファブリックから詳細なテクニカルサポートデータを収集し、数回クリックするだけでシスコの確認用にデータをアップロードできます。ローカルまたは Cisco TAC で問題のトリアージを行ってから解決にあたるため、時間と労力が大幅に軽減されます。

重要なポイント

パフォーマンスの問題やパケット損失が発生しているエンドポイント間のエンドツーエンドのパスについての検証は、従来エラーが発生しやすいうえに時間のかかる作業でした。ですが、Nexus Dashboard Insights が提供する接続性分析ツールを使えば、作業を簡略化して効率を上げることができます。重要な情報をいくつか入力するだけでよく、後は接続性分析ツールが手間のかかるタスクをすべて処理します。具体的には、分析対象のエンドポイントが接続しているリーフスイッチを特定し、エンドポイント間で利用可能なファブリック経由のパスを検出して、関連する各デバイスとパスの正常性と整合性を検証します。

こうして得られたデータを利用すれば、ネットワークに問題があるのではなく、ホストまたはアプリケーションで問題が発生している可能性が高いことをすぐに証明できます。仮にネットワークに問題が存在する場合でも、問題の正確な性質と関連するデバイスを特定することが可能です。また、Nexus Dashboard Insights の追加機能を使えば、ログやその他のテクニカルサポートデータを簡単に収集して、Cisco Intersight Cloud 経由でシスコの確認用にアップロードできます。これで、これまでになく簡単にネットワークの問題を追跡し、迅速に解決できるようになります。

リソース

本ブログ記事で取り上げたテクノロジーの詳細については、以下を参照してください。

 

Tags:
コメントを書く