Q1.debug capwap console cli コマンドはあまり馴染みがないのですが、これを使わなければ解析できない問題があるのですか？
A1. debug capwap console cli コマンド自体は、debug コマンドではなく単に LightWeight AP でconfig モードに入れるようにするためのコマンドとなります。Config モードに入ってログ取得のための事前準備コマンドを入力頂くために必要なコマンドになります。
Q2. FlexConnect の Local Switching の場合は、WLC 接続ポートでの有線キャプチャは必要無いように思えますが、取得する必要性はありますか？
A2. FlexConnect の Local Switching の場合でも、802.1x 認証は WLC 経由で実施されますので、WLC 接続ポートでのキャプチャも必要です。ただ、FlexConnect Group を使用して 802.1x認証を AP と Radius で実施する場合は必要ないかもしれません。
Q3.無線キャプチャは Wireshark では駄目なのですか？
A3. まず、OmniPeek でのパケットキャプチャと Wireshark のパケットキャプチャ の違いを説明します。
OmniPeek では無線APには接続せずに、空間上に飛んでいるあるチャネルのフレームを全て取得する事ができます。このため、AP が送出する Beacon などもキャプチャすることができます。
一方 Wireshark は OmniPeek の様な使い方はできず、Wireshark がインストールされた端末が送信/受信しているフレームのみを記録することができます。
Wireshark のログだと、例えば無線端末側の問題で、あるフレームが Wireshark に記録されていなかったとしても、その原因が、AP が 送出していないのか、端末側の問題で端末側が受け取れていないのかが判断出来ません。
Q4. show run-config 内に show time は含まれないのですか？
A4. 残念ながら含まれていませんので、ログを取得する時は show time も合わせて取得をお願いします。
Q5. 無線キャプチャの解析の時に使用する BSSID をキャプチャから知る方法を紹介していたが、WLC 側のログから知ることはできますか？
A5. WLC の show client detail <MAC Address> に接続している無線AP の情報が表示されます。また、debug client でも、Association シーケンスの際に どの AP に端末が接続したかが分かります。
Q6. 解析に使う Wireshark の推奨バージョンは？
A6. 推奨するのは難しいです、なにかの不具合があるかもしれないですし。私が使用しているWireshark の Version は 1.4.0 で今回の資料を作成するために取得した画面キャプチャもこのVersionのものです。
Q7.無線キャプチャは、Omnipeek を推奨していますが、当社はAirmagnet しかありません。Airmagnet で取得した無線キャプチャもTACで解析してもらえるのでしょうか？
A7. Wireshark で開けるファイルでご提供いただければ、ご対応いたします。
Q8. AP - WLC間の CAPWAP通信を暗号化する設定をしていれば、パケットキャプチャを取得しても解析は無理なのでしょうか？
A8. 確かに解析は難しくなりますが、ご紹介したように、500 byte, 1000 byte ping を定期的に実行することで、どの暗号化された packetが pingかを判定することが出来るなど、packet種別を推測できることがあります。重要なのは、有線・無線キャプチャ PCと WLCの時刻を正確に合わせていただき、show timeコマンドなどで、ログ取得の際の各作業実行時刻を記録するなど、
複数のログを組み合わせて解析できるようにしていただくくことです。
Q9. APへのTelnet/SSHはデフォルト無効になっていますが，障害対応を考えると，デフォルトONにしたほうがよいでしょうか？
A9. 障害時にタイムリーにログ取得できるようにしておくという観点では、デフォルトでAP へのTelnet/SSHを有効にしておいた方がよいです。
ただ、ネットワーク運用ポリシーにも依存するかと思いますので、エンドユーザ様とご相談の上ご判断いただければと思います。
Q10. deauth(デオウス)は正常な動作ですか、それとも異常を示すものですか？
A10. deauthentication frameだけを見ても正常異常の判断をすることは出来ません。前後のフローを見て判断する必要があります。
Q11. debug client コマンドは稼働中のWLCの稼働に極端な負荷を与えますか？
A11. debug client は、特定クライアントに対して、無線接続時のイベントに関するログのみを出力させるコマンドとなり、運用に影響を与えるほどの負荷がかかるものではありません。これまでも多数のお客様環境で問題なく取得いただいた実績があるDebug となります。
Q12. 解析結果は分かったのですが、どうやって対処したのかがわからないです。 クライアントのファームアップなどで対応するのですか？
A12. 紹介したケーススタディの内容は無線端末側の問題でしたので、クライアントPC でのドライバーアップグレードで解決いたしました。
Q13. 最後のケーススタディの例は，クライアントが「たまに」MSG4を新しい鍵で暗号化するということが原因だったということですか？
A13. まず、発生頻度ですが、先ほどご紹介したケースでは、WPA2-Enterprise の再認証のタイミングで必ず発生する障害でありました。
原因はご質問いただきましたとおり、クライアントがEAPOL MSG 4 を新しい鍵で暗号化してしまっていたことであり、ドライバアップグレード
で解決しました。
Q14. PoEで接続しているAPが正常に動作しない場合があったのですが(SW再起動で回復)、APへの電源共有に関する情報を確認するコマンドはございますでしょうか？
A14.WLC から確認する事はできませんが、PoE スイッチが弊社の Catalyst スイッチの場合、show power inline コマンドにて、どのポートでどの程度の電力を供給しているかを確認できます。CDP 有効の場合は AP の hostname 等も表示されます。
Q15. 802.11nを使用した際の、帰属クライアント限界数及び同時接続クライアント限界数の目安を教えて下さい。
A15. クライアント最大接続数 は、下記 Configuration Guide で記載しております。
<http://www.cisco.com/cisco/web/support/JP/docs/WL/WLLANCntrller/5500WLCntrllers/CG/002/cg_controller_setting.html?bid=0900e4b182c27983#pgfId-2335394>
集中管理型の 802.11n 対応 AP の場合、無線インタフェースごとに200台まで接続可能で、2.4GHzと5GHz の両インターフェース合計では 400台まで接続可能になります。
ただ、基本的な考え方としては、接続数が増えるのにつれて、クライアント毎の通信パフォーマンスが落ちていきます。接続できるということと、快適に通信ができるということは異なるものと捉えていただくのがよいと思います。
Q16.大きなデータサイズのファイルを多人数でダウンロード等チャネルの利用率を高騰させる状況があった場合、キャプチャによってどういう状況が起きていることうを確認するのが有効でしょうか？
A16. チャネルの利用率高くても、それ自体は問題ではありません。問題が発生している場合は再送（リトライ）が多発していないかなどに着目しキャプチャを確認されると良いと思います。
Q17. 無線端末から接続切断しても WLCでのコネクションは残ったままで、即時削除しないのですが、キャッシュなど理由があって持ったままなのでしょうか？
A17. はい。集中管理型(WLC)をご使用の場合は、端末から接続を切断しても無線端末の情報は残ります。Idle Timeout (Default:5分) が経過した後、 WLC からもその端末の情報が削除されます。
Q18.無線パケットキャプチャー時にCRCエラーが多く発生することがあります。OmniPeek側の問題や環境問題、AP（クライアント）の故障の可能性があると思いますが、WLCのログなどから環境問題の有無を確認する方法はあるでしょうか？
A18. Rogue AP(不正AP) を検知した Trap が多い場合や、Clean Air で干渉源を検知したTrapが記録されているような場合は、電波環境が悪いことが推測できます。
Q19.debugを掛けた際にWLC、LAPがパフォーマンス不足に陥る様なことはないのでしょうか？
A19. 仕掛ける debug コマンドの種類や数によります。例えば WLC での debug client は運用に影響をあたえるほどの負荷は発生しませんが、ケーススタディでご案内した AP の debug コマンドは大量のログが生成され、パフォーマンスに影響をあたえる可能性があります。
Q20. 無線経由でユーザがシンクライント接続を行っています。通信が遅い等の申告を受けた場合、なにが起きていることを解析するのが有効でしょうか？
A20. まず、その問題が無線経由でのみ発生するかどうかをご確認頂くのが良いと思います。無線経由でのみ発生するのであれば、有線キャプチャと無線キャプチャを取得し、有線キャプチャではシンクライアント通信のシーケンスで問題が発生していないか、単位時間あたりの該当端末とのパケット数と問題事象発生のパケット数を比べて違いが発生していないか。問題や違いが発生していれば無線キャプチャ上で再送やCRCエラーがその時間帯に多くないのかなど、順々に切り分けていくと良いと思います。
Q21.P.66 端末側の調査を実施したとのことでしたが、具体的にどのような調査手法で原因を特定できたのでしょうか？
A21. 端末側では Debug 用の Driver を作成し、その Debug Driver で調査を実施しておりました。
Q22.今回のトラブルシュートで色々な箇所でログを取得しておりますが，NCSの導入により，どれほどの工数削減が期待できますか？
A22. NCSの導入で日々の運用管理に対する工数削減は期待できるかと思います。ただ、NCS で debug や キャプチャ は取得することができないため、詳細な解析が必要な事象に関しては NCS 以外のWLC や AP, 各種キャプチャ等での解析が必要になります。
