[ご参加ありがとうございました] Ask Me Anything - 6/19 Wireless TAC Time フォローアップフォーラム

[Eri Mizuno]

6/30（日）で質問の新規受付を終了しました。多数のご質問ありがとうございました！

Ask Me Anything フォーラム　2024/6/12（水）～ 2024/6/30（日）

このフォーラムは、6/19（水） 開催のシスコ コミュニティライブ Wireless TAC Time - 今すぐ現場に効く Tips 紹介 - のフォローアップイベントです。このウェビナーの内容についてのご質問は、開始日の 2024 年 6 月 12 日（水）より 2024 年 6 月 30 日（日）までに投稿いただけます。ご質問できる対象範囲については下記をご確認ください。

対象範囲：6/19（水） Community Live 「Wireless TAC Time」より
[主なアジェンダ]
下記の製品に関する更新情報を提供します。ソフトウェア不具合、ハードウェアの更新、新機能、制限事項、ベストプラクティス、推奨するリリース情報、サードパーティ製品との互換性情報などが含まれます。
・Cisco Aironet/Catalyst Access Point
・AireOS Wireless Controller
・C9800 Wireless Controller
・Embedded Wireless Controller
・Cisco Wireless Phone

　　　 Ask Me Anything フォーラムイベントページへ戻る

 前回の Ask Me Anything フォーラムを見る

右下にある「返信」ボタンをクリックして質問を開始してください↑こちらは画像です。ボタンは右下にあります。

回答は、対応するエキスパートの状況で遅れる場合があります。また、対象外の質問にはお答えできないケースもあります。あらかじめご了承ください。

---

エキスパート紹介

大﨑 秀行（Hideyuki Osaki） - 在学研究中から UWB 車載レーダなどの無線開発に関わり、情報通信工学を修了。シスコシステムズに入社後はルータ、スイッチ、ブロードバンドルータなどのサポートを経てワイヤレス (Wi-Fi) チームに異動。一貫してワイヤレス製品のサポートを担当し、2 回のオリンピックパラリンピックの現地サポートおよびリード、SMB から国内外の中央省庁、海外エンタープライズなどの大障害サポートを多数経験。現在は Japan Wireless TACチームリードおよび CXC Technical Leader としてエンタープライズソリューション全体のサポートと、製品開発 BU との折衝の日々を過ごす。2023 年 4月「ネットワークエンジニアの教科書」を共著にて出版（Wireless セクションを担当）。

髙木 美沙（Misa Takagi） - シスコシステムズに 2021 年度の新卒として入社後、Japan TAC Wireless チームに所属。TAC エンジニアとして、クライアントに無線通信を提供するワイヤレス コントローラー Catalyst 9800 シリーズや、無線クライアントやアクセスポイントの位置情報を管理する Connected Mobile Experiences (CMX) などのワイヤレス製品で生じた障害のトラブルシューティングに従事。Cisco Community サイトにお問い合わせの多い障害に関連する不具合情報の記事を定期的に投稿し、問題解決に役立てていただけるような取り組みも行っている。

小林 昇斗（Shoto Kobayashi）- シスコシステムズに 2023 年度の新卒として入社。Japan TAC Wirelessチームに所属し、TAC エンジニアとして無線通信を提供するワイヤレス製品で生じた障害のトラブルシューティングに従事。より早く事象を解決し、お客様に満足いただけるよう対応のスピード、正確性を大事にしながら日々の業務に邁進中。
「ご質問いただけましたら、誠意をもって対応いたします！」

Look! 
書籍「ネットワークエンジニアの教科書」著者インタビュー＜Vol 3.エンジニア編 パート 2 ＞ もぜひご覧ください！

書籍紹介「ネットワークエンジニアの教科書」

上述　大﨑 秀行（Hideyuki Osaki） の他、シスコ TAC エンジニアが多数共著者として参画。前回第二版の公開から約 4 年、2023 年 4 月の刊行にあたり、約 1 年のプロジェクト期間を経てこのたび第三版を公開。現在好評につき増刷決定。働き方の変化のトレンドにも対応した内容となっており、ネットワークエンジニアだけでなく提案に関わる担当者にもお勧めとなっている。共同執筆者は下記のとおり（敬称略）。

