シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

6/21 "無線LAN 基本トラブルシューティング CCNP 改訂と Mobility Express の紹介" QAドキュメント

資料ダウンロード   ディスカッションに参加する   録画を観る   QAを読む

Q1.WLC/APのログから電波干渉が発生しているか確認する方法はありますか。

はい、あります。
WLC GUI で MONITOR > Access Points > Radios > 802.11b/g/n (802.11a/n/ac) > AP name > 右端の青い三角ボタン > Detail > Profile Information を確認してください。
Detail の代わりに CleanAir を選ぶと、どんな種類の干渉源であるかまで判明します。

Q2.AP1830を自立型APのリプレースとして、利用できますか?

リプレースとして十分に機能すると考えて開発された製品ではありますが、セミナーでご紹介したように、サポートされていない細かな機能がいくつかあります。
その差分が許容できて、集中管理、冗長性、アプリや日本語での運用といった製品特徴にメリットを感じていただけるのであれば、リプレース製品として十分にご満足いただけると思います。

Q3.Mobility Expressで、WLANのセキュリティー設定するときに利用可能な.1xの種類はどうなるのでしょうか。

EAP のタイプという意味であれば、LEAP, EAP-FAST, PEAP, EAP-TLS, EAP-TTLS, EAP-SIM をサポートしています。
WEP に関しては脆弱なアルゴリズムですのでサポートしておらず、Dynamic WEP 構成はできません。WPA2 Personal (PSK) もサポートしています。
また、外部 RADIUS サーバを使わず内部の RADIUS サーバを使う Local Authentication としては、LEAP, EAP-FAST, PEAP が可能です。

Q4.使用可能な外部認証サーバは、RADIUS,Tacacsが使える認識ですが、LDAPやADは非サポートの認識で間違いないでしょうか。

はい、AD/LDAP と Master AP は直接は通信できませんので、その間に Cisco Identity Service Engine (ISE) などを配置して RADIUS 経由で LDAP を参照する必要があります。

Q5.最新のCCX認定デバイスに関する情報があればご紹介いただけないでしょうか。

最新の情報は常に DevNet にあります。CCX については次のページです。

https://developer.cisco.com/site/compatible-ext/home/
認定製品 : http://www.cisco.com/web/partners/pr46/pr147/partners_pgm_partners_0900aecd800a7907.html

認定製品は各メーカーのページにてさらに詳細検索していただく必要があります。また、時期によってはパートナー契約が終了している場合もありますので、特にこのページに記載されていないメーカー製品については各メーカーに個別にご相談ください。
最近のトレンドとしては、Wi-Fi アライアンスの規定だけでなく、IEEE 802.11k, 802.11v, 802.11r など、IEEE スタンダードにも皆で準拠して、より互換性を高めていこうという基盤が整いつつあるのかなと感じています。CCX から生まれた IEEE スタンダードが多数ありますし、今回の Apple + Cisco のようにベンダー独自色を出して差別化をしていく流れも並行して存在しています。

Q6.「クライアント固有の電波送受信仕様とサポートするプロトコル」の例は?

SNR の話をしたと思いますが、そこで受信機に求められる SNR や最低受信感度という点に触れました。この値がクライアントによって異なるので、たとえば同じ距離に2種類のクライアントがいる場合、どちらでも同じ受信電 力、すなわち SNR が得られるとは限りません。とくにスマホなどはパソコンに比べるとハードウェアの制約が大きいので、受信感度が悪かったりします。
また、手に持っているという ことも意外と大きな要素になります。手というのは水分を多く含んでいるので、電波を吸収してしまいます。同様に頭部もそうなので、手に持った状態で耳の付近に構えていると、大幅な減衰が生じることが期待されます。
また、アンテナの数がクライアントによって変わるので、ダイバーシティ受信ができるかどうかや、MIMO の恩恵を受けることができるかどうか、といったところに関連してきます。結局最後は SNR と伝送レートが期待するものになるかどうか、というところに関わってきますので、重要な要素として考えてほしいです。
これが、クライアントは実機を使ってサイトサーベイした方がよい、ということの一つの根拠にもなっています。
また、今回紹介できませんでしたが、プロトコルについては MIMO 以外にも、特にローミングの際の挙動が大きいです。スタンダードの 802.11k, 11v, 11r などの直接ローミングに関わるプロトコルを端末がサポートしているかどうか、また、シスコと互換性があるという CCX プログラム (CCKM) に参加しているかどうか、などによって高速セキュアローミングを実施するときのやりとりが変わってきます。
その対応状況に応じた無線 LAN の設定、および設計をしておかないと、ローミングのたびに問題が発生することが考えられます。全ての端末が完全に 802.11 スタンダードに準拠した動作をしていたとしても、実はスタンダードでは詳細については定義しておらず、メーカーの実装に任せるとなっている部分も多くありますので、その独自実装がどのようなものなのか、といったところをよく見ておく必要があります。
たとえばシスコの WLC は最初は OKC のみをサポートしていて、SKC はサポートしていませんでした。一方 Apple iPhone は SKC のみをサポートしていて OKC をサポートしていませんでした。なのでローミングの際にはいちいち認証サーバまで行って再認証をする必要があり、ローミング時間がかかるという問題が起きていましたが、今では WLC が SKC もサポートしているため、WLC 側で互換性問題に対応ができるようになっています。

