ND Insights 活用術: 相関分析によるトラブル解析

[Daijiro Kido]

※この記事には Cisco 非公式の情報が含まれます。製品のご利用にあたりましては必ず公式なドキュメント、ガイド、データシートなどを参照いただき、本記事との差異がある場合は公式の情報を優先して下さい。

※本記事はドキュメント投稿時、または、更新時時点の情報に基き掲載されています。最新の情報は掲載時点から変更されている場合がありますので、製品のご利用にあたっては必ず最新の公式の情報をご参照ください。

• 活用シナリオ
• 課題
• ND Insights の活用

NDI version: 6.0.2 , ACI / NDFC 共通

活用シナリオ

特定のアプリケーションにおいて、一部のユーザからアプリケーションが使用できなかったという申告が多発しており、ネットワーク管理者にてネットワークの正常性の確認が必要な状況。

• 申告内容より問題が発生した時刻は午前9時から午前10時であることを確認
• 調査開始時点ではアプリケーションおよびネットワークにトラブルなどは発生していない状況
• アプリケーションのアクセスログなどを確認しても、エラーを示すものはないが、アクセス数が極端に減少していることが判明
  
  

課題

アプリケーションへのアクセス自体が不可となるようなトラブルが発生した場合、ネットワークトラブルが最も可能性の高い被疑としてあげられれます。ネットワーク管理者としてはそのトラブルに全く心当たりがなくても、異常とその原因を特定するまでは継続して緊急対応を取らざるを得ないケースがあります。

異常を迅速に特定し、その異常に関連しそうなイベントの分析し、いかに迅速に原因特定に至ることができるかがネットワーク管理者にとって重要な課題となります。

•  
• 数少ない情報の中からネットワーク全体の変化、異常の有無をどのように確認していくのか
• ネットワークの異常や変化を捕捉した際、その原因をどのように特定することができるか
• 複数のネットワーク変化が同時に発生しているような状況で、各イベントをどのように関連付け、どのように時系列で整理できるか
• 外部起因で引き起こされたネットワーク変化について、内部にその原因がないことをどのように証明できるか
  • DDoS アタック
  • 外部ネットワーク接続機器、中継機器故障
  • ルーティング、DNS トラブル

ND Insights の活用

異常発生有無の確認

• 問題発生時刻である 9:30 の前後 30分に解析範囲を絞り込み、異常(Anomaly)発生状況を確認
  問題の時間帯では Flow Drop のイベントが発生しており、問題のアプリケーションの通信が影響を受けていることを特定
  
  

  ポイント	設定した時間帯に発生していた異常をすべて確認することができる。トラブルが発生していた可能性の高い時間帯をできるだけ狭く絞り込み、該当する異常が確認できない場合は徐々に時間帯を広げていくような調査が可能。

相関分析による被疑の特定

• トラブル発生に関連するイベントの確認
  上記の Anomaly イベントをダブルクリックすることで Anomaly の詳細を確認することが可能
  Mutual Occurrences から問題の Flow Drop が発生した時刻周辺の異常イベントを確認する
  ここでは問題発生と同時に Fault 異常が発生していることを確認
  
  

  ポイント	ND Insights で確認できるすべての Anomaly に対して Mutual Occurrences (相互発生イベント)が確認でき、ある異常に対するネットワーク全体の関連イベントを素早く追跡しくことが可能

• 関連イベントの確認と被疑の特定
  ここでは問題の事象に関連して発生した Fault イベントから、BGP ダウンが発生していたことがわかり、これにより通信断が引き起こされたと特定することが可能
  (実際には問題の BGP ピアで交換されている経路情報に、通信ホストを含む経路があることを確認する必要がある)
  
  
  
  

  ポイント	Anomaly と Fault はどちらも異常を示す可能性が高いイベントになるが以下の違いがある Anomaly: ND Insights が保持する情報を分析し、総合的に異常と判断しているイベント Fault: APIC/NDFC もしくはスイッチが単独で異常と判断しているイベント

• Fault (BGPダウン) の原因分析
  該当する Fault から Fault Details 画面を開くと、Fault の詳細とそのイベント周辺の Timeline が確認できる。
  Timeline からは Fault 直前になんらかの設定変更作業が実施されたことがわかるが、そのイベントオブジェクトは明らかに BGP ダウンとの関連が低いことがわかる。つまり、問題の BGP ダウン周辺時間帯には何もネットワークの変化がなかったことがわかり、実際にこの BGP ピア対向側の機器 (管理外ルータ)にて BGP 閉塞作業を実施していた。
  
  
  
  

  ポイント	この事例は、問題のアプリケーションのパフォーマンス低下はネットワークトラブルに起因によるものであることと、ほぼ同時にネットワーク管理者の責任外のトラブルであることがすぐに特定できる。従来のトラブルシューティングの方法では、ネットワーク管理者としても自己の責任範囲外で発生したトラブルであることの証明が難しく、管理外機器と連携した原因特定まで、長時間疑いが晴れない状況下に置かれる場合がある。