・ルータ・スイッチ担当 中島 康裕 Yasuhiro Nakajima 山田 健斗 Kento Yamada 塩津 達郎 Tatsuro Shiotsu 張本 大成 Hironari Harimoto	・ワイヤレス担当 大﨑 秀行 Hideyuki Osaki	・セキュリティ担当 加藤 絢一郎 Kenichiro Kato 中村 隆之 Takayuki Nakamura
・データセンター担当 山本 大輔  Daisuke Yamamoto 梶浦 慶人  Keito Kajiura 細川 海人  Kaito Hosokawa 浅野 拓也  Takuya Asano	・モバイル担当 南部 泰亮 Yasuaki Nambu	・コラボレーション担当 吉永 祐亮  Yusuke Yoshinaga 佐藤 剛史  Takeshi Sato
・ネットワーク・マネジメント・システム担当 長尾 誠  Makoto Nagao	・ハードウェア担当 森川 寛之  Hiroyuki Morikawa 中村 忠司  Tadashi Nakamura	・オートメーション・オーケストレーション担当 岩本 彰  Akira Iwamoto
・テクニカルリード 小上 賢一  Kenichi Ogami ・プロジェクトマネージャー 竹内 ゆき子  Yukiko Takeuchi

For more information, visit the ワイヤレス section.
If you have any questions or technical issues with Cisco products, click here for additional information at no charge. Visit the シスコ コミュニティ page.

[H-Yoichi]

無線の運用においてよく聞くのが、現場から「うまくつながらない」「通信が遅い」と言った症状であると思ってます。ただ管理者が連絡を受けてから現地に行って調査を行って特に異常がなく原因不明、後日また同じ事象が再発して、を繰り返すと言った事を聞きます。

御社の製品において上記のような、事態を防ぐため常時無線の状態を記録あるいは特定のトリガーにより無線の状態を保存し、後日調査が行えるようにすると言った仕組みがあると聞いたことがありまして、具体的にどのような構成を組めばよいのかどのような設計となるのか、またどのような仕組みで実現しているのか教えて欲しいと思っております。

[Hideyuki Osaki · Accepted solution]

こんにちは。ご質問ありがとうございます。

はい、まさに無線運用あるあるですね。

書いていただいたような仕組みといえば、Catalyst Center （旧称：Cisco DNA Center) のことではないかなと思います。AP, WLC を設定管理監視するネットワークマネジメント製品で、オンプレ版、バーチャル版とあります。これを使っていただくと、問題が発生した時のトリガーが何であったのか、グラフィカルにぱっと見で把握することができますし、過去に遡って詳しい内容を見ることもできます。最終的にはその問題発生時のパケットキャプチャ（自動取得）を確認することもできるので、一過性の問題であったとしても原因追及ができる可能性がグッと高まります。

詳細はこちらの短いYoutubeビデオなどがわかりやすいと思いますのでぜひご覧になってください。

# 前半はセットアップの話なので6分経過頃から見るとわかりやすいです（英語です）

https://youtu.be/NsMqUsVUTeo?si=WQ9_mj0tfOQhnv9_&t=356

# 弊社のカスタマーサクセスチームが日本語でデモンストレーションをしている動画もありましたので、こちらもわかりやすいと思います。

https://www.youtube.com/watch?v=2axZ9XeScuw

また、C9800 WLC 自体は IOS-XE というルータスイッチ共通プラットフォームを採用しており、従来の IOS や AireOS にはなかった Trace という強力な機能を実装しています。これも常時動いており、過去のエラーなどを後から遡って確認することができます。ただしかなり専門的な内容になりますので、読み解くには TAC の解析や相当な習熟が必要です。

show logging profile wireless trace-on-failure

というコマンドはその Trace 機能の一端ですが、これで過去のエラーを抽出することができます。

[toshihiro-tanaka-xe]