Q7.QoE と QoSの違いは?

厳密な定義はなかなかないと思います。
QoE は呼んで字のごとく、ユーザの体験の質、ということになります。ユーザが使い易いと考えれば良いQoE だし、そうでなければ QoE が悪い、ということになるはずです。定性的な判断になるので、扱いは難しいですが、常にユーザの目線で使い易いかどうか、ということを意識してデザインすること が求められているのだと思います。一方 QoS については遅延量やジッタ、VoIP の場合は MOS といった値で、ある程度定量的に評価、判断ができます。
QoS がちゃんと合格ラインをクリアしていれば、QoE の向上にも一躍買うことは間違いないですが、QoS だけを気にしていてもダメだというのが主旨です。たとえばローミング時の端末の挙動や、ユーザが思いがけない場所や密度で無線LANを使おうとしていないか、といった点も気にする必要があります。

Q8.サイトサーベイをしないことにより発生したトラブルは多いのか?

多いです。サイトサーベイを全くしないという人はさすがに少なくなってきていますが、実機や実際の就業時間中に実施をしていないということがあります。その場合は端末依存の問題や、時間や人に依存した干渉源、人口密度などが考慮から漏れてしまう。干渉源の問題などは、しっかりサーベイをしていれば必ずわかるし、対策もとれるので是非やってほしいです。
また、一度やって終わりではなく、やはり継続的に監視していくことが重要だと思います。ある日突然従業員が自前の不正アクセスポイントを持ちこんだりすることも考えられるし、同じフロアの別テナントがWiFiを使い始めるかもしれません。最近だと BLE や iBeacon の活用などもでてくると思います。PI と CleanAir 、そして CMX を組み合わせて継続監視するのが有効ですね。

Q9. DFSの発生頻度はどのように算出すればいいのか? 実際にAPを設置してチャネルごとに長時間確認しなければならないのか?

はい。そのようにするしかありません。
基本的に日本国内だと、全国どこでもレーダを受信する環境にあります。なので、レーダーが存在するかしないか、というこ とではなく、どのチャネルにどの時間帯に存在するのか、という観点で把握しておくことが重要です。気象レーダーなどは各地域によって周波数が省庁のホームページで公開されていることもあるので、調査せずともわかることもあります。ただし日米の軍事レーダなどについては原則公開していないため、事前に対策をするのは難しいのが現状です。

Q10.APが接続できない問題で一番多い事例は?

なかなか難しい質問ですね。統計値としては持っていません。セミナーで紹介したように、無線でデータ通信が可能になるまでには複数のステップがあり、すべてに成功する必要があります。どこかで失敗していたら、接続できないことになります。それは無線環境かもしれないし、認証サーバの設定かもしれないし、サポートするプロトコルや、伝送レートの違いなどかもしれない。また、単純に AP やクライアント固有のソフトウェア不具合である場合もあります。その場合は修正済みの最新版のドライバや OS へアップグレードすれば解決するので、ある意味動きやすいですが、無線環境やそもそものデザインに無理があったりすると、解決にも時間と手間がかかる傾向にあります。
一番多い事例、というのは無いものと考えていただき、常に真っ白な状態からトラブルシュートを開始して、どこまで成功していてどこで失敗しているのか、その分岐点を突き止めることが重要だと考えています。

Q11. Mobility Express では CLIはサポートされているのか?

いくつかのCLI はサポートされています。
cisco.com 上に deployment guide やコマンドリファレンスがあるので、そこに記載されているものはサポートされていると考えていただきたいのですが、もし動かないものが記載されていたら、問い合わせてください。
また、コマンドは入力できるけれども、実はその設定は機能としてはサポートしていない、というものもありますので、もしガイドに書かれていないコマンドが入ったとしても、使わないでください。
たとえば MAC filtering などはコマンドとして入力できてしまうが、8.2.110.0 の時点ではサポートしていない機能ですので、使わないようにお願いします。

Q12.初期設定を実施したコンフィグをIP等変更して、複数のAPにリストアしたい場合は可能か?

パスワードをかけてコンフィグを暗号化して保存している場合は不可能です。
暗号化していない場合は、技術的には可能ですがおすすめはしません。Mobility Express の場合、Mobility Express ソフトウェアで動く AP 同士で冗長構成を組むことができます。この冗長構成を実施しているAP の間では、同一のコンフィグが同期され、たとえばアップグレードのときや、スイッチオーバする場合でも同一のコンフィグが自動的に採用されるので、わざわざ Master AP 候補となる AP 用に複数のコンフィグファイルを用意してリストアするといった作業は実施する必要は発生しないはずです。

Q13.TACにケースをオープンする場合はGUIの画面をとるのか?IOS APのようにCLIからのログ取得が必要あるのか?(もしくはGUIからログが取得できるのか?)

AireOS で使える show traplog, show logging といったコマンドは使えます。debug client も使えます。GUI のスクリーンショットを取得してもらい、そこから問題解決をスタートすることでも全然構いませんが、CLI でダブルチェックを要請することはあり得ます。

Q14.WLCへJoinする場合、バージョンが異なってもWLCからソフトウェアがダウンロードされるのか?

はい。WLC AireOS 8.1.111.0 以降であれば AP1850 を、8.1.120.0 以降であれば AP1830 も加えてサポートしています。

Q15.AP3700 と AP3800 を比べた時、AP3800 の魅力はなんですか

3800 は 3700 にはない機能がたくさんありますが、大きな魅力の一つは柔軟性にあると考えています。
環境といものは常に変化するものです。現在 2.4 GHz 帯と 5 GHz 帯に同じ数のデバイス数が存在するかもしれませんが、1年後には 5 GHz 帯のクライアントしかほとんどいない状況になっているかもしれません。完全な 5GHz 環境へ移行するためには、3700 を使用していた場合、AP を追加で購入する必要が出てくるかもしれませんが、3800 ではデュアル 5 GHz モードをサポートしています。
デュアル 5 GHz モードをとは、AP 内の無線インターフェイス 2つが両方とも 5 GHz の帯域で動作する機能です。これによって増加した 5 GHz のクライアントに対応することができます。 このように、3800 は変化する環境に柔軟に対応することができます。

Q16.Cisco に問い合わせると無線パケットキャプチャを依頼されるが、無線パケットキャプチャから何が分かるのか

TAC では大きく 2 つの理由で無線パケットキャプチャを依頼しています。
1 つ目の理由は、一見は百聞にしかず、事象が発生している時の無線空間を確認したいためです。2 つ目は客観的な第三者の視点から事象を確認をしたいためです。
具体例を上げて説明します。OS アップグレード後無線通信がたまに切れるという事象が発生したとします。AP の debug ログでは問題が起きているようには見えません。クライアントで取得したパケットキャプチャでも問題があるように見えません。こういう時に第三者の無線パケットキャプチャが役に立ちます。
無線パケットキャプチャを取得すると、その時だけ異様にチャネルが混雑してた、隣接 AP が同一チャネルを使用し同一チャネル干渉が発生していた等、AP とクライアントだけでは把握できかったことが分かります。また、実はクライアントが AP のパケットに応答していなかった、AP がパケットを送信していなかったといったように、無線パケットキャプチャを取得しないと分からないこともたくさんあります。

537
閲覧回数
5
いいね!
0
コメント