- ライター：力石 靖
- 2001年にネットワンシステムズに新卒入社。
入社時より、日本国内の無線LAN市場とともに歩む。
無線LAN製品担当、社内技術支援対応、および保守部門と渡り歩き、
プリセールスの技術支援からポストセールスまでの知識と経験を有する。
2021年現在は無線LANやクラウド技術を利用したサービスの開発、提案に従事。
目次
ネットワンシステムズ 力石（ちからいし）です。
無線LANのトラブルシューティングについて、３回目の記事です。
これまでにお知らせした内容は、次項のリンク先をご覧ください。
これまでの内容と今回の内容
第１回記事では、
「無線LANのトラブルシューティングには利用者・運用者それぞれの視点で見ることが必要」という点をお伝えしました。
第２回記事では、
「端末利用者の視点から見たトラブルシューティング」について、深掘りしました。
今回、第３回記事では
「システム運用者の視点から見たトラブルシューティング」について、深掘りします。
トラブルシューティングの考え方をまとめた図については下図をご覧ください。
図１：トラブルシューティングの視点と観点
無線LANシステム運用者の視点から見た、トラブルシューティングの流れ
前回お話しした通り無線LANのトラブルは端末側に起因したトラブルが比較的多いと言えますが、中には端末側での対処のみでは解決できない場合もあります。
今回はシステム運用者の視点で「状況の把握」について深掘りし「原因の特定」「対処の実施」につなげます。
大きな流れは今までと同様、下図の通りです。
図２：トラブルシューティングの流れ
無線LANシステムにおけるトラブル事例の紹介
はじめに、筆者がこれまでに経験した、無線LANシステムに関連したトラブルとして申告されたものうち、比較的見られた事例をまとめたものを下図にて紹介します。
図３：無線LANシステムにおける実際のトラブル事例
トラブルの把握と特定（無線LANシステムの視点）
それでは、先にご紹介したようなトラブル内容について、把握・特定するにはどのようなアプローチをとればよいでしょうか？
最初に言えることは、無線LANシステムにおけるトラブルシューティングにおいて、システム内の各機器で取得できるログ情報から有用な情報が得られる場合が多いという点です。
これらのログ情報を取得していくところから、システム側の調査を開始することになります。
取得可能な情報の例を下図に示します。
図４：ログの取得と得られる情報
システム内部のログ情報は、システムを構成する機器それぞれにある内部のメモリ領域に保存されることが多く、時間が経過すると古いものは削除されてしまいます。
従ってそれらログ情報が削除されてしまう前、トラブル発生中もしくはなるべく早い時期に情報を取得※１するのがポイント です。
※１：SNMPマネージャやSyslogサーバ等をシステムの外部に用意し、蓄積し後から見直すという手段もあります
さらなる情報収集手段としてご紹介するのは、トラブルが発生している時間帯にアクセスポイントからコントローラ間を流れる通信を
Wireshark等の通信キャプチャツールを用いて実際の通信内容を取得する※２※３という方法です。
こちらはログ収集よりも多くの手間がかかりますが、非常に有用な情報となります。
※２：Windowsでは、OS標準機能で無線区間のキャプチャを直接取得する手段がないため、（外部サイト）LiveAction社製のOmnipeekなど、対応した商用製品を運用者側で用意しておくと非常に有用です。
※３：MacやLinuxではOS標準機能で無線区間のキャプチャを取得方法が存在します。
（外部サイト）無線キャプチャ (OS X編)
（外部サイト）WLANトラフィックをdecryptする方法 - Cisco Community
図５：キャプチャツールによる通信取得ポイント
またメーカーにてトラブルシューティングの初期に取得してほしい情報を開示している場合もあります、合わせて確認しましょう。
ここでは、Cisco社にて公開している情報を紹介します。
（外部サイト）Catalyst 9800 シリーズのワイヤレスコントローラで取得すべき基本ログ ※現行世代のIOS-XE稼働機器向け情報
（外部サイト）WLCで取得すべき基本ログ ※旧世代のAireOS稼働機器向け情報
（外部サイト）“debug client” の解析方法 : 無線 LAN トラブルシューティング
トラブルへの対処（システム運用者の視点）
これまでに集めた各種の情報より、トラブル発生状況の特定および対処を行います。
無線LANシステム側にトラブルの原因がありそうだという判断ができた場合、もしくはトラブルの原因が絞り込めずに切り分けを実施する際、実施すべきトラブルシュートの選択肢は主に下図の通りです。
また、トラブルの発生した原因の詳細を追及する際、これらトラブルシュート対応の実施前に事象発生中の情報を取得し、メーカー等への問い合わせを行うことになります。詳細は次項にて解説します。
図６：システム側でのトラブル発生時における対処
迅速な回復・復旧と原因の詳細調査はトレードオフの関係
トラブルに見舞われた際、いかに迅速に回復・復旧させるかはとても重要です。
それに加え「このトラブルの原因は何なのか？」という詳細を調査する必要が生じる場合もあります。
このように原因の詳細を調査する際は、明らかにハードウェアの故障であるという以外、メーカーへの問い合わせや購入した販売会社への問い合わせを行うことになります。
問い合わせ時はこれまでにまとめたように「どのような事象が発生し、現在どうなっているのか？」を明確にメーカーや販売会社へ伝えねばなりません。
つまり事象発生時のログやデバッグで取得した情報といった、詳細な情報を随時提供することが必須となります。
下図に、提供をする情報の種類をまとめました。
図７：メーカー等への問い合わせ時に必要な情報例
メーカーや販売会社への問い合わせについて上記のような対応を繰り返すことになるため、原因追及の精度（より詳細な情報）を求める場合は、トラブル終息までの時間がより長くかかるという点は考慮しましょう。
また、原因の詳細を知るための調査を主目的とする際は、トラブルシュート対応で改善することが明確である場合であっても、その後の再現が見られない場合は詳細な情報取得が困難となり、以降の調査が継続ができないという事態になることが多い点にもご注意ください。
そのため、迅速な回復と原因の追及という２つの観点は基本的に相反するものであり、それぞれのバランスをとって対応していくことが重要となります。
図８：トラブル対応のバランス
まとめ
今回は無線LANのトラブルについて、システム運用者の立場における情報の深掘りと対処の考え方についてお伝えしました。
前回の内容である端末利用者の観点を合わせ、どのように情報を収集し、対処につなげていくか？という点を押さえられたかと思います。
まとめると以下の通りです。
- システム運用者の立場で最初に実施すること：ログ等の情報をなるべく事象発生中かログが残っている状況で収集する
- トラブルシュートで実施できることの紹介：機器の再起動、設定の確認、ソフトウェアのアップデートなどが実施できる
- 迅速な回復・復旧と原因の詳細調査はトレードオフの関係であり、バランスをとった対応が重要
上記を踏まえつつ、改めて本シリーズの核心であるトラブルの視点と観点の図を確認しましょう。
図９：トラブルの視点と観点
ここまで、多くの情報を集めたうえで対処を検討し、実施するという流れをたどりました。
やるべきことが多いな、と感じられているかと思います。
また、無線LANに関する知見や経験がないので、そもそも難しい！というのもあろうかと思います。
次回は、より容易なトラブルシューティングができるよう、メーカーで取り組んでいる内容をご紹介します。
引き続きお付き合いいただけますと幸いです。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
