NWインフラに関する問題点、課題の迅速な発見手順を確立
[1] ITシステム全体を網羅的に試験
[2] 被疑機器については、試験間隔を短くした試験の実施
[3] 短い間隔でのトラフィック調査
[4] トラブル時にパケットキャプチャーのsnap shot （データの保存）とそのデータの分析
[5] パケットキャプチャーのバリエーション
[6] まとめ

１．ITシステム全体を網羅的に試験

　ITシステム全体を網羅的に試験を行います。 約１分に1回の試験で、良し悪しが分かります。
　多くの機器の監視により、共通部分のトラブル、単体の機器のトラブルかの切り分けが可能となります。
　EEC(End to End Checker）は、通常HUB拠点（サーバがあるDCやFWを配置しているようなロケーション）に設置します。
　必要により、拠点に設置する場合もあります。

　

登録グループ例
登録Aグループ
システム全体を鳥瞰図的に把握するため、拠点のRouterを登録します。（ping試験）
遅延値で違いがある場合は、別グループに登録します。 例：国内、国外 等
登録Bグループ
クローズド網にあるサーバのWEBサーバに対して、 http or https 試験を行います。
登録Cグループ
クローズド網にあるWEBサーバ以外のサーバに対して、port 試験を行います。
登録Dグループ
FWを超えたサイト（InterNet上）のWEBサーバ、及びクラウドのWEBサーバに対して、http or https試験を行います。
登録Eグループ
敷地が広い工場のSwitch 及び、Wifiを利用している

２．被疑機器については、試験間隔を短くした試験の実施

　次に示しますのは、ある機器について、約１分間に１回 ping試験を行った例です。

　あるお客様の例
　2024/08/19(月) 08時台 約１分に１回の試験
　
　１分間に１回程度の試験では、該当の分の試験が遅いと、100%遅いの表示になります。

【グラフの解説】
　上のグラフは、08時台に、約１分に１回試験を行った結果のグラフです。
横軸は、0分 ～ 59分を示します。
　22分台は、遅かったので、紫色となっています。
　27分台は、少し遅かったので、緑色となっています。
　40分台は、普通だったので、青色となっています。
グラフは、100%表示になっていますので、約１分に１回の試験では、0% か 100% と 粗いグラフになります。

　2024/08/19(月) 08時台 試験間隔を短くした場合
　
　試験間隔を短くすると遅延の細かい分単位の識別が可能です。
　この例では、１分間に１回の試験では分からなかった timeout の状況も明らかになっています。

【グラフの解説】
　上のグラフは、上述の約１分に１回の試験を行った同じ時間に、短い間隔で試験を行った結果のグラフです。
横軸は、0分 ～ 59分を示します。
　23分ごろは、約20%が、赤のtimeout、約60%が、紫の遅い、約18%が、緑の少し遅い、約2%が、青の普通となっています。
　試験間隔を短くすることにより、利用者の体感に近い状況を把握することが可能です。
　※短い試験を行っても、通常の機器は、多い時で、１秒間に、３万パケット程度の処理を行っていますので、数秒に１回のping試験の影響はほとんどありません。

　試験間隔を短くして分かること　（データは、100Mbps のギャランティー回線を利用されている例です）
　以下に示すのは、あるお客様のEECの試験結果、トラフィック状況を示した例です。
　・エンドユーザ様の使い勝手の体感を把握することができます。
　・回線の逼迫状況明確になります。
　
【グラフの解説】
　トラフィックのグラフを見ると ８時、10時、16時に 100Mbps 近くの in のトラフィックがあることが分かります。
　この時間帯のEECの試験結果を見ると、
　10時台は、赤の timeout の割合が多くなっています。８時台、16時台の timeout はそれ程多くないため、
　エンドユーザ様の使い勝手は、10時台は非常に悪かったことが分かります。
　※一番下の、トラフィックの拡大を見ると、10時台は張り付き、８時台、16時台は、張り付きが弱いのが分かります。
　このように、EECの試験結果を見るだけでも、回線の逼迫状況も把握することができます。

３．短い間隔でのトラフィック調査

　5分平均、10分平均のトラフィックデータでは、実態を把握できない場合があります。
　EECでは、試験間隔（平均）を自由に設定できますので、1分平均のトラフィックデータや、30秒平均のトラフィックデータも取得が可能です。
以下に示すのは、あるお客様のトラフィックデータを示します。
　

【グラフの解説】
　左側のグラフは、日のトラフィックデータです。右側のグラフは、7時台のトラフィックデータです。
　上から、1分平均、5分平均、10分平均のグラフです。
　左側の日のデータは、どの平均でも同じようなグラフの形となっています。
　右側の7時台のデータを見ると、かなり違いがあります。
　10分平均の 7時台のMaxは、57.7Mbps と 100Mbps よりかなり少なくなっていますので、このデータを見ただけでは、回線帯域に余裕があると間違った判断をする可能性があります。
　1分平均のデータでは、Max 96.2Mbps であり、かなり 100Mbps に近づいています。
　WEB会議では、短時間のトラフィック集中でも、通話の途切れになる可能性があるので注意が必要です。
　ITSCでは、エンドユーザ様の体感を把握するため、5分、10分の平均でなく、1分平均のデータの取得を推奨しています。

４．トラブル時にパケットキャプチャーのsnap shot （データの保存）とそのデータの分析

　EEC(End to End Cheker）では、パケットキャプチャーを取れる設定*をして頂ければ、パケットキャプチャーを連続して取得することをお勧めしています。
*パケットキャプチャーのデータを取得するには、お客様機器において、ミラーポートの設定が必要です。Switch or Router のお客様装置に 数行の cofig を追加することにより実現可能です。

　週明けの月曜日（月曜日が祝日の場合は火曜日）にトラフィックが増加することが多いため、EECでは、Default で、この日に snap shot（パケットキャプチャーのデータの保管）を実施し、packet推移のグラフを作成することにしています（自動化処理）。
　以下の例は、あるお客様の 2024.9.2（火）の packet推移のグラフです。
　

　連続取得している過去のパケットデータ 5世代＋0世代（現在取得中）の全パケットデータについて、パケット数の多い TOP 10 の機器について、パケット数の推移のグラフを表示します。
　発IP、着IPのどちらも表示が可能です。

　パケットデータは、5世代＋0世代（現在取得中）が保存されていますので、検索したい時間帯にフォーカスして分析することが可能です。
以下の表は、2024-09-02 08:47:00 ～ 08:47:28 【 28 秒 】 の詳細データです。
　

以下の表は、更に、Zoomの機器で絞り込んだ詳細データです。
　

　この時間帯は、23名の方が、Zoomを利用されていることが分かります。

５．パケットキャプチャーのバリエーション

　トラブルの原因究明に有効な手段として、パケットキャプチャーがあります。
パケットキャプチャーは、事前にRouterや、Switchにて、ミラーポートの設定が必要です。
　ミラーポートの設定後、パケットキャプチャーができる環境が整ったことになります。
【通常のパケットキャプチャーの取得手順】
① 技術者による事前準備
　お客様の環境に合わせて機器の設置の準備が必要です。
　パケットキャプチャーを実施する時間、取得するパケット量を決める必要があります。

② 現場における機器の設置
　技術者による設置が必要です。パケットキャプチャーが取得できているかの確認が必要です。

③ 調査の実施

④ 現地のおけるデータの回収
　技術者が現地に赴き、データが取得できているかの確認が必要です。
　取得しているデータのコピー。
　パケットキャプチャーデータ量は膨大ですので、データのコピーが現実的でない場合があります。
　その場合は、取得したデータが保存されている機器自体を回収します。

⑤ 取得したデータの分析

①～④を実施した後に、ようやく、⑤の分析ができることになります。
この方法が一般的ですが、調査までにかなりの日数と、どうしても技術者による、設置・データ取得の確認が必要となり、コストがかさむことになります。

【ITSCで行っている手法】
◇ 工夫その１：分析までの時間の短縮

　現地に設置する調査機（EEC：End to End Checker）とITSCのリモートセンタ間のセキュアなRemoteコラボレーション機能を実現しています。
通常、調査機は、お客様の閉域網内に設置しますので、外部のセンターから、現地設置の機器に loginをすることができません。
ITSCでは、httpsのプロトコルのみを用いて閉域網内に設置した機器とのコラボレーションを実現しています。

　Remoteコラボレーション機能により、上記の通常手順の ②～④ を 省略することが可能となりました。

◇ 工夫その２：トラブル時のデータの適格の取得
　パケットキャプチャーデータは、膨大なため、トラブルがあった時間帯のデータを取得するには工夫が必要です。
EEC(End to End Checker) では、データの取得方法を選択することが可能です。
(a) 時間を指定して、パケットキャプチャーの取得を開始する。
(b) EECでは、遅延監視も行うことができますので、遅延が発生した時にパケットキャプチャーの取得を開始する。
(c) お客様が必要と感じた時にWEBブラウザ上（EECにアクセス）で、ボタンを押すことにより、パケットキャプチャーの取得を開始する。
(d) snap shot（パケットキャプチャーの過去のデータを保存）を利用する方法
　連続してパケットの取得を行い、過去のデータを５世代常に保管しておき、トラブルが発生した時、
snap shot（パケットキャプチャーの過去のデータを保存）を実施します。
参考ページ：連続してパケットの取得の機能を追加 ←をクリックすると別タグのページが開きます。

(d) の方法は、大変有効で、トラブルの原因究明に大変役立つ機能となっています。
　　

６．まとめ

　2003年から開始した、NWシステムの見える化の業務の知見から、トラブルの原因や潜在故障の発見のための、
『NWインフラに関する問題点の迅速な発見手順』を確立しました。
　[1] ITシステム全体を網羅的に試験
　[2] 被疑機器については、試験間隔を短くした試験の実施
　[3] 短い間隔でのトラフィック調査
　[4] トラブル時にパケットキャプチャーのsnap shot （データの保存）とそのデータの分析
を実施し、
　・EECの試験結果
　・トラフィックデータ
　・packet推移のグラフ
を分析することにより、トラブルの原因を明確にしていきます。
　更に、トラブル時に、snap shot（パケットキャプチャーのデータのcopy）を取ることにより、トラブル発生時のパケット状況を調査することが可能です。

パケットキャプチャーデータは、膨大であり（何十Gbyteにもなる）、トラブル発生時のデータの保存には課題がありました。
EECでは、パケットキャプチャーデータを常に保存（5世代＋0世代[その時点の最新packet])し、トラブル時にパケットデータをcopyすることにより、トラブル時のデータの保存が可能となりました。

よくあるケースとして、トラブルの時に データが残っておらず、状況把握ができないケースがあります。
トラブルの報告ができず、復旧にも時間を要す場合があります。

　情報システムのトラブルは、お客様の経営に大きな影響を及ぼします。
ITSCでは、トラブル時には、迅速に原因を究明し、日常は潜在トラブルの発見に努め、常にお客様のITインフラサービスの品質を向上させる仕組みの提供を続けて参ります。