Wlc(9800)で稼働しているAIR-AP1852I-Q-K9配下のクライアント(Windows10)で、無線接続出来ているもののG/WへPINGも飛ばず(arp -aでは他の接続クライアントIP一覧は出る)、通信出来ない状態に陥る。DNACでクライアントの状態を確認するが特に異常は見受けられ無い。クライアント側で無線OFF/ONする事で通信可能となる。この様な事象発生時、原因切り分けの方法やどちらに問題があるのか特定する方法があれば、ご教示頂きたい。

[mistakag · Accepted solution]

toshihiro-tanaka-xe さん、こんにちは。ご質問いただきありがとうございます。

C9800 に無線接続しているクライアントが、他の無線クライアントは ARP によって知ることが出来ている状態で、
ゲートウェイへの Ping 疎通性がなく、通信ができない問題が起こるが、
クライアント上で無線インターフェイスを OFF/ON することで通信可能になる、
という問題に対する原因の切り分け方法が知りたいというご質問ですね。

このような問題では、切り分けのポイントは下記のようなものがあります。

• C9800 上で、クライアントの状態は RUN になっているか。
  GUI の Monitoring > Wireless > Clients で対象のクライアントの [State] をご確認ください。
  CLI では、show wireless client summary コマンドで確認できます。
  
  
• クライアント上で、無線インターフェイスを ipconfig /all で確認したとき、
  意図した通りの IP アドレスを利用できているか。
  169.254.xxx.xxx のようなリンクローカルアドレスではないか。
  
  
• 他のクライアントデバイスでも同じ問題が起こるか。
  クライアントの種類やファームウェアバージョンによって差分がある場合があります。
  
  
• 他の SSID に接続したときに同じ問題が起こるか。
  SSID の認証方式や VLAN などの設定に差分がある場合があります。
  
  
• 発生する頻度や日時、場所に傾向はないか。発生しやすい状況はあるか。
  発生条件やトリガーを推測できる場合があります。
  
  
• 通信可能な状態からある時問題が起きるのか。SSID に接続した直後から起きるのか。
  通信中に起きる問題なのか、アソシエーション中に起きる問題なのかを切り分けます。

他の無線クライアントが arp -a で表示されるがゲートウェイへの疎通性がないということから、
無線-有線のネットワーク間に問題が生じている可能性もあります。
ネットワークの問題を切り分ける場合、デバッグやパケットキャプチャを解析する必要があります。
上述した簡易的な切り分けのみでは原因の特定が難しい場合がありますので、
弊社 TAC のサービスリクエストのご利用をご検討ください。

サービスリクエストをオープンする際は、ぜひ以下の Cisco Community 記事もご参照ください。
各種の調査に必要なログやパケットキャプチャのご案内があります。

サポートケースをオープンする際に必要な情報 - ユニファイドワイヤレスネットワーク トラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161756

[toshihiro-tanaka-xe]

ご回答ありがとうございます。

ユーザからの問い合わせが来た時には事象が収束している為、Wlc上で確認しても接続状態なのです。。

初回の返信時のarp -aで確認した結果ですが、下名PCで発生した際の確認結果となります。自席に戻った際、PCのWlanReportやCatalyst Centerで確認した結果は添付Excelにあります。

発生当時は、所内を移動しており移動先でPCを利用しようとした際、無線接続出来ているものの通信出来ない状態となりました。

Wlc上で状況確認しようとしましたが、通信出来ない状態でしたので、確認出来ませんでした。

同事象が発生した場合、ユーザからの問い合わせが無い限り気づかないのでWlcやCatalyst Centerでいち早く知る方法があればと思った次第です。

[mistakag · Accepted solution]

toshihiro-tanaka-xe さん、
お客様からお問い合わせがあったときには、事象が収束しているということですね。

収束後の詳細把握はどうしても難しい場合が多いですが、
上記の弊社大崎からのコメントで触れられているように Catalyst Center や C9800 の Trace から、
過去にさかのぼって問題の概要を確認する方法もあります。

今回のケースでは Catalyst Center の Event Viewer をご確認いただいているようですので、発生時刻を確かめた上で、
その時刻にエラーがないか、どこかの処理でスタックしている様子がないかなどをチェックいただくことで、
どこに問題がありそうなのかをある程度絞り込めると思います。

また、Catalyst Center では特定のイベントがトリガーされると外部メールサーバにメール通知を送る機能があります。
Event Viewer で確認したイベントをトリガーに設定することで、事象の発生にすぐ気づくことができるかと思います。
詳しくはお使いのバージョンの下記ドキュメントをご覧ください。

Enable Issue Notifications - Cisco DNA Assurance User Guide
https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center-assurance/2-3-5/b_cisco_dna_assurance_2_3_5_ug/b_cisco_dna_assurance_2_3_3_ug_chapter_01001.html#id_113958

個別の事象調査について具体的なご質問がありましたら、サービスリクエストのご利用もご検討ください。

[toshihiro-tanaka-xe]

クライアントとAP間で接続出来ているものの通信出来ない状態の際、AP上の無線フレームの合計が20万件を超していました。

WlcはC-9800-40 Ver17.12.3でAPの機種は1852Iです。

フレームエラーが発生する原因と対策をご教示頂きたく。

[shokobay · Accepted solution]

ご質問ありがとうございます。

一時的にではありますが、大量のTx errorを確認されているということですね。

Tx error の原因としてよくあることは、無線空間が混雑していることや、端末が遠い場所に移動していて届いていなかったりする可能性がございますが、実際の被疑箇所や原因についてはその事象が発生している周辺のログを詳細に確認する必要があります。

ご質問いただいた内容のみではこちらの原因について言及できないため、原因と対策についてご希望の場合はお手数ではございますがサービスリクエストをオープンいただけますでしょうか。

[toshihiro-tanaka-xe]

ご回答ありがとうございます。

現調の上、ローミングの最適化、低データレートの無効化、APの追加などの対策を行ってみたいと思います。

[M O]

Catalyst 9800で無線接続断が発生した際に、以下のようなreason codeが出ると思います。

Deleting the client, reason: 15, CO_CLIENT_DELETE_REASON_KEY_XCHNG_TIMEOUT, Client state S_CO_RUN

こちらについて調査を行う際に、以下のURLを参考にしたりしているのですが、上記のreasonのように以下に掲載されていないものもありそうです。
reason codeの情報がまとまった資料などはありますでしょうか？

・Catalyst 9800ワイヤレスコントローラの一般的なワイヤレスクライアント接続の問題のトラブルシューティング
https://www.cisco.com/c/ja_jp/support/docs/wireless/catalyst-9800-series-wireless-controllers/213970-catalyst-9800-wireless-controllers-commo.html

[Hideyuki Osaki]

こんにちは。回答が遅くなって申し訳ありません。

そのページはとても良いサンプルが掲載されていますね。確かにおっしゃる通り、ご提示の Reason については残念ながら掲載されていないようです。なんとなく見えてくるかと思いますが、KEY XCHNG TIMEOUT = キー、エクスチェンジ、タイムアウト、となりますので、鍵、交換、時間切れ、ということですね。無線の世界で鍵の交換となると、最初に頭に浮かぶのは暗号化セッションを確立するための 4way handshake です。これは PSK や 802.1x により暗号化している SSID で必ず最初の方に発生する処理ですので、そこでなんらかの問題が起きているのではないか、と想像ができます。同じREASONによる切断が多発しているようであればサービスリクエストによる調査打診をご検討ください。なお基本的には IEEE802.11 に掲載の Deauthentication 理由に基づいた挙動を取るように設計しておりますので、IEEE 802.11 を辞書として参照するのもおすすめです。

そしてご質問にあるまとまった資料についてですが、フォーマットが少し違いますが、AP が Deauthenticate する、つまり、DELETE するときに使う Reason の一部は下記のリンクにまとまっています。2020年なので既に古い情報にはなってしまいますが、なんらかの一助にはなるかと思いますのでご参照ください。

https://community.cisco.com/t5/-/-/ta-p/3148055

例えば 4-Way Handshake timeout などの記述が見えると思います。

[M O]

ご回答いただき、ありがとうございます。
まとまった資料について、今後のトラブル対応で参考にさせていただきます。