インストールと接続
手順
ステップ 1 |
RAP にするメッシュ アクセス ポイントをコントローラに接続します。 |
ステップ 2 |
目的の場所に無線(MAP)を配置します。 |
ステップ 3 |
コントローラ CLI で、show mesh ap summary コマンドを入力して、コントローラ上のすべての MAP と RAP を表示します。 ![]() |
ステップ 4 |
コントローラ GUI で、[Wireless] をクリックして、メッシュ アクセス ポイント(RAP と MAP)の概要を表示します。 ![]() |
ステップ 5 |
[AP Name] をクリックして詳細ページを表示し、[Interfaces] タブを選択して、アクティブな無線インターフェイスを表示します。 使用中の無線スロット、無線タイプ、使用中のサブバンド、動作状態(UP または DOWN)がまとめて表示されます。
|
ステップ 6 |
[Wireless] > [AP Name] をクリックして、AP 詳細ページでメッシュ アクセス ポイントのプライマリ コントローラを確認します。 |
debug コマンド
次の 2 つのコマンドは、メッシュ アクセス ポイントとコントローラ間で交換されるメッセージを表示する場合にたいへん役立ちます。
(Cisco Controller) > debug capwap events enable
(Cisco Controller) > debug disable-all
debug コマンドを使用して、メッシュ アクセス ポイントとコントローラ間で行われるパケット交換のフローを表示できます。メッシュ アクセス ポイントで、検索プロセスが起動します。加入フェーズでクレデンシャルの交換が行われ、メッシュ アクセス ポイントがメッシュ ネットワークへの加入を許可されることが認証されます。
加入が正常に完了すると、メッシュ アクセス ポイントは CAPWAP 設定要求を送信します。コントローラは設定応答で応答します。メッシュ アクセス ポイントはコントローラからの設定応答を受信すると、各設定要素を評価し、それらを実装します。
リモート デバッグ コマンド
AP コンソール ポートへの直接接続またはコントローラのリモート デバッグ機能のいずれかによって、デバッグのために、メッシュ アクセス ポイント コンソールにログインできます。
コントローラでリモート デバッグを起動するには、次のコマンドを入力します。
(Cisco Controller) > debug ap enable ap-name
(Cisco Controller) > debug ap command command ap-name
AP コンソール アクセス
AP1500 にはコンソール ポートがあります。メッシュ アクセス ポイントにはコンソール ケーブルが付属していません。1550 シリーズのアクセス ポイントの場合、コンソール ポートは簡単にアクセスでき、アクセス ポイント ボックスを開く必要はありません。
AP1500 では、コードにコンソール アクセス セキュリティが埋め込まれており、コンソール ポートへの不正アクセスを防止し、セキュリティが拡張されています。
コンソール アクセス用の ログイン ID とパスワードはコントローラから設定します。次のコマンドを使用して、ユーザ名/パスワードの組み合わせを指定したメッシュ アクセス ポイントまたはすべてのアクセス ポイントに適用できます。
<Cisco Controller> config ap username cisco password cisco ?
all Configures the Username/Password for all connected APs.
<Cisco AP> Enter the name of the Cisco AP.
<Cisco Controller> config ap username cisco password cisco all
コントローラから適用されたユーザ名/パスワードがメッシュ アクセス ポイントのユーザ ID とパスワード として使用されているか確認する必要があります。これは不揮発性設定です。ログイン ID とパスワード は、設定すると、メッシュ アクセス ポイントのプライベート設定に保存されます。
ログインに成功すると、トラップが Cisco Prime Infrastructure に送信されます。ユーザが 3 回連続してログインに失敗すると、ログイン失敗トラップがコントローラと Cisco Prime Infrastructure に送信されます。
![]() 注意 |
メッシュ アクセス ポイントは、別の場所に移動する前に、出荷時のデフォルト設定にリセットする必要があります。 ![]() |
AP からのケーブル モデムのシリアル ポート アクセス
コマンドは、CLI の特権モードからケーブル モデムに送信できます。コマンドを使用してテキスト文字列を取得し、ケーブル モデム UART インターフェイスに送信します。ケーブル モデムはそのテキスト文字列を独自のコマンドの 1 つとして解釈します。ケーブル モデムの応答が取得され、Cisco IOS コンソールに表示されます。ケーブル モデムからは、最大 9600 文字が表示されます。4800 文字を超えるテキストはすべて切り捨てられます。
モデムのコマンドは、元々ケーブル モデム用である UART ポートに接続されているデバイスがあるメッシュ AP でのみ使用できます。ケーブル モデムがない、または他のデバイスが UART に接続されているメッシュ AP でコマンドを使用した場合、コマンドは受け入れられますが、戻される出力は生成されません。明示的にフラグが付けられるエラーはありません。
設定
MAP の特権モードから次のコマンドを入力します。
AP#send cmodem timeout-value modem-command
modem コマンドは、ケーブル モデムに送信する任意のコマンドまたはテキストです。タイムアウト値の範囲は 1 ~ 300 秒です。ただし、取得されたデータが 9600 文字の場合、9600 文字を超えるテキストは切り捨てられ、タイムアウト値とは関係なく、応答が AP コンソールにすぐに表示されます。
![](/c/dam/en/us/td/i/200001-300000/270001-280000/279001-280000/279059.tif/_jcr_content/renditions/279059.jpg)
![](/c/dam/en/us/td/i/200001-300000/270001-280000/279001-280000/279060.tif/_jcr_content/renditions/279060.jpg)
![]() 注意 |
疑問符(?)と感嘆符(!)は、send cmodem コマンドでは使用できません。これらの文字は、Cisco IOS CLI で即座に別の意味に解釈されます。そのため、モデムに送信できません。 |
ケーブル モデム コンソール ポートの有効化
![]() (注) |
AP1572EC、AP1572IC、AP1552C および AP1552CU の場合、ケーブル モデムを有効にする必要があります。 |
-
ケーブル モデムの IP アドレスに次のコマンドを入力して、SNMP を介してケーブル モデム コンソール ポートを有効にします。
OID を使用して、次のコマンドを入力します。snmpset –c private IP_ADDRESS cmConsoleMode.0 i N
IP_ADDRESS は任意の Ipv4 アドレス、N は整数、2 は読み取りと書き込みの有効化、1 は読み取り専用、0 は無効化です。snmpset –c private IP_ADDRESS 1.3.6.1.4.1.1429.77.1.4.7.0 i N
例: snmpset -c private 209.165.200.224 cmConsoleMode.0 i 2
-
コンフィギュレーション ファイルからケーブル モデム コンソール ポートを有効にします。コンフィギュレーション ファイル(.cm 拡張子)は、ケーブル モデム ヘッド エンドにロードされます。参加プロセスの一部としてケーブル モデムにプッシュされます。ケーブル モデム コンフィギュレーション ファイルに次の行を入力します。
OID を使用して、この行を入力します。SA-CM-MIB::cmConsoleMode.0 = INTEGER: readWrite(2)
SA-CM-MIB::cmConsoleMode.0 = INTEGER: readWrite(2)
ケーブル モデムを使用した AP1572xC/AP1552C のリセット
AP はアクセス ポイント内にあるケーブル モデムへ SNMP コマンドを入力してリセットできます。この機能を動作させるには、ケーブル モデム コンソール ポートを有効にする必要があります。
Snmpset -v2c -c public IP ADDRESS 1.3.6.1.4.1.1429.77.1.3.17.0 i 1
IP ADDRESS は、ケーブル モデムの IPv4 アドレスです。 メッシュ アクセス ポイント CLI コマンド
次のコマンドは、メッシュ アクセス ポイントで AP コンソール ポートを使用して直接入力できます。コントローラのリモート デバッグ機能を使用して入力することもできます。
![](/c/dam/en/us/td/i/400001-500000/400001-410000/404001-405000/404484.tif/_jcr_content/renditions/404484.jpg)
![](/c/dam/en/us/td/i/400001-500000/400001-410000/404001-405000/404485.tif/_jcr_content/renditions/404485.jpg)
![](/c/dam/en/us/td/i/400001-500000/400001-410000/404001-405000/404486.tif/_jcr_content/renditions/404486.jpg)
![](/c/dam/en/us/td/i/400001-500000/400001-410000/404001-405000/404487.tif/_jcr_content/renditions/404487.jpg)
![](/c/dam/en/us/td/i/200001-300000/270001-280000/273001-274000/273949.tif/_jcr_content/renditions/273949.jpg)
![](/c/dam/en/us/td/i/200001-300000/270001-280000/273001-274000/273950.tif/_jcr_content/renditions/273950.jpg)
メッシュ アクセス ポイント デバッグ コマンド
次のコマンドは、メッシュ アクセス ポイントで AP コンソール ポートを使用して直接入力しても、コントローラでリモート デバッグ機能を使用しても、入力できます。
-
debug mesh ethernet bridging :イーサネット ブリッジングをデバッグします。
-
debug mesh ethernet config :VLAN タギングに関連付けられているアクセスおよびトランク ポート設定をデバッグします。
-
debug mesh ethernet registration :VLAN レジストレーション プロトコルをデバッグします。このコマンドは、VLAN タギングに関連付けられています。
-
debug mesh forwarding table :ブリッジ グループが含まれている転送テーブルをデバッグします。
-
debugs mesh forwarding packet bridge-group :ブリッジ グループ設定をデバッグします。
メッシュ アクセス ポイントの役割の定義
デフォルトでは、AP1500 の無線の役割は MAP に設定されています。そのため、メッシュ アクセス ポイントを RAP として機能させるために、その無線の役割を変更する必要があります。
メッシュ アクセス ポイントのこの設定は、config ap role {rootAP | mesh AP | default} コマンドを使用して、屋上アクセス ポイントまたはメッシュ アクセス ポイントとして静的に設定することで変更できます。
無線の役割は GUI を使用して変更することもでき、その手順は次のとおりです。
手順
ステップ 1 |
[Wireless] > [Access Points] > [All APs] の順に選択して、[All APs] ページを開きます。 |
||
ステップ 2 |
変更するメッシュ アクセス ポイントの名前をクリックします。[Mesh] タブをクリックします。 |
||
ステップ 3 |
[AP Role] ドロップダウンリストから、[MeshAP] または [RootAP] を選択して、このメッシュ アクセス ポイントを MAP または RAP として指定します。 |
||
ステップ 4 |
[Apply] をクリックして、変更を確定します。メッシュ アクセス ポイントがリブートします。 |
||
ステップ 5 |
[Save Configuration] をクリックして、変更を保存します。
|
バックホール アルゴリズム
バックホールは、メッシュ アクセス ポイント間に無線接続だけを作成するために使用します。
デフォルトでバックホール インターフェイスは 802.11a です。バックホール インターフェイスを 802.11b/g に変更できません。
AP1500 には、デフォルトで「自動」データ レートが選択されています。
バックホール アルゴリズムは、孤立状態のメッシュ アクセス ポイントの状況に対処するために設計されました。このアルゴリズムは、各メッシュ ノードに高いレベルの復元力も追加します。
このアルゴリズムは、次のようにまとめることができます。
-
MAP は常に、イーサネット ポートが UP の場合はイーサネット ポートをプライマリ バックホールとして設定し、UP でない場合は 802.11a 無線として設定します(この機能により、ネットワーク管理者は、イーサネット ポートを最初に RAP として設定し、社内で回復することができます)。ネットワークの高速コンバージェンスを可能にするため、メッシュ ネットワークへの最初の加入では、イーサネット デバイスを MAP に接続しないことを推奨します。
-
UP であるイーサネット ポートで WLAN コントローラへの接続が失敗した MAP は 802.11a 無線をプライマリ バックホールとして設定します。ネイバーの検索に失敗するか、802.11a 無線上でネイバーを経由した WLAN コントローラへの接続が失敗すると、イーサネット ポートで、再度プライマリ バックホールが UP になります。MAP は同じ BGN を持つ親を優先します。
-
イーサネット ポートを介してコントローラに接続されている MAP は、(RAP とは違って)メッシュ トポロジをビルドしません。
-
RAP は、常にイーサネット ポートをプライマリ バックホールとして設定します。
-
RAP のイーサネット ポートが DOWN の場合、または RAP が UP であるイーサネット ポートでコントローラに接続できない場合、802.11a 無線がプライマリ バックホールとして設定されます。ネイバーの検索に失敗するか、802.11a 無線上でネイバーを経由したコントローラへの接続が失敗すると、15 分後に、RAP が SCAN 状態になり、イーサネット ポートが最初に起動します。
前述のアルゴリズムを使用して、メッシュ ノードの役割を保持すると、メッシュ アクセス ポイントが不明状態になり、ライブ ネットワークで孤立状態になるのを避けることができます。
パッシブ ビーコン(ストランディング防止)
パッシブ ビーコンをイネーブルにすると、孤立状態のメッシュ アクセス ポイントで、802.11b/g 無線を使用して、無線でそのデバッグ メッセージをブロードキャストできます。孤立状態のメッシュ アクセス ポイントをリッスンし、コントローラとの接続がある隣接メッシュ アクセス ポイントは、それらのメッセージを CAPWAP 経由でコントローラに渡します。パッシブ ビーコンにより、有線接続のないメッシュ アクセス ポイントが孤立状態になるのを防ぎます。
デバッグ ログもバックホール以外の無線で、救難ビーコンとして送信できるため、隣接メッシュ アクセス ポイントをビーコンのリッスン専用にすることができます。
メッシュ アクセス ポイントでコントローラへの接続が失われると、コントローラで次の手順が自動的に起動されます。
-
孤立状態のメッシュ アクセス ポイントの MAC アドレスを識別する
-
CAPWAP が接続されているすぐ近くのネイバーを見つける
-
リモート デバッグによってコマンドを送信する
-
チャネルを循環してメッシュ アクセス ポイントを追跡する
この機能を使用するために、知っている必要があるのは孤立状態の AP の MAC アドレスだけです。
メッシュ アクセス ポイントは、孤立タイマーのリブートが実行された場合に孤立状態と見なされます。孤立タイマーのリブートが発生すると、現在孤立状態のメッシュ アクセス ポイントで、孤立防止機能のパッシブ ビーコンが有効になります。
この機能は 3 つの部分に分けられます。
-
孤立状態のメッシュ アクセス ポイントによる孤立検出
-
孤立状態のメッシュ アクセス ポイントによって送信されるビーコン
-
802.11b 無線をチャネル(1、6、11)にラッチする
-
デバッグをイネーブルにする
-
孤立デバッグ メッセージを救難ビーコンとしてブロードキャストする
-
最新のクラッシュ情報ファイルを送信する
-
-
ビーコンの受信(リモート デバッグがイネーブルになっている隣接メッシュ アクセス ポイント)
構成されたメッシュ アクセス ポイントは定期的に孤立状態のメッシュ アクセス ポイントを検索します。メッシュ アクセス ポイントは定期的に孤立状態のメッシュ アクセス ポイントのリストと SNR 情報をコントローラに送信します。コントローラはネットワーク内の孤立状態のメッシュ アクセス ポイントのリストを保持します。
debug mesh astools troubleshoot mac-addr start コマンドを入力すると、コントローラはリストを検索して、孤立状態のメッシュ アクセス ポイントの MAC アドレスを見つけます。
孤立状態のアクセス ポイントのリッスンを開始するメッセージが最適なネイバーに送信されます。リッスンしているメッシュ アクセス ポイントは、孤立状態のメッシュ アクセス ポイントからの救難ビーコンを取得し、コントローラに送信します。
メッシュ アクセス ポイントは、リスナーの役割を担うと、孤立状態のメッシュ アクセス ポイントのリッスンを停止するまで、孤立状態のメッシュ アクセス ポイントをその内部リストから消去しません。孤立状態のメッシュ アクセス ポイントのデバッグ中に、そのメッシュ アクセス ポイントのネイバーが一定の割合で、現在のリスナーより優れた SNR をコントローラに報告した場合、ただちに孤立状態のメッシュ アクセス ポイントのリスナーが新しいリスナー(SNR が優れた)に変更されます。
エンドユーザ コマンドは次のとおりです。
-
config mesh astools [enable | disable ] :メッシュ アクセス ポイントの astools を有効または無効にします。ディセーブルの場合、AP は孤立状態の AP リストをコントローラに送信しません。
-
show mesh astools stats :孤立状態の AP とそれぞれのリスナー(存在する場合)のリストを表示します。
-
debug mesh astools troubleshoot mac-addr start :mac-addr の最適なネイバーに、リッスンを開始するメッセージを送信します。
-
debug mesh astools troubleshoot mac-addr stop :mac-addr の最適なネイバーに、リッスンを停止するメッセージを送信します。
-
clear mesh stranded [all | mac of b/g radio] :孤立状態の AP エントリをクリアします。
コントローラ コンソールは、30 分間、孤立状態の AP からのデバッグ メッセージでいっぱいになります。
Dynamic Frequency Selection(動的周波数選択)
このセクションでは、RAP および MAP での DFS(動的周波数選択)機能について説明します。
RAP の DFS
RAP ではレーダー検出の応答として、次の手順が実行されます。
-
RAP が、チャネルがレーダーに影響を受けるコントローラにメッセージを送信します。チャネルが、RAP およびコントローラで影響を受けるチャネルとしてマークされます。
-
RAP がそのチャネルを 30 分間ブロックします。この 30 分間は非占有期間と呼ばれます。
-
コントローラが、チャネルでレーダーが検出されたことを示す TRAP を送信します。TRAP は非占有期間が経過するまで留まります。
-
RAP は 10 秒間でチャネルから移行します。これは、チャネル移行時間と呼ばれます。システムがチャネルをクリアする時間として定義され、レーダー バーストの終わりからチャネルの最終送信の終わりまで測定されます。
-
RAP が Quite モードに入ります。Quite モードで、RAP がデータ伝送を停止します。ビーコンは引き続き生成され、プローブ応答も引き続き配信されます。Quiet モードは、チャネル移行時間(10 秒)が終了するまで存続します。
-
コントローラが新しいランダム チャネルを選択し、チャネル情報を RAP に送信します。
-
RAP が新しいチャネル情報を受信し、チャネル変更フレーム(ユニキャスト、暗号化)を MAP に送信し、各 MAP が同じ情報をセクターの下位の子に送信します。各メッシュ アクセス ポイントは、100 ミリ秒ごとに 1 回ずつ合計 5 回、チャネル変更フレームを送信します。
-
RAP が新しいチャネルにチューニングし、サイレント モードになります。サイレント モード中は、レシーバだけが ON になります。RAP が新しいチャネルで、60 秒間レーダーの存在をスキャンし続けます。このプロセスは、チャネル アベイラビリティ チェック(CAC)と呼ばれます。
-
MAP が新しいチャネルにチューニングし、サイレント モードになります。サイレント モード中は、レシーバだけが ON になります。MAP が新しいチャネルで、60 秒間レーダーの存在をスキャンし続けます。
-
レーダーが検出されない場合、RAP がこの新しいチャネルですべての機能を再開し、セクター全体がこの新しいチャネルにチューニングされます。
MAP の DFS
MAP ではレーダー検出の応答として、次の手順が実行されます。
-
MAP が、レーダー発見の指示を親と、最終的にそのチャネルが影響を受けることを示している RAP に送信します。RAP がこのメッセージをコントローラに送信します。このメッセージは、RAP から送信されたものであるように表示されます。MAP、RAP、およびコントローラが 30 分間影響を受けるものとしてチャネルをマークします。
-
MAP が 30 分間チャネルをブロックします。この 30 分間は非占有期間と呼ばれます。
-
コントローラが、チャネルでレーダーが検出されたことを示す TRAP を送信します。TRAP は非占有期間が経過するまで留まります。
-
MAP は 10 秒間でチャネルから移行します。これは、チャネル移行時間と呼ばれます。システムがチャネルをクリアする時間として定義され、レーダー バーストの終わりからチャネルの最終送信の終わりまで測定されます。
-
MAP が Quite モードに入ります。Quite モードで、MAP がデータ伝送を停止します。ビーコンは引き続き生成され、プローブ応答も引き続き配信されます。Quiet モードは、チャネル移行時間(10 秒)が終了するまで存続します。
-
コントローラが新しいランダム チャネルを選択し、チャネルを RAP に送信します。
-
RAP が新しいチャネル情報を受信し、チャネル変更フレーム(ユニキャスト、暗号化)を MAP に送信し、各 MAP が同じ情報をセクターの下位の子に送信します。各メッシュ アクセス ポイントは、100 ミリ秒ごとに 1 回ずつ合計 5 回、チャネル変更フレームを送信します。
-
各メッシュ アクセス ポイントが新しいチャネルにチューニングし、サイレント モードになります。サイレント モード中は、レシーバだけが ON になります。パケット伝送は行われません。AP が新しいチャネルで、60 秒間レーダーの存在をスキャンし続けます。このプロセスは、チャネル アベイラビリティ チェック(CAC)と呼ばれます。MAP はコントローラから切断されない必要があります。この 1 分間、ネットワークは安定した状態を維持する必要があります。
DFS 機能により、レーダー信号を検出した MAP はそれを RAP まで伝送することができ、RAP はレーダーを経験したことがあるかのように動作し、セクターを移動します。このプロセスは、コーディネイテッド チャネル変更と呼ばれます。コントローラで、この機能はオンまたはオフにできます。コーディネイテッド チャネル変更は、デフォルトでイネーブルになっています。
DFS をイネーブルにするには、次のコマンドを入力します。
(Cisco Controller) > config mesh full-sector-dfs enable
ネットワークで DFS がイネーブルになっているかどうかを確認するには、次のコマンドを入力します。
(Cisco Controller) > show network summary
![]() (注) |
レーダーを検出した MAP は、親の BGN が異ならない限り、RAP にメッセージを送信する必要があります。この場合、コーディネイテッド セクター変更のメッセージを送信しません。代わりに、MAP は再度 SCAN 状態になり、レーダーが発見されなかったチャネルで、新しい親を検索します。 |
![]() (注) |
いずれのメッシュ アクセス ポイントもデフォルトの BGN を使用していないことを確認します。 |
![]() (注) |
MAP で繰り返されたレーダー イベント(レーダーは 1 回トリガーすると、ほとんどすぐに再度トリガーする)により、MAP が切断されます。 |
DFS 環境での準備
この項では、DFS 環境での準備方法について説明します。
-
コントローラが正しい国の地域に設定されていることを確認するには、次のコマンドを入力します。
(Cisco Controller) > show country
-
メッシュ アクセス ポイントの国とコントローラのチャネル設定を確認するには、次のコマンドを入力します。
(Cisco Controller)> show ap config 802.11a ap-name
-
メッシュに使用可能なチャネルを識別するには、次のコマンドを入力します。
(Cisco Controller)> show ap config 802.11a ap-name
許可されたチャネル リストを検索します。
Allowed Channel List....................... 100,104,108,112,116,120,124, ......................................... 128,132,136,140
-
AP コンソールで(またはコントローラからリモート デバッグを使用して)メッシュに使用可能なチャネルを識別するには、次のコマンドを入力します。
ap1520-rap # show mesh channels HW: Dot11Radio1, Channels: 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
チャネルの横のアスタリスクは、チャネルでレーダーが検出されたことを示します。
-
リモート デバッグを起動するには、次のコマンドを入力します。
(Cisco Controller) > debug ap enable ap-name (Cisco Controller) > debug ap command command ap-name
-
DFS チャネルのレーダー検出と過去のレーダー検出を確認するためのデバッグ コマンドは、次のようになります。
show mesh dfs channel channel-number show mesh dfs history
以下のような情報が表示されます。
ap1520-rap # show mesh dfs channel 132
Channel 132 is available Time elapsed since radar last detected: 0 day(s), 7 hour(s), 6 minute(s), 51 second(s).
RAP はすべてのチャネルを調べ、各チャネルにアクティブなレーダーがあるかどうかを判断する必要があります。
ap1520-rap # show mesh dfs channel 132 Radar detected on channel 132, channel becomes unusable (Time Elapsed: 0 day(s), 7 hour(s), 7 minute(s), 11 second(s)). Channel is set to 100 (Time Elapsed: 0 day(s), 7 hour(s), 7 minute(s), 11 second(s)). Radar detected on channel 116, channel becomes unusable (Time Elapsed: 0 day(s), 7 hour(s), 6 minute(s), 42 second(s)). Channel is set to 64 (Time Elapsed: 0 day(s), 7 hour(s), 6 minute(s), 42 second(s)). Channel 132 becomes usable (Time Elapsed: 0 day(s), 6 hour(s), 37 minute(s), 10 second(s)). Channel 116 becomes usable (Time Elapsed: 0 day(s), 6 hour(s), 36 minute(s), 42 second(s)).
DFS のモニタ
DFS 履歴は、レーダーを検出するために、毎朝、またはより頻繁に実行する必要があります。この情報は消去されず、メッシュ アクセス ポイントのフラッシュに保存されます。そのため、ユーザは時間を合わせるだけで済みます。
ap1520-rap # show controller dot11Radio 1
以下に類似した情報が表示されます。
interface Dot11Radio1
Radio Hammer 5, Base Address 001c.0e6c.9c00, BBlock version 0.00, Software version 0.05.30
Serial number: FOC11174XCW
Number of supported simultaneous BSSID on Dot11Radio1: 16
Carrier Set: ETSI (OFDM) (EU) (-E)
Uniform Spreading Required: Yes
Current Frequency: 5540 MHz Channel 108 (DFS enabled)
Allowed Frequencies: *5500(100) *5520(104) *5540(108) *5560(112) *5580(116) *560
0(120) *5620(124) *5640(128) *5660(132) *5680(136) *5700(140)
* = May only be selected by Dynamic Frequency Selection (DFS)
Listen Frequencies: 5180(36) 5200(40) 5220(44) 5240(48) 5260(52) 5280(56) 5300(6
0) 5320(64) 5500(100) 5520(104) 5540(108) 5560(112) 5580(116) 5660(132) 5680(136
) 5700(140) 5745(149) 5765(153) 5785(157) 5805(161) 5825(165) 4950(20) 4955(21)
4960(22) 4965(23) 4970(24) 4975(25) 4980(26)
![]() (注) |
アスタリスクは、このチャネルで DFS がイネーブルになっていることを示します。 |
周波数プランニング
隣接セクターの代替隣接チャネルを使用します。同じ場所に 2 つの RAP を展開する場合、それらの間に 1 つのチャネルを残しておく必要があります。
気象レーダーは 5600 ~ 5650 MHz 帯域で動作します。つまり、チャネル 124 および 128 が影響を受ける可能性があり、チャネル 120 と 132 も気象レーダーの活動に影響を受ける可能性があります。
メッシュ アクセス ポイントがレーダーを検出すると、コントローラとメッシュ アクセス ポイントは共にチャネルを設定されたチャネルとして保持します。コントローラはそれをメッシュ アクセス ポイントに関連付けられた揮発性メモリに保存し、メッシュ アクセス ポイントはそれを設定としてフラッシュに保存します。30 分の Quiet 時間後、コントローラは、メッシュ アクセス ポイントが新しいチャネルで設定されているかどうかに関係なく、メッシュ アクセス ポイントをスタティック値に戻します。これを避けるには、メッシュ アクセス ポイントを新しいチャネルで設定し、メッシュ アクセス ポイントをリブートします。
あるチャネルでレーダーが確実に検出されたら、次のように、そのチャネルおよび周囲の 2 つのチャネルを RRM 除外リストに追加する必要があります。
(Cisco Controller) > config advanced 802.11a channel delete channel
メッシュ アクセス ポイントは RRM によって選択された新しいチャネルに移行し、除外されたチャネルを考慮しません。
たとえば、チャネル 124 でレーダーが検出された場合、チャネル 120、124、および 128 を除外リストに追加する必要があります。さらに、RAP をそれらのチャネルで動作しないように設定します。
適切な信号対雑音比
ヨーロッパのインストールでは、信号対雑音比(SNR)の最小の推奨値が 20 dB に増えます。追加の dB は、DFS 以外の環境で検出されないパケット受信へのレーダー干渉の影響を緩和するために使用されます。
アクセス ポイントの配置
メッシュ アクセス ポイントのコロケーションには、最低 10 フィート(3.048 m)の垂直区切り、または 100 フィート(30.48 m)の水平区切りが必要です。
ブリッジ グループ名の誤った設定
メッシュ アクセス ポイントに、bridgegroupname が誤って指定され、意図されないグループに配置されることがあります。ネットワーク設計によっては、このメッシュ アクセス ポイントに到達して、その正しいセクターやツリーを見つけられたり、見つけられなかったりする可能性があります。メッシュ アクセス ポイントが互換性のあるセクターに到達できない場合、孤立状態になる可能性があります。
孤立状態のメッシュ アクセス ポイントを回復するために、デフォルトの bridgegroupname の概念がソフトウェアに導入されています。メッシュ アクセス ポイントは、設定された bridgegroupname を使用して他のメッシュ アクセス ポイントに接続できない場合、デフォルトの bridgegroupname を使用して接続を試みます。
この孤立状況の検出と回復のアルゴリズムは、次のようになります。
-
パッシブ スキャンを実行し、bridgegroupname に関係なく、すべてのネイバー ノードを検出します。
-
メッシュ アクセス ポイントは、AWPP を使用して、my own bridgegroupname でリッスンしたネイバーに接続します。
-
手順 2 が失敗した場合、AWPP を使用して、デフォルトの bridgegroupname で接続を試みます。
-
手順 3 で失敗した試行ごとに、ネイバーが除外リストに追加され、次の最適なネイバーへの接続が試行されます。
-
手順 4 で AP がすべてのネイバーへの接続を失敗した場合、メッシュ アクセス ポイントがリブートされます。
-
15 分間、デフォルトの bridgegroupname で接続した場合、メッシュ アクセス ポイントはスキャン状態になります。
メッシュ アクセス ポイントがデフォルトの bridgegroupname で接続できた場合、親ノードは、メッシュ アクセス ポイントをコントローラのデフォルトの子/ノード/ネイバー エントリとして報告するため、ネットワーク管理者は Cisco Prime Infrastructure になります。そのようなメッシュ アクセス ポイントは通常の(非メッシュ)アクセス ポイントとして動作し、すべてのクライアントを受け入れ、他のメッシュ ノードをその子とし、すべてのデータ トラフィックを通します。
![]() (注) |
DEFAULT の未割り当ての BGN(NULL 値)と混同しないでください。これは、アクセス ポイントで独自の BGN を見つけられない場合に、接続に使用されるモードです。 |
メッシュ アクセス ポイントの BGN の現在の状態を確認するには、次のコマンドを入力します。
(Cisco Controller)> show mesh path Map3:5f:ff:60
00:0B:85:5F:FA:60 state UPDATED NEIGH PARENT DEFAULT (106B), snrUp 48, snrDown 48, linkSnr 49
00:0B:85:5F:FB:10 state UPDATED NEIGH PARENT BEACON (86B) snrUp 72, snrDown 63, linkSrn 57
00:0B:85:5F:FA:60 is RAP
メッシュ アクセス ポイントの BGN の現在の状態を確認し、メッシュ アクセス ポイントのネイバー情報を確認するには、次の手順を実行します(GUI)。
[Wireless] > [All APs] > [AP Name] > [Neighbor info] を選択します。
![](/c/dam/en/us/td/i/200001-300000/270001-280000/273001-274000/273956.tif/_jcr_content/renditions/273956.jpg)
![](/c/dam/en/us/td/i/200001-300000/200001-210000/205001-206000/205712.tif/_jcr_content/renditions/205712.jpg)
メッシュ アクセス ポイントの IP アドレスの誤った設定
ほとんどのレイヤ 3 ネットワークは DHCP IP アドレス管理を使用して導入されますが、一部のネットワーク管理者は IP アドレスを手動で管理し、各メッシュ ノードに IP アドレスを静的に割り当てることを好みます。手動でのメッシュ アクセス ポイントの IP アドレスの管理は、大規模なネットワークでは悪夢になりかねませんが、小規模から中規模のネットワーク(10 ~ 100 メッシュ ノード程度)では、メッシュ ノードの数がクライアント ホスト数と比べてかなり少ないので道理にかなっています。
メッシュ ノードに IP アドレスをスタティックに設定すると、サブネットや VLAN などの誤ったネットワークに MAP を配置してしまう可能性があります。この誤りにより、メッシュ アクセス ポイントで、IP ゲートウェイを正しく解決できなくなり、WLAN コントローラを検出できなくなる可能性があります。そのようなシナリオでは、メッシュ アクセス ポイントがその DHCP メカニズムにフォールバックし、自動的に DHCP サーバを見つけて、IP アドレスを取得しようとします。このフォールバック メカニズムにより、誤って設定されたスタティック IP アドレスから、メッシュ ノードが孤立する可能性を回避し、ネットワーク上の DHCP サーバから正しいアドレスを取得できます。
手動で IP アドレスを割り当てる場合、最初に最も遠いメッシュ アクセス ポイントの子から IP アドレッシングを変更し、RAP まで戻ってくることを推奨します。これは、装置を移動する場合にも当てはまります。たとえば、メッシュ アクセス ポイントをアンインストールし、異なるアドレスが設定されたサブネットを持つメッシュ ネットワークの別の物理的場所に再展開する場合などです。
別のオプションは、RAP と共にレイヤ 2 モードのコントローラを、誤って設定された MAP がある場所に運ぶことです。設定変更が必要な MAP に一致するブリッジ グループ名を RAP に設定します。MAP の MAC アドレスをコントローラに追加します。メッシュ アクセス ポイントの概要詳細に、誤って設定された MAP が表示されたら、それを IP アドレスで設定します。
DHCP の誤った設定
DHCP フォールバック メカニズムがあっても、次のいずれかの状況が存在する場合に、メッシュ アクセス ポイントが孤立する可能性があります。
-
ネットワークに DHCP サーバがない
-
ネットワークに DHCP サーバがあるが、AP に IP アドレスを提供しないか、AP に誤った IP アドレスを提供している場合(誤った VLAN またはサブネット上など)。
こうした状況によって、誤ったスタティック IP アドレスで設定されているか、設定されていないか、または DHCP で設定されているメッシュ アクセス ポイントが孤立する可能性があります。このため、すべての DHCP 検出の試行回数、DHCP 再試行回数、または IP ゲートウェイ解決再試行回数を試しても接続できない場合、メッシュ アクセス ポイントがレイヤ 2 モードでコントローラの検出を試みることを確認する必要があります。言い換えると、メッシュ アクセス ポイントは、最初にレイヤ 3 モードでコントローラの検出を試み、このモードでスタティック IP(設定されている場合)と DHCP(可能な場合)の両方で試みます。次に、AP はレイヤ 2 モードで、コントローラの検出を試みます。レイヤ 3 およびレイヤ 2 モードの試行を何回か試みたら、メッシュ アクセス ポイントはその親ノードを変更し、DHCP 検出を再試行します。さらに、ソフトウェア除外リストに、正しい IP アドレスを取得できなかった親ノードが記載されます。
ノード除外アルゴリズムについて
メッシュ ネットワークの設計によっては、ノードがルーティング メトリックに従って(再帰的に真の場合でも)別のノードを「最適」だと判断しても、ノードに正しいコントローラや正しいネットワークへの接続を提供できない場合があります。これは、誤った配置、プロビジョニング、ネットワークの設計のいずれかによって、または特定のリンクの AWPP ルーティング メトリックを、永続的または一時的な方法で最適化する状況を示す RF 環境の動的な性質によって発生する、典型的なハニーポット アクセス ポイントのシナリオです。ほとんどのネットワークで、そのような状況の回復は一般に難しく、ノードを完全にブラックホール化またはシンクホール化し、ネットワークから除外させる可能性があります。次の現象が見られる場合がありますが、これらに限定されるわけではありません。
-
ハニーポットにノードが接続しているが、静的 IP アドレスが設定されている場合に IP ゲートウェイが解決できない、または DHCP サーバから正しい IP アドレスが取得できない、あるいは WLAN コントローラに接続できない。
-
いくつかの、または(最悪の場合)多数のハニーポット間をノードが循環している。
シスコのメッシュ ソフトウェアは、高度なノード除外リスト アルゴリズムを使用してこの困難なシナリオを解決します。このノード除外リスト アルゴリズムは、指数バックオフ、および TCP スライディング ウィンドウや 802.11 MAC などの高度な技術を使用します。
基本なアイデアは次の 5 つの手順に基づいています。
-
ハニーポットの検出:次の手順でハニーポットが最初に検出されます。
次を試行することにより、AWPP モジュールによって親ノードが設定されます。
-
CAPWAP モジュールの固定 IP アドレス
-
DHCP モジュールの DHCP
-
CAPWAP による障害が発生したコントローラの検出および接続
-
-
ハニーポットの確定:ハニーポットが検出されると、それが確定されるまでの期間、除外リストのデータベースに配置されます。デフォルト値は 32 分です。その後、現在のメカニズムに障害が発生すると次にフォールバックされ、次の順序で他のノードが親になるよう試行されます。
-
同じチャネル
-
別のチャネル(最初は独自のブリッジ グループ名を持つチャネル、次にデフォルトのチャネル)
-
現在のすべての除外リストのエントリの確定をクリアした、別のサイクル
-
AP のリブート
-
-
非ハニーポットの信用:ノードが実際にはハニーポットではないにもかかわらず、次のような一時的なバックエンド状態によってハニーポットとして表示されることがよくあります。
-
DHCP サーバが、起動して実行していないか、一時的に障害が発生している、あるいはリブートが必要な状態
-
WLAN コントローラが、起動して実行していないか、一時的に障害が発生している、あるいはリブートが必要な状態
-
RAP 上のイーサネット ケーブルが誤って外れている状態
このような非ハニーポットは、ノードができるだけ早くサービス状態に戻れるように正しく信用される必要があります。
-
-
ハニーポットの期限:期限に達すると、除外リストのノードは除外リストのデータベースから削除され、AWPP によって今後のために通常の状態に戻る必要があります。
-
ハニーポットのレポート:コントローラへの LWAPP のメッシュ ネイバー メッセージを介してコントローラにハニーポットがレポートされます。レポートは [Bridging Information] ページに表示されます。メッセージは、最初に除外リストに記載されたネイバーが見られた際にも表示されます。後続のソフトウェア リリースでは、このような状況が発生した場合、コントローラで SNMP トラップが生成され、Cisco Prime Infrastructure で記録できるようになります。
図 7. 除外ネイバー
多くのノードは予定のイベントまたは予定外のイベント後にネットワークに加入または再加入を試みる可能性があるので、16 分のホールドオフ時間が実装されます。これは、システム初期化後、16 分間はノードが除外リストに追加されないことを意味します。
この指数バックオフおよび高度なアルゴリズムは独特であり、次のプロパティがあります。
-
親ノードが本当にハニーポットなのか、それとも一時的に機能が停止しているだけなのかをノードによって正しく判断できるようにします。
-
ノードのネットワークへの接続が維持された時間に基づいて、良好な親ノードであると信用します。信用することで、本当に一時的な状況の場合は除外リストの確定時間をきわめて短くすることができ、中程度の機能停止の場合は適度にすることができます。
-
組み込みのヒステリシス機能があります。これは、多くのノードが同じネットワーク内に存在しないかどうか互いのノードの検出を試みている場所で初期状態の問題が発生した場合に使用されます。
-
組み込みメモリがあります。これは、除外リスト データベースでかつて親ノードとして登録されていた場合(あるいは今後親ノードになる場合)、現在誤って親ノードと見なされないように、時々ネイバーになり得るノードに使用されます。
ノード除外リスト アルゴリズムは、メッシュ ネットワークの重大な孤立を防ぎます。このアルゴリズムは、ノードが迅速に再コンバージェンスして、正しいネットワークを探すことができる方法で AWPP に統合されます。
スループット分析
スループットはパケット エラー レートおよびホップ カウントによって決まります。
容量とスループットは直交概念です。スループットはノード N でのユーザ エクスペリエンスです。領域の合計容量は N 個のノードの全体のセクターで計算され、入力および出力 RAP 数に基づいています。また個別の妨害チャネルがないことを想定しています。
たとえば、10 Mbps での 4 つの RAP はそれぞれ合計容量 40 Mbps を配信します。1 ユーザが 2 つのホップを経由する場合、論理的には各 RAP で TPUT ごとに 5 Mbps を受信できることになり、40 Mbps のバックホール容量を消費します。
Cisco Mesh ソリューションを使用する場合、ホップごとの遅延は 10 ミリ秒未満で、ホップごとの遅延の範囲は標準で 1 ~ 3 ミリ秒です。ジッタ全体も 3 ミリ秒未満になります。
スループットは、ユーザ データグラム プロトコル(UDP)または Transmission Control Protocol(TCP)という、ネットワークを通過するトラフィックのタイプによって決まります。UDP はイーサネット経由で送信元アドレスおよび送信先アドレスを持つパケットおよび UDP プロトコルのヘッダーを送信します。確認応答(ACK)は行われません。パケットがアプリケーション層で配信されるかどうかは保証されません。
TCP は UDP と似ていますが、信頼性のあるパケット配信メカニズムです。パケットの ACK が行われ、スライディング ウィンドウ技術を使用することによって ACK を待つ前に送信者が複数のパケットを送信できます。クライアントが送信するデータの最大量が決められています(TCP ソケット バッファ ウィンドウと呼びます)。シーケンス番号により、送信したパケットを追跡し、パケットを正しい順序で到着させることができます。TCP は累積的に ACK を使用し、現在どのくらいのストリームが受信されたかを受信側がレポートします。ACK は TCP のウィンドウ サイズ内であればいくつでもパケットを扱うことができます。
TCP はスロー スタートおよび乗法減少を使用してネットワーク輻輳やパケット損失に対応します。パケットが損失すると TCP ウィンドウは半分になり、バックオフ再送信タイマーが急激に増加します。ワイヤレスはインターフェイスの問題によりパケット損失の影響を受けますが、TCP はこのパケット損失に応答します。パケット損失からリカバリする際に接続が切断されないように、スロー スタート リカバリ アルゴリズムも使用されます。これらのアルゴリズムは、損失の多いネットワーク環境でトラフィック ストリーム全体のスループットを減少させる効果があります。
デフォルトでは、TCP の最大セグメント サイズ(MSS)は 1460 バイトで、1500 バイトの IP データグラムになります。TCP は 1460 バイトを超えるデータ パケットを分割し、スループットが少なくとも 30 % 減少します。さらに図 1 に示されているように、コントローラによって IP データグラムが 48 バイトの CAPWAP トンネル ヘッダーにカプセル化されます。1394 バイトを超えるデータ パケットもコントローラによって分割され、スループットが最大 15 % 減少します。
![](/c/dam/en/us/td/i/200001-300000/200001-210000/205001-206000/205691.eps/_jcr_content/renditions/205691.jpg)