キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
告知

JTAC-Mid-Career-Recruitment-2021.3

CSC-campaign-v2.JPG

 

7303
閲覧回数
35
いいね!
48
返信
CiscoJapanModerator
Rising star

Ask Me Anything - ワイヤレス: Catalyst 9800やWLCの設計や設定とトラブルシューティング

AMATopBanner2021.4.23.JPG

以下のワイヤレス製品を利用した設計や設定、機能確認、トラブルシューティングでお困りのことはありませんか? 当 Ask Me Anything (AMA) イベントでは、現役のワイヤレスエキスパートが、皆様の質問にお答えします!

  • Catalyst 9800
  • Wireless LAN Controller (WLC)
  • Wireless Access Point
  • Identity Services Engine (ISE) ※認証機能などワイヤレス製品と連携機能が対象

なお、当イベントの対象は以下とさせて頂きます。

  • IOS-XEは、バージョン16.10以降の利用時を前提
  • AireOSは、バージョン8.0以降の利用時を前提
  • ISEは、バージョン 2.4以降の利用時を前提
  • ハードウェア固有の質問は対象外

当イベントは、Cat9800、WLC、アクセスポイントおよびISEについて、エキスパートの知見を得られる良いチャンスです! 皆様のご質問をお待ちしております。

なお、当イベントは、ネットワンシステムズ株式会社 ビジネス開発本部 応用技術部様との共催となります。

 

このイベントに 参加するには、 Japanese-reply.png ボタンをクリックして質問してください。

4月5日(月)から23日(金)まで質問を投稿できます。
大変ご好評につき 開催期間を1週間延長いたします!

  

共催会社紹介

net-one-logo.JPG
ネットワンシステムズ株式会社について

ネットワンシステムズ株式会社は、お客様が利用するビジネスアプリケーションを、プライベートクラウド/パブリッククラウドを包括してセキュアに支える「クラウドシステム」を提供する企業です。そのために、常に世界の最先端技術動向を見極め、その組み合わせを検証して具現化するとともに、実際に自社内で実践することで利活用ノウハウも併せてお届けしています。詳細は https://www.netone.co.jp をご覧ください。

 

エキスパート紹介

田中 政満 (Tanaka Masamitsu)
ネットワンシステムズ株式会社 ビジネス開発本部  第3応用技術部 第3チーム
入社以来無線LANの製品担当SEとして製品や技術の調査、検証評価、及び、提案や導入を支援する業務に従事。現在はキャンパスセキュリティや自動化に力を入れるなど、エンタープライズSDNのエンジニアとして邁進中。

丸田 竜一(Maruta Ryuichi)
ネットワンシステムズ株式会社 ビジネス開発本部 第3応用技術部 第3チーム
無線LAN製品担当として、主にCisco WLC, AP, PI, CMX製品評価・検証・技術サポート・提案支援に従事。
DNA Centerやクラウド型無線LAN製品など、新たな製品が増えていくなか、現場での使われ方を念頭に業務にあたっています。

質問をするには Cisco.com ユーザIDでのログインが必要です。Cisco.com ユーザIDの登録や設定、ニックネーム利用方法などについて詳しくは、新Cisco Community: ログインと プロファイル設定方法 を参照してください。

なお、質問が多数となる場合、2人では回答が難しくなる場合があります。 そのため、おひとり様の質問数は最大3件まで、全体の質問数は先着 20件までとさせていただきます。ご質問数を超える場合は、ワイヤレスのディスカッションボードまでご投稿をお願いいたします。
 

**役に立ったら 「いいね!」ボタンをクリックして参加者を増やしましょう **
質問に対する回答は 是非 評価をお願いいたします。

48件の返信48

メーカーエンジニアでないとお答えの難しい質問かと存じますため 弊社(シスコ)内で確認した所、Catalyst 9800 設定ガイドに記載のない場合は非サポートと回答がありました。 そのため、ご利用は控えて頂けますようお願いいたします。 また、残念ながら IPベースの管理アクセス制御については現在サポートしておりません。

エンジニアへのご確認までいただき大変ありがとうございました。

access-classでのIPベースの管理アクセス制御はサポートしていない旨かしこまりました。

 

cja56910tf
Beginner

Flexible Radio Assignment(FRA)とデュアルバンド(XOR)無線を効果的に活用できる環境・条件・設計/設定についてご教授下さい。

 

Catalyst 9120AXIではデュアルバンド(XOR)無線をサポートしており、Radio0とRadio1で5GHz帯を同時に動作させる事が出来る事に加えて、Flexible Radio Assignment(FRA)により、使われる周波数帯の選択などを自動調整してくれる認識です。

そこで、2.4GHz帯の使用を最低限にするため、殆どのAPではRadio0とRadio1において5GHz帯が動作するように設定しようと考えていますが、無線APの高密度環境においては5GHzの周波数帯を多数使用してしまい、問題が発生するのではないか?と不安に思っております。
また、チャネルボンディングで周波数帯を40MHzや80MHzに束ねる設定をしている場合は、干渉・混信が発生する原因になって、かえって品質が悪化してしまうのではないかとも懸念していますので、そのような場合はRadio1はモニターモードで使用した方が良いのか?という疑問もわきます。

 

前置きが長くなりましたが、冒頭に記載した通り、デュアルバンド(XOR)無線を効果的に活用できる環境・条件・設計/設定、また、デュアルバンド無線を使用しない方が良い環境・条件などについてご教授いただけませんでしょうか。

前提として、
2.4GHzは選択可能なチャネル数が事実上3しかなく、比較的遠くまで伝搬する。
5GHzは選択可能なチャネルがより多くあり、比較的遠くには伝搬しにくい。という特徴があります。
APをオフィス等の室内に設置する場合、旧来はAPの2.4GHz interfaceを停止して間引くことで、
チャネル設計を最適化していましたが、存在するリソースを停止することはもったいないことで、
これをより活用するために作られた機能がDual-5GHzであると理解しています。
端末の数が多く、多くのAPが設置されるオフィスや等の室内での使用に適した機能です。

そういった場所で5GHzのカバレッジをベースにAPの配置設計を行うと、
2.4GHzのチャネル被りや電波の広がりから、2.4GHzを停止することが望ましいAPが出てくるはずです。
FRAによる自動調整を使わず、どのAPでDual-5GHzを使用するかを手動で設定する場合、
それらのAPのSlotを2.4GHzから5GHzに切り替えて使用するといいでしょう。
FRAによる自動調整を使用する場合は、2.4GHzを停止しても構わないAPから
5GHzへの切り替えが行われます。手動選定の必要がないため、こちらのほうが容易です。

Catalyst 9120AXIの場合、Dual-5GHzはMacro/Micro(大セル/小セル)で動作します。
Slot0が2.4GHzと5GHzの選択が可能なSlot、Slot1が5GHz専用のSlotとなっています。
Solt0を5GHzにするとDual-5GHzの状態になり、Slot0は小セルとして動作します。パワーが最低に設定され、
APを天井面に設置した場合は、APから直下に向けたスポットライトのようなイメージでセルを形成します。
Slot1はDual-5GHzとしない状態と変わらず、APから周囲に広がるセルを形成します。
Slot0の電波は直下方向に放射され、パワーを最小にしか設定できないので、
多少離れたAPであれば干渉や混信の影響は少ないと考えていいでしょう。

セルのイメージは文末のDeployment Guideから放射パターン(Antenna Patterns)を参照してください。

このことから、
2.4GHzをそもそも使っていなかったり、いくつかのAPで無効にしている場合で、
無線LAN端末の台数が多い場合に効果的に使えます。
反対に、2.4GHzを使っていて、2.4GHzを間引かなくてもよいくらいAP間の距離がある場合は、
2.4GHzを間引いで5GHzを有効にすると2.4GHzのセルに穴ができてしまうため、使用は適当ではありません。
特に端末の機種や種類が多種多様になるゲストWi-Fiや公衆的な利用の場合、
2.4GHzのみに対応しているPCやスマートフォン等が接続できなくなります。
802.11ac, 11axが普及しつつある昨今でも、2.4GHzのみに対応した端末が存在します。

チャネルボンディングで40MHz幅や80MHz幅を使用している場合の懸念はその通りです。
(チャネルボンディングについて関して多くの意見や考え方があるのは承知の上で、ひとつの考え方として申し上げます)
端末やAPの台数が多くなるオフィスや会議室のような環境では、
40/80MHzというようにチャネル幅を固定したチャネルボンディングは使用せず、
旧来と同様に20MHz幅で運用する、もしくはWLCのDBS(Dynamic Bandwidth Selection)を使用して、
チャネルボンディングの使用とチャネル幅の選択をWLCに任せることが良いだろうと考えています。
DBSを使用すれば、WLCが干渉等の影響が少ないと判断した時に、40MHzや80MHzのチャネルボンディングが自動設定されます。

ありふれた業務用のアプリケーションで無線LANを介して通信するものは、おそらく20MHzの帯域幅で
足りるものが多いだろうと思われ、チャネルボンディングの必要性はそう高くないと考えています。
昨今の状況から、ビデオ会議などリアルタイム性が高い通信の利用シーンが多いと思われますので、
チャネルボンディングを使用して帯域幅を優先するより、Dual-5GHzを使用してチャネルやSlotあたりの端末数を分散し、
遅延が少なくなるような無線LANネットワークを目指すほうが、より良いユーザビリティを提供できると考えられます。

長くなってしまったのでまとめますが、
ほとんどのAPでDual-5GHzを使用する方針は問題ないと思います。
その際に、以下のポイントを念頭に実施を検討ください。
・2.4GHzのみ対応の端末への考慮
 (必要に応じて)いくつかのAPでは2.4GHzを有効にしておく
・チャネルボンディングの可否
 (特にAP台数が多いとき)20MHzで運用する もしくは DBS を使用
・モニターモード
 20MHz固定設定やDBSを使用してもチャネル干渉(使用率が高い等)が発生する場合に検討


(参考記事)
Dual-5GHzについては弊社ブログ記事に紹介があります。
機能や動作の理解につながると思いますので、もしよければお目通しください。
Cisco IEEE802.11ac wave2対応アクセスポイント Flexible Radio Assignment機能のメリット
https://www.netone.co.jp/knowledge-center/blog-column/knowledge_takumi_092/

無線端末の接続数が増大する状況でも快適に無線LANを利活用するための挑戦(Dual5GHz帯モード)
https://www.netone.co.jp/knowledge-center/blog-column/knowledge_takumi_164/

Ciscoデプロイガイド
Cisco Catalyst 9120 Access Point Deployment Guide
https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/guide-c07-742311.html

返信に時間を要し、失礼いたしました。

詳細かつ丁寧なご回答、誠にありがとうございます。

 

内容はどれもこれも成程と頷ける得難いものばかりで、無線LAN設計の真髄を見た思いです。(これ程の解説を無償でご教授いただけるのが信じられないくらいです)

参考記事も合わせて精読しましたが、おかげ様で、これで各機能をどのような環境/条件の際に、どのように使用したら良いかが理解出来ました。

ご教授いただいた内容を、早速設計・設定に反映させたいと思います。

 

追加の質問はありませんので、本件はこれにて完了としていただいて結構です。

ご対応いただきましてありがとうございました。厚く厚く御礼申し上げます。

GonDad04010
Beginner

Catalyst9800 や Aire-OS の WLC を使用して、無線クライアントが接続する AP を
コントロールすることは可能でしょうか?

例えば、会議室に2つのAP(AP#1とAP#2)があって同じSSIDを広報している環境で、
AさんはAP#1に接続させる、BさんはAP#2に接続させる、といったことが実現可能なのか
教えていただけますでしょうか。

Cisco Ask Me Anythingに、ご投稿頂き有難うございます。下記に回答させていただきます。

 

ご質問の内容ですが、基本的に同一のSSIDを利用している場合、クライアントの接続先APをWLC側から厳密に制御することは不可能です。
というのも、どのAPに接続しに行くかはクライアント側が判断しているためです。
(選択アルゴリズムに関してもクライアント側の実装によるためです)

 

Aggressive Load Balancingを有効にし、接続時の偏りを促したり、
802.1X/EAPなどを利用している際に「許可したAP以外からの接続の場合は認証NGとする」というような認証ルールをRADIUSサーバで設定することも不可能ではありませんが、接続できなかったクライアントが別APに接続先を切り替えるかどうか、という判断はクライアントが行います。
当然同一APに再度接続要求を送信するクライアントも存在します。

 

接続後のクライアントの偏りの観点で言えば802.11vを有効にすることで解消できる場合もありますが、11v対応のクライアントにおいてもローミングを行う判断は最終的にはクライアントになるため100%の効果を期待できるものではありません。

 

明示的に接続先を限定したい場合、SSIDを分ける等設計での対応を行ってください。

ご回答ありがとうございました!

isxx-xx
Beginner

通信遅延などの無線環境の障害として、他APや電子レンジ等の周りから影響を受けた電波干渉が原因になりえるかと思いますが、
その原因切り分けを行う方法として何かいい方法はございませんでしょうか。

本来であれば何かツールを使ってサーベイし、電波環境を調査するのが一番だとは思いますが、
お客様がツールを持っているケースがほとんどありません。
そのため、CleanAirが一つの機能だとは思いますが、Cat9800やWLCのログ機能やほかの何らかの機能を利用して、
電波干渉が障害の原因かどうかを切り分けを行いたいと考えております。

WLC Cat9800 や CT5520等 で電波干渉の可能性を確認できる項目は以下4点と思います。
なお、WLCで確認する場合、基本的には今の時点で起こっていることや状態を確認できます。
過去に起こっていた電波の状態や干渉を知ることはできないとお考え下さい。
・Channel Utilization
・CleanAir
・Rogue AP
・Neighboring AP

まず、電波干渉で通信影響が出ている場合、Channel Utilization(チャネル使用率)が上昇します。
障害の原因が電波干渉かどうかを確認するため、通信影響などの障害が発生した時に
チャネル使用率がどう変化しているかを確認してください。
これは個人的な感覚ですが、2.4GHz帯でチャネル使用率が
おおよそ70%を超えると明らかに通信遅延やスループット低下が顕著になります。

チャネル使用率が高い場合、上昇の原因を探ります。
CleanAirに対応したAPとWLCであれば、どのような種類の機器が影響を与えているかを確認でき、
例えば電子レンジであればMicrowave ovenと表示されます。

加えて、無線LANデバイスも電波的な干渉源になりえます。
同じチャネルで特に電波強度が高いAPを排除したり制御することで通信環境を改善できるかもしれません。

管理外のAPが使用しているチャネルや電波強度をRogue APの情報から確認できます。
ただ現実的にはRogue APを発見・排除することは容易でない場合もあり、
ゼロにできなかったり、あきらめたりという判断も選択の一つと思います。
管理下のAPでも隣接するAPが使用しているチャネルや電波強度をNeighboring APの情報から確認できます。
特にAPを数多く設置している環境では、自動電波制御(RRM)を使っても同じチャネルを使用して、
お互いに干渉しあってしまうことがありますので、いくつかのAPで2.4GHz帯の停止(間引き)も検討します。

最後に、こういった状況を syslog や SNMP Trap といったログで確認することはできないと考えています。
管理製品の PI(Prime Infrastructure) や DNA Center の Assurance 機能を使用すると、
チャネル使用率やノイズの情報が自動的に蓄積されますので、
過去の情報を確認するためにはこういった機器との連携が現実的と思います。

Catalystシリーズになってから、バグのせいか、無線通信が安定しないという話を耳にしました。

ファームウェアや機種の組み合わせで鉄板な構成があればお教えください。

また、axはクライアントとの相性が出てトラブルになったりするので、まだ提案しないほうが良いのでしょうか。

Cisco Ask Me Anythingに、ご投稿頂き有難うございます。下記に回答させていただきます。

 

物理ハードウェアモデルも仮想モデル(-CL)も、ソフトウェアのバージョンリリースは基本的に同じですので、機種によるバージョン差異は基本的にありません。
同一ホストに存在する別VMの影響を受けるという概念が基本的にない物理ハードウェアのほうが外部要因の少なさという点ではメリットがあるかと思います。
なお弊社ネットワンシステムズでは物理モデルを購入されるお客様の割合が多くなっています。

 

OSバージョンの選定ですが、以下のようなポイントがあるかと思います。
・利用したいAPが対応していること
→バージョンにより利用できるAPに違いがある(最新APは最新リリースOSでないと対応しない)

 

・TAC Recommended Buildを利用する
→Cisco TACのオススメバージョンが以下に記載されています。また、下記にあるLong-Lived/Short-Livedの情報も記載されています。
https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214749-tac-recommended-ios-xe-builds-for-wirele.html

 

・Long-Lived Releaseであること、不具合の修正状況
→必須ではありませんが、メンテナンスが進んでいるほど不具合が修正されてケースが多いです(Release NoteのOpen/Resolved Caveatsを確認)

 

また、定期的にWireless TAC Timeという名称で不具合の情報やベストプラクティスなどのTips情報などを紹介するセミナーが開催されていますので、こちらに参加して情報を得るのもおすすめです。
https://community.cisco.com/t5/%E3%83%AF%E3%82%A4%E3%83%A4%E3%83%AC%E3%82%B9-%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88/wireless-tac-time-%E4%BB%8A%E3%81%99%E3%81%90%E7%8F%BE%E5%A0%B4%E3%81%AB%E5%8A%B9%E3%81%8F-tips-%E7%B4%B9%E4%BB%8B/ba-p/4266157


また802.11ax(Wi-Fi6)対応APでの提案に関してですが、1世代前のAPx800シリーズは当然Catalyst9100より先行してEoS/EoLを迎えることになります。
これから提案される場合、特別の事情がない限り(既にAPx800シリーズを使用していてそこへの追加等)、Catalyst9100シリーズAPを選択するほうが製品のライフサイクルを考えた場合、長く利用することができるでしょう。

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

承知いたしました。

 

他メーカーを検討しようとしておりましたが、もう少し情報収集してみます。

bear
Beginner

・突然の通信遮断時の切替動作について

 

Cisco Aironet 1852I (Mobility Express) を利用し30mほどの廊下に鉄扉を介し2台設置している環境下で、

 

   AP1---------------------|||-------------------------AP2

               鉄扉(閉じたとき、ほぼ完全に電波を遮断)

(AP1とAP2はME配下で同一ESSIDを利用)

 

クライアントデバイスはAndroidスマートフォン(android 9) 1台で

立ち止まっている状況での通信及び利用は問題なく、

また扉が開きっぱなしの状態では電波状況に応じ瞬時にハンドオーバーされることは確認しております。

 

しかしながら鉄扉閉じているとき、例えばAP1に接続した状態で移動し、鉄扉を開き、AP2側に移動し、閉じた瞬間、

AP1からの電波が遮断され、AP2側への切り替えまでに数秒~十数秒ほどの時間を要します。

 

クライアントデバイス側の挙動によって切替時間は様々かと思いますが、こういった突然の(急激な)電波遮断に対し、WLAN側で対応できることはあるでしょうか?

設計自体に問題はないものとしてお考え頂けると幸いです。

 

あるいはCisco-Apple連携によりiOSデバイスを用いることで、瞬時に切り替わるなどあればご教示下さい。

その他、類似のご経験や事例などでも構いません。

 

お手数ですがよろしくお願いいたします。

質問いただいた事象はありふれたもので、理解いただいている通りクライアントデバイスの挙動や仕様に依存します。
アクセスポイントやWLC等で確実に解決するような方法は、残念ながらないと考えられます。
確実性は高くないですが、切り替え(ローミング)の所要時間を短くするために二つのアイディアがあります。

1.RFのセルサイズを小さくする
クライアントデバイスは電波強度や品質等からローミングすることを判断しています。
このアルゴリズムはデバイスやWLAN NIC、ドライバの実装に依存します。

クライアントデバイスがローミングしたくなる境界がちょうど鉄扉の位置にあれば、
鉄扉の手前ではAP1に、奥ではAP2に、クライアントデバイスがローミングすることが期待できます。
AP1側からAP2側にデバイスをもって移動し鉄扉を越えたとき、AP1からAP2にローミングが発生すれば、
鉄扉を開閉したときのような切り替わり時間がかからなくなると考えられます。

このために、APからの電波の送信出力を弱める方向に調整してください。
鉄扉の周辺でクライアントデバイスがローミングするように仕向けます。
ただし、これによりAPからの電波の到達性が短く(狭く)なるため、
そのほかの場所で通信環境が悪くなってしまうデメリットもあります。

2.802.11k/vを有効化する
802.11k, 802.11vというローミングを促したり、支援する機能があります。
Mobility Express では Version 8.4 以降で対応しており、初期値で有効となっている機能です。
11kにより、クライアントデバイスはAPの隣接情報(ネイバーリスト)を取得でき、
ローミング可能なAPを事前に把握することができるので、ローミング先APを探す時間を短縮できます。
また、11vにより、APは接続状態が悪くなったクライアントデバイスに対し、ローミングを促すことができます。

クライアントデバイスもこれらの機能に対応している必要があり、
また当方も実機での動作を確認したことがないため、未知数な部分もあるのですが、
理想通り動作すれば、ローミング時間の短縮につながることが期待できます。

Appleデバイスはこれらの連係動作がメーカー間で確認されており、
Androidデバイスに比べてよりシームレスな動作ができると思われます。
しかしながら、無線LANは使用環境に依存する要素が非常に多いため、
Appleデバイスを使用したとしても、改善は確実なものではありません。

(参考記事)
iOS での 802.11k、802.11r、802.11v による Wi-Fi ネットワークローミング
https://support.apple.com/ja-jp/HT202628
802.11k/vについては、Appleが概要を紹介する記事を公開しています。
Cisco Mobility Express Deployment Guide Release 8.4.100.0
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-4/b_cisco_mobility_express_8_4/b_cisco_mobility_express_8_4_chapter_0110.html#task_02ABB3D87ACF4C28A2194317118FE3A8
Mobility Expressにおける802.11k/vの設定方法はCiscoのDeploy Guideに記載があります。

isxx-xx
Beginner

Mobility Expressの環境について教えてください。

Mobility ExpressはWLCの機能を簡易的に移植したものかと思います。
Mobility Express上でWLCと同じCLIコマンドを実行自体はできるものの、
コマンドリファレンスには掲載されていないものがあります。

こういった場合、どこまでがCisco社でサポートされ、使用していいものになるのでしょうか。

メーカーエンジニアでないとお答えの難しい質問かと存じますため 弊社(シスコ)内で確認した所、Mobility Express コマンドリファレンスに記載のない場合は非サポートと回答がありました。 そのため、掲載されてない設定・機能についてはご利用は控えて頂けますようお願いいたします。

ご確認ありがとうございます。

回答いただいたようにコマンドリファレンスにないものは使用しないよう気を付けます。

nawata
Beginner

WLCや無線APの再起動を調査する際に、再起動の理由を確認する方法について教えてください。

System Informationなどで[Last reload reason]や[Last Rest]に理由が表示されますが、
ここで表示される理由について、詳細に記載された一覧表などがありました教えていただけると助かります。

Cisco Ask Me Anythingに、ご投稿頂き有難うございます。下記に回答させていただきます。

 

当方でもLast Reload reasonの一覧に関する情報は持ち合わせておりません。
Reload commandやPower cycle、watchdog timeout等は見たことがありますが、
意図しない再起動、かつ再起動理由が表示される内容を読んでも不明の場合、BST(Bug Search Tool)やコミュニティでの検索、
またログを添えてTACへ原因解析のためのケースオープンを検討いただければと思います。

 

返答が遅れてしまい失礼いたしました。