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

2014/10/7 Webcast 「Cisco Unified Wireless Network (CUWN) の技術紹介およびトラブルシューティング」Q&A

2014 年 10 月 7 日(火)開催 Live Expert Webcast で行われた Q&A 集です。

録画ビデオは こちら から、資料は こちら よりご覧いただけます。

---------------------------------------------------------------------

Q1. Voice については何か注意すべき点はありますか?

A1. Voice の運用には、データ通信とはまた違う考え方やプロトコルが必要です。たとえば QoS ですが、まだまだこれを使わずにデータ通信と同じ条件で運用しているかたがいらっしゃいます。ある程度使えてしまうので厄介ですが、データ通信よりもジッターに厳しい要件があったり、ユーザが歩き回ったり、または思いもつかない場所で電話をしていたりしますので、それらのニーズの違いというものをデザインに取り入れておかないと、いざトラブルが発生した時に影響が大きくなったり、改善に時間を要したりしてしまいます。データ通信の延長線上という考え方で間違ってはいないのですが、そのまんま同じ設計、同じ設定でうまく行くとは考えずに、違いを理解した上で適切にデザインに反映していく必要がありますね。

 

 

Q2. CAPWAP は標準化されているということですが、シスコ製品以外の AP も Join できるのでしょうか。

A2. 現時点ではサードパーティのサポートはしていません。というのも、WLC が CAPWAP の正規プロセスをサポートしていても、vendor specific payload によるシスコの独自実装を送信できないからです。同じく、その他社製の AP から vendor specific payload が飛んできた場合、内容を理解することができません。

 

 

Q3. 802.11ac の対応について。AP3700 や 2700 は 11ac に対応していると思いますが、チャネルボンディングをどう設定するのがよいかわかりません。20/40/80MHz はどう使い分ければよいでしょうか。

A3. 80MHz については、まず、11ac 端末がどれだけ多いかということを考慮して導入すべきと思います。1ss クライアントでも 11ac の 80MHz 幅に対応しているのであれば積極的に使っていき、キャパシティを増やした方がよいと思いますし、まだそこまで多くなく 11n クライアントが多いということであれば 20/40MHz で良いと思います。40MHz はヘビーなビデオ等のトラフィックが多い場合に採用するべきだと思います。

 

 

Q4. 802.11ac では 80MHz 対応ですが、チャネルを 4 つ分使うということになります。 DFS が起こりやすいチャネルを避けるという話がありましたが、80MHz で運用している場合は 20MHz  で運用している場合よりも DFS にあたりやすい、という理解であっていますでしょうか。

A4. はい、その理解で大体あっています。 80MHz で運用している場合、AP はその全ての帯域において DFS の監視を行います。どこかで DFS が動作した場合、なるべく 80MHz 幅のままで移動できる新たなチャネルを探しますが、適当なチャネルがない場合は 40MHz 幅に落としてチャネルを運用するように動きます。したがって、802.11ac を使う場合、とくに W56 などの屋外での使用については、DFS がどの程度発生するのか等、影響度を慎重に見極める必要があると言えます。

 

 

Q5. AP の priming についてですが、Join した後に、Primary/Secondary/Tertiary を設計するようにしています。説明のあったコマンドは使っていないのですが、これで問題ないでしょうか?

A5. はい、その方法であっていますが、特定の一台を対象にしているのであれば、primary だけを設定しておくべきですね。今回ご案内したコマンドは、AP 単体で priming をする方法です。 Join した後に、AP 個別設定にて P/S/T を設定される場合と、同じ結果になります。ただし、目的外の WLC に Join している場合は、設定後に test capwap reset を実施するか、WLC は予めAP fallback をオンにしておき、目的の P/S/T にJoinできるようにしてやる必要がありますね。

 

 

Q6. 現在 WPA-TKIP で運用しており、8.0 にバージョンをあげることを考えています。WPA-TkIPは使えないという話でしたが、どうすれば良いでしょうか。

A6. 使えないわけではなく、あくまでインフラ側の制限です。つまり、設定としては WPA-TKIP 単体というのは許可されず、設定できませんが、クライアントの接続は引き続き可能です。アップグレードされる場合は自動的に WPA2 の設定も入った形でコンフィグが変更されることになります。 WPA2 への移行期ということで猶予されている状況ですので、セキュリティの観点からも  WPA2 への移行を考えていった方がよいかもしれませんね。

 

 

Q7. ローミングの動作について基本的な動作を教えてください。

A7. ローミングが発生するときは、基本的には通信は途切れずに高速にローミングしたいというニーズがあると思います。このようなローミングを高速ローミングと言いますが、CUWN の場合、高速ローミングをするにはいくつかのオプションが考えられます。鍵となるのは、クライアントの設定、仕様、実装動作です。 WLC の設定としては、クライアントがローミングをする場合に CCKM を使っているのか、sticky key caching なのか、OKC なのか、802.11r なのか、ということを考慮する必要があります。どのプロトコルで高速ローミングをするかを決めたあとは、それを実現できるように、基本的には 20% 程度の重なりを持った形でセルを配置し、カバレッジに穴があかないようにセルをデザインしていくことになります。

 

 

Q8. 色々と内容があったんですが、なかなか現場ですぐに適切に対応するのが難しいんじゃないかと思うところがあります。もっとシンプルに言うとどのようにトラシューすればよいでしょうか。

A8. 無線 LAN のトラシューには、定石というものはなく、すぐに原因がわかるということは多くありません。 常に状況を把握し、問題をなるべく具体的に定義し、ロジカルに考えていく必要があります。こういうログ、症状、パケットキャプチャの結果が見られるから、 こういう問題があるんじゃないか、と想定をして、それに対する対処を実施し、効果を見るというのが基本的なスタンスです。その際には、今回ご紹介したように、IP 通信ができるようになるまでは複数の デバイス、プロトコルが全て成功する必要があるということを念頭に置き、どこで失敗しているのか、という見方で原因個所を絞っていく必要があります。その過程をサポートするために、debug client を始め、数々の コマンドやツールを用意していますので、これらを駆使することができれば、より早くロジックを回すことができると言えます。

 

 

Q9. MTU が大きすぎて CAPWAP が通信できないという話があったが、Path MTU discovery についてもう少し詳細に教えてほしい

A9. AP の CAPWAP プロセスでは、まず Join する際に、1485 バイトまで padding したうえで Join Request を送信します。
 DTLS トンネル確立後に最初に送信するのは Join Request ですので、ここで正しい MTU 値に設定することができれば、以降のトンネルを通した通信での MTU が保証されますね。したがってここで調整を行うのです。1485 バイトというのが、設定できる最大の MTU 値なのです。
このとき、フラグメントされては元も子もありませんので、DF bit もセットされます。 Response についても WLC は DF bit をセットした上で、最大の 1485 バイトで WLC は応答します。これがちゃんと AP に届けば、MTU は 1485 でよい、ということになり、 AP は MTU を 1485 バイトに設定します。MTU を 1485 に設定したことを、Config Request あるいは Image Request の vendor specific payload を使って WLC へ伝えます。 この受信をもって WLC もその AP に対しては MTU を 1485 へと設定するわけです。このように3回のやりとりで CAPWAP で使う MTU は決定されます。
ではもし、MTU が足りなくて WLC に Join Request が届かなかった場合はどうなるかというと、AP は Join Request を再送するのですが、このときは 1485 バイトまで padding することなく、短いまま送信するのです。 これがちゃんと WLC に届いた場合、WLC も padding をせずに Response を返し、そのまま成功するようであれば、この値を採用することになります。
もしも AP から WLC へは 1485 バイトで届くけれども、WLC から AP へは 1485 バイトへ padding して届かないという場合も同様に、やはり AP は再送を するのですが、やはり 1485 バイトへ padding せずに再送をすることになります。 実は padding 無しの場合というのは 576byte になっており、1485 か 576 のいずれかの値が採用されるようになっています。
これで RUN ステートまで行ったあと、実はもう一度dynamic path discovery により MTU は調整されます。 dynamic path discovery については RFC で規定されております。 もしもどこかで MTU に変更があり、1485 が通らなくなった場合、中間のルーターが ICMP により Error を伝えます。
このエラーを受信しますと、AP はやはり小さい方の値、576バイトを採用するように動き、また WLC にもその旨を伝えます。
Error の中で指定されている MTU サイズに調整した Path MTU Discovery を WLC へ送信し、WLC もまた、その値で応答します。 これが成功しますと、その MTU が AP にセットされます。
もしもエラーの中で明示的に MTU が指定されていない場合は、最小の 576 バイトからスタートし、以降30秒毎に 1006, 1492, 1500 バイト というように徐々に MTU を増やしていきます。

 

Q10. AP が WLC に JOIN しているかどうかの「今の状態」を、AP 側ローカルで確認するための 「show」コマンドは何でしょうか? show ap clinet config では、設定状態や過去の接続履歴情報だったと思いますので。

A10. show capwap client rcb に、OperationState という項目があり、そこに UP と表示されます。 WLC に Join している場合は、Up。Discovery Mode の時は DISCOVERY と表示されます。


 // 実際の出力 //
AP#show capwap client rcb
AdminState                  :  ADMIN_ENABLED
SwVer                       :  7.6.120.0
NumFilledSlots              :  2
Name                        :  AP
Location                    :  default location
MwarName                    :  CT5508
MwarApMgrIp                 :  172.16.12.34
MwarHwVer                   :  0.0.0.0
ApMode                      :  Local
ApSubMode                   :  Not Configured
OperationState              :  UP << ここです。
CAPWAP Path MTU             :  1485
LinkAuditing                :  disabled
AP Rogue Detection Mode     :  Enabled
AP Tcp Mss Adjust           :  Disabled
AP IPv6 TCP MSS Adjust      :  Disabled
Predownload Status          :  None
Auto Immune Status          :  Disabled
RA Guard Status             :  Enabled
Efficient Upgrade State     :  Disabled
Efficient Upgrade Role      :  None
TFTP Server                 :  Disabled
Antenna Band Mode           :  Unknown
802.11bg(0) Radio
ADMIN  State =  ENABLE [1]
OPER   State =      UP [2]
CONFIG State =      UP [2]
HW     State =      UP [4]
  Radio Mode                : Local
  GPR Period                : 10
  Beacon Period             : 100
  DTIM Period               : 0
  World Mode                : 1
  VoceraFix                 : 0
  Dfs peakdetect            : 0
  Fragmentation Threshold   : 2346
  Current Tx Power Level    : 1
  Current Channel           : 1
  Current Bandwidth         : 20
802.11a(1) Radio
ADMIN  State =  ENABLE [1]
OPER   State =      UP [2]
CONFIG State =      UP [2]
HW     State =      UP [4]
  Radio Mode                : Local
  GPR Period                : 10
  Beacon Period             : 100
  DTIM Period               : 0
  World Mode                : 1
  VoceraFix                 : 0
  Dfs peakdetect            : 1
  Fragmentation Threshold   : 2346
  Current Tx Power Level    : 1
  Current Channel           : 64
  Current Bandwidth         : 20
Nexthop MAC Address         :  0022.bb81.5312



 

Q11. デュアルバンド機能を有効にしており、2.4GHz帯に干渉が起きている環境の場合、5GHzにしか接続できなくないことはありえるか? Band Select は有効にしていません。

A11. 2.4GHz に接続しにくい状況の場合に、端末が5GHzでの接続を試みれば 5GHz で接続します。WLC 側でBand Select 機能を有効にしていない場合、端末がどちらの帯域に接続するのかは端末側の実装に依存します。

 

Q12. AP1600 が CleanAir express をサポートしましたが、SE コネクトモードのサポート予定はどうでしょうか?

A12. SE-Connect mode も同じくサポートしています。 AP1700 についても同様です。

 

Q13. 「Local mode AP の場合は trunk ではなく access で問題なし。」とありますが、trunk でも問題はないのでしょうか。

A13. AP は初期値では native vlan (dot1qタグ無し) を使って Discovery/Join パケットを送受信するという点に気をつけておけば、問題はありません。ただ、ネットワークの一般的な話として、受け取る必要のない別セグメントのブロードキャスト等は予めフィルタする等しておくのが一般的だと思います。また、受け取る側の WLC のマネジメントインターフェイスがタグ無しなのか VLAN の色付きなのかを考慮して、ちゃんと AP からの CAPWAP パケットが届くように設計すべきですね。

 

Q14. Client Statistics情報で RSSIやSNR情報がありますが、これば AP側受信感度でよろしでしょうか?Client側の受信感度を確認する方法はありますか?(APまたはClientどちらの受信か解釈に迷います)

A14. show cient deitail の次の部分ですね。

Client Statistics:
      Number of Bytes Received................... 16998
      Number of Bytes Sent....................... 11239
      Total Number of Bytes Sent................. 11239
      Total Number of Bytes Recv................. 16998
      Number of Bytes Sent (last 90s)............ 122
      Number of Bytes Recv (last 90s)............ 183
      Number of Packets Received................. 216
      Number of Packets Sent..................... 128
      Number of Interim-Update Sent.............. 0
      Number of EAP Id Request Msg Timeouts...... 0
      Number of EAP Id Request Msg Failures...... 0
      Number of EAP Request Msg Timeouts......... 0
      Number of EAP Request Msg Failures......... 0
      Number of EAP Key Msg Timeouts............. 0
      Number of EAP Key Msg Failures............. 0
      Number of Data Retries..................... 19
      Number of RTS Retries...................... 0
      Number of Duplicate Received Packets....... 0
      Number of Decrypt Failed Packets........... 0
      Number of Mic Failured Packets............. 0
      Number of Mic Missing Packets.............. 0
      Number of RA Packets Dropped............... 0
      Number of Policy Errors.................... 0
      Radio Signal Strength Indicator............ -41 dBm <<<<<
      Signal to Noise Ratio...................... 55 dB <<<<<

はい、これはこの AP が受信したこのクライアント発の電波の強度です。 クライアントが AP 発の電波の受信感度を通知する機能はありません。クライアントによってはローカルに確認できるものがあります。Macbook OSX 10.9 だと Option+Wi-Fi アイコンクリックで出てきますね。昔は弊社の ACU というクライアント製品があり、それで RSSI を見ることもできました。

 

Q15. APのDHCPfallback 機能は OFF にできないでしょうか?

A15. オフにはできません。オフにしたいというご要望も確かに存在するので、次の機能追加リクエストが存在しています(実装予定は今のところありません)。
CSCua58662 Ability to Disable AP Fallback to DHCP When Configured for Static IP

 

Q16. SSO 構成について質問です。ver8.0 で SSO を構成するときに、Switch のポートをトランクポートに設定しないと正常動作確認ができなかったです。これは ver8.0 からは SSO 構成では必ずトランクポートでの設定しないといけないことですか?(まったく同じ環境で、ver7.6 ではアクセスポートでも SSO 構成・正常動作確認できた)

A16. CT5508 の Redundant port の接続スイッチポートのことでしょうか? WISM2 であれば Redundant VLAN を management VLAN とは別に作成する必要があります。5508 でそのような事象が起きたというのは聞いたことがありませんので、キャプチャしてどのようなタグがついているか確認してみてください。

 

Q17. AP の一部の capwap コマンドが、入力しても反映されないことがあります。何故でしょうか?

A17. それはひょっとするとホスト名の変更コマンドでしょうか。その場合は次の不具合に該当しているおそれがありますね。
CSCtl96208 "capwap ap hostname" CLI returns "ERROR!!! Command is disabled."

 

Q18. 高速ローミングする場合、移動するAPにPMKキャッシュが無くても再認証が必要ない方法は、CCKMとなるでしょうか? OKC の場合は、異動する先の AP に PMK キャッシュが無いと再認証が必須になるでしょうか?

A18. CCKM および OKC ですね。CCKM, OKC は実際にキャッシュしているのは WLC 内のメモリですので、どの AP に来ようと、WLC が変わらないのであれば OKC により高速ローミングできます。また、モビリティを組んでいる WLC間であれば、モビリティ間でもキャッシュを共有していますので、やはり高速ローミングができます。

 

Q19. WLC のバージョンが「7.2.110.0」であれば debug client コマンドは何台設定できますか?

A19. 3 台です。7.3 から 10 台に拡張されました。

 

Q20. CleanAir では 5GHzでもサポートしていますか?サポートする予定がありますか?

A20. はい、もちろんサポートしています。

 

Q21. WLC の DHCP Proxy を有効にした場合、無線クライアントがユニキャスト(WLCのIPアドレス)の DHCP パケットを送信した場合でも、DHCP サーバにパケットを転送しますでしょうか?

A21. こちらは Ask The Expert にて回答いたしましたので、そちらをご参照ください。

 

バージョン履歴
改訂番号
1/1
最終更新:
‎10-14-2014 11:53 AM
更新者: