「リモートデスクトップの操作が遅い!」の原因を高速特定!ntopngによる輻輳原因の究明アプローチを実例でご紹介

本ブログでは、実際に弊社メンバーから不具合報告としてあがった「リモートデスクトップが遅い」といった事象をntopngで迅速に特定したという実例をご紹介したいと思います。

本記事でご紹介する4ステップの調査で、所要時間10分以内に問題事象を把握できております。是非ntopngの活用方法として、ご一読いただければ幸いです。

文:ジュピターテクノロジー よしひろ

不具合発生

当方が所属するネットワーク監視製品プロダクトグループでは、メンバー間のコミュニケーション手段としてSlackを利用しています。

在宅勤務をしているメンバーから以下のような報告がありました。

「朝9時から11時の間、リモートデスクトップ(以降、RDP)がつながっているが、操作が非常に遅い・・・」

メンバー自身が調べたところ、以下までは調査・把握しておりました。

事象: RDP遅い

  •  自宅シンクラ端末→VPN→RDP対象PC。Ping応答時間大、タイムアウト多発
  •  自宅シンクラ端末→VPN→Fortigate2(以降、FG2)。Ping安定

といった内容でした。

また、「経路がわからず普段使っているNMSでボトルネック見つけられないので、経路間のネットワーク機器について情報システム部門にご相談したい。」といった内容もございました。

当方は情報システム部門ではないのですが、お客様へのプレゼン用途で上述のトラフィックが流れる環境にBluevault ntopng Enterprise io-B製品を仕込んでおり、原因特定に動きだしました。

調査ステップその1:調査対象環境を知る

ネットワークの調査は、当然ですがその環境を把握していないと困難となります。そこで、今回不具合となった環境を読者の皆様にもイメージして頂きたく、図1を作成しました。

不具合の遭遇したメンバーは、図1右上「シンクライアント端末」からFG3にIPsec VPNを張り、次にRDPで自席にあるDEFビル内のPCに接続しております。

RDP自体は接続できたにも関わらず、マウス操作といった通常のPC操作が非常に重く仕事に支障が出ているとの報告がありました。

図1 社内環境イメージ

調査ステップその2:報告内容にそってntopngでトラフィック量を確認する

図2 障害発生時のトラフィックグラフ

朝9時から11時の間の実際のトラフィックグラフです。確かに、8:30から最大278Mbpsを利用していますが、弊社LAN環境は1Gbpsのはずです。

こちらの図2だけでは、遅延が起きているとは断定できませんでした。

調査ステップその3:遅延の有無をActive Monitorで確認する

ntopngは、Active Monitorという機能があり、対象IPアドレスに対してHTTP/HTTPS, ICMPといったプロトコルを用いて定期的に応答時間の測定を実行する設定が可能です。

図1の[Active Monitorルート1]を設定していたので、遅延グラフを参照してみました。

図3 Active Monitorルート1の遅延状況

図3の通り、メンバーから報告のあった時間帯に最大10秒の応答遅延が発生しています。これで、メンバーの報告通りの時間帯に応答遅延が発生していたといった事実が分かりました。

また、上記の情報とメンバーの報告「自宅シンクラ端末→VPN→FG2。Ping安定」より、問題はRDP対象PCとFG1間にある可能性が高いといった予測が立てられました。

そこで、図1のL2以下にある島ハブで「誰が、何の通信を発生させていたのか?」を確認するために、トラフィックの中身をntopngで分析してみることにしました。

調査ステップその4:不具合発生時間のトラフィックの中身を確認する

図4 WUDO通信の確認

図4の通り、アプリケーション[WUDO]というのが、該当時間の43.2%のトラフィックを占め、合計バイトが24.58GBであったことが分かりました。

このWUDOの詳細を把握するために、図4右下のアクションボタンをクリックしたのが、次の図5です。

図5 rawフロー表示

図5はntopngの最大の特長である、rawフロー分析画面です。

WUDOの正体は、TCPの7680を使った通信のようです。

しかも、単一フローでスループット98.85Mbit/s、バイト633.34MB利用する非常に高コストな通信をLAN内で同じ時間帯に複数フローで発生していることが分かります。

つまり、図1配下の島ハブのPC間でこの[WUDO]のクライアント間通信が大量に発生していたことが輻輳の原因と特定できました。

このWUDOに関しては、マイクロソフトのサイト、「配信の最適化とは」を一読すると理解が容易です。インターネット通信を抑制するための機能のようですが、今回この仕組みによって複数のWUDO通信がLAN内のPC同士で発生し、L2以下の帯域を輻輳させたというのが今回の障害の真因です。

ここで、図1のL2をntopngのSNMP監視で監視していれば特定ポートのトラフィックの状態を監視できていたので、より明確な証拠を突き付けられたと思いますが、残念ながら該当のL2をSNMPで監視はしていませんでした。

しかし、上記の情報からntopngでの解析で必要十分であることがわかっていただけたのではないでしょうか?

是非、貴社のトラブルシューティングやトラフィックの見える化にntopngの採用をご検討ください!

ntop製品のお問い合わせ

ntop社製品にご興味のある方は、以下リンクよりいつでも弊社までお問い合わせください。

10分間機能制限なし!無償でご利用いただける評価版も以下のダウンロードリンクにご用意しております。簡単に検証が開始できますので、評価ガイド(PDF)を参考にぜひお試しください!

こんな記事も読まれています

最新記事

おすすめ記事

  1. 産業スパイを発見し、防ぐ方法とは

  2. Flexible NetFlowとは?を5分で理解する

  3. WinSyslog 使い方ガイド#2 受信時刻とデバイスタイムスタンプ両方を出力する

製品カテゴリー

JTC IT用語集
TOP