この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、トラブルシューティング情報について説明します。内容は次のとおりです。
次の 2 つのコマンドは、メッシュ アクセス ポイントとコントローラ間で交換されるメッセージを表示する場合に非常に便利です。
(Cisco Controller) > debug capwap events enable (Cisco Controller) > debug disable-all
debug コマンドを使用して、メッシュ アクセス ポイントとコントローラ間で行われるパケット交換のフローを表示できます。メッシュ アクセス ポイントで、ディスカバリ プロセスが起動します。join フェーズでクレデンシャルの交換が行われ、メッシュ アクセス ポイントによるメッシュ ネットワークへの join 許可が認証されます。
join が正常に完了すると、メッシュ アクセス ポイントは CAPWAP 設定要求を送信します。コントローラは設定応答で応答します。メッシュ アクセス ポイントはコントローラからの設定応答を受信すると、各設定要素を評価し、それらを実装します。
AP コンソール ポートへの直接接続またはコントローラのリモート デバッグ機能のいずれかによって、デバッグのために、メッシュ アクセス ポイント コンソールにログインできます。
コントローラでリモート デバッグを起動するには、次のコマンドを入力します。
(Cisco Controller) > debug ap enable ap-name (Cisco Controller) > debug ap command command ap-name
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 に送信されます。
![]() 注意 | メッシュ アクセス ポイントは、別の場所に移動する前に、出荷時のデフォルト設定にリセットする必要があります。 ![]() |
コマンドは、CLI の特権モードからケーブル モデムに送信できます。コマンドを使用してテキスト文字列を取得し、ケーブル モデム UART インターフェイスに送信します。ケーブル モデムはそのテキスト文字列を独自のコマンドの 1 つとして解釈します。ケーブル モデムの応答が取得され、Cisco IOS コンソールに表示されます。ケーブル モデムからは、最大 9600 文字が表示されます。4800 文字を超えるテキストはすべて切り捨てられます。
モデムのコマンドは、元々ケーブル モデム用である UART ポートに接続されているデバイスがあるメッシュ AP でのみ使用できます。ケーブル モデムがない、または他のデバイスが UART に接続されているメッシュ AP でコマンドを使用した場合、コマンドは受け入れられますが、戻される出力は生成されません。明示的にフラグが付けられるエラーはありません。
AP#send cmodem timeout-value modem-command
modem コマンドは、ケーブル モデムに送信する任意のコマンドまたはテキストです。タイムアウト値の範囲は 1 ~ 300 秒です。ただし、取得されたデータが 9600 文字の場合、9600 文字を超えるテキストは切り捨てられ、タイムアウト値とは関係なく、応答が AP コンソールにすぐに表示されます。
![]() 注意 | 疑問符(?)と感嘆符(!)は、send cmodem コマンドでは使用できません。これらの文字は、Cisco IOS CLI で即座に別の意味に解釈されます。そのため、モデムに送信できません。 |
![]() (注) | AP1572EC、AP1572IC、AP1552C および AP1552CU の場合、ケーブル モデムを有効にする必要があります。 |
snmpset –c private IP_ADDRESS cmConsoleMode.0 i NOID を使用して、次のコマンドを入力します。
snmpset –c private IP_ADDRESS 1.3.6.1.4.1.1429.77.1.4.7.0 i NIP_ADDRESS は任意の Ipv4 アドレス、N は整数、2 は読み取りと書き込みの有効化、1 は読み取り専用、0 は無効化です。
snmpset -c private 209.165.200.224 cmConsoleMode.0 i 2
SA-CM-MIB::cmConsoleMode.0 = INTEGER: readWrite(2)OID を使用して、この行を入力します。
SA-CM-MIB::cmConsoleMode.0 = INTEGER: readWrite(2)
AP はアクセス ポイント内にあるケーブル モデムへ SNMP コマンドを入力してリセットできます。この機能を動作させるには、ケーブル モデム コンソール ポートを有効にする必要があります。
Snmpset -v2c -c public IP ADDRESS 1.3.6.1.4.1.1429.77.1.3.17.0 i 1IP ADDRESS は、ケーブル モデムの IPv4 アドレスです。
次のコマンドは、メッシュ アクセス ポイントで AP コンソール ポートを使用して直接入力できます。コントローラのリモート デバッグ機能を使用して入力することもできます。
次のコマンドは、メッシュ アクセス ポイントで AP コンソール ポートを使用して直接入力しても、コントローラでリモート デバッグ機能を使用しても、入力できます。
AP1500 でデフォルトの無線のロールは MAP です。RAP として動作させるには、メッシュ アクセス ポイントを再設定する必要があります。
バックホールは、メッシュ アクセス ポイント間に無線接続だけを作成するために使用します。
デフォルトでバックホール インターフェイスは 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 のイーサネット ポートが DOWN の場合、または RAP が UP であるイーサネット ポートでコントローラに接続できない場合、802.11a がプライマリ バックホールとして設定されます。ネイバーの検索に失敗するか、802.11a 上でネイバーを経由したコントローラへの接続が失敗すると、15 分後に、RAP が SCAN 状態になり、イーサネット ポートが最初に起動します。
前述のアルゴリズムを使用して、メッシュ ノードの役割を保持すると、メッシュ アクセス ポイントが不明状態になり、ライブ ネットワークで孤立状態になるのを避けることができます。
パッシブ ビーコンを有効化すると、孤立状態のメッシュ アクセス ポイントで 802.11b/g AP を使用し、デバッグ メッセージを OTA でブロードキャストできます。孤立状態のメッシュ アクセス ポイントをリッスンし、コントローラとの接続がある隣接メッシュ アクセス ポイントは、それらのメッセージを CAPWAP 経由でコントローラに渡します。パッシブ ビーコンにより、有線接続のないメッシュ アクセス ポイントが孤立状態になるのを防ぎます。
デバッグ ログもバックホール以外の周波数帯で救難ビーコンとして送信できるため、隣接メッシュ アクセス ポイントをビーコンのリッスン専用にできます。
メッシュ アクセス ポイントでコントローラへの接続が失われると、コントローラで次の手順が自動的に起動されます。
この機能を使用するために、知っている必要があるのは孤立状態の AP の MAC アドレスだけです。
メッシュ アクセス ポイントは、孤立タイマーのリブートが実行された場合に孤立状態と見なされます。孤立タイマーのリブートが発生すると、現在孤立状態のメッシュ アクセス ポイントで、孤立防止機能のパッシブ ビーコンが有効になります。
構成されたメッシュ アクセス ポイントは定期的に孤立状態のメッシュ アクセス ポイントを検索します。メッシュ アクセス ポイントは定期的に孤立状態のメッシュ アクセス ポイントのリストと 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 エントリをクリアします。
ほとんどのレイヤ 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 フォールバック メカニズムがあっても、次のいずれかの状況が存在する場合は、メッシュ アクセス ポイントが孤立する可能性があります。
こうした状況では、スタティック IP アドレスで設定されていない(または DHCP や誤ったスタティック IP アドレスで設定されている)メッシュ アクセス ポイントが孤立する可能性があります。このため、すべての DHCP 検出の試行回数、DHCP 再試行回数、または IP ゲートウェイ解決再試行回数を試しても接続できない場合、メッシュ アクセス ポイントがレイヤ 2 モードでコントローラの検出を試みることを確認する必要があります。言い換えると、メッシュ アクセス ポイントは、最初にレイヤ 3 モードでコントローラの検出を試み、このモードでスタティック IP(設定されている場合)と DHCP(可能な場合)の両方で試みます。次に、AP はレイヤ 2 モードで、コントローラの検出を試みます。レイヤ 3 およびレイヤ 2 モードの試行を何回か試みたら、メッシュ アクセス ポイントはその親ノードを変更し、DHCP 検出を再試行します。さらに、ソフトウェア除外リストに、正しい IP アドレスを取得できなかった親ノードが記載されます。
メッシュ ネットワークの設計によっては、ノードがルーティング メトリックに従って(再帰的に真の場合でも)別のノードを「最適」だと判断しても、ノードに正しいコントローラや正しいネットワークへの接続を提供できない場合があります。これは、誤った配置、プロビジョニング、ネットワークの設計のいずれかによって、または特定のリンクの AWPP ルーティング メトリックを、永続的または一時的な方法で最適化する状況を示す RF 環境の動的な性質によって発生する、典型的なハニーポット アクセス ポイントのシナリオです。ほとんどのネットワークでは、そのような状況の回復が難しく、ノードを完全にブラックホール化またはシンクホール化し、ネットワークから切断させる可能性すらあります。次の現象などが見られる場合があります。
静的 IP アドレスが設定されておりハニーポットにノードが接続しているが、IP ゲートウェイが解決できない/DHCP サーバから正しい IP アドレスが取得できない、あるいは WLAN コントローラに接続できない。
シスコのメッシュ ソフトウェアは、高度なノード除外リスト アルゴリズムを使用してこの困難なシナリオを解決します。このノード除外リスト アルゴリズムは、指数バックオフ、および TCP スライディング ウィンドウや 802.11 MAC などの高度な技術を使用します。
ハニーポットの確定:ハニーポットが検出されると、それが確定されるまでの期間、除外リストのデータベースに配置されます。デフォルト値は 32 分です。その後、現在のメカニズムに障害が発生すると次にフォールバックされ、次の順序で他のノードが親になるよう試行されます。
非ハニーポットの信用:ノードが実際にはハニーポットではないにもかかわらず、次のような一時的なバックエンド状態によってハニーポットとして表示されることがよくあります。
ハニーポットの期限:期限に達すると、除外リストのノードは除外リストのデータベースから削除され、AWPP によって今後のために通常の状態に戻る必要があります。
ハニーポットのレポート:コントローラへの LWAPP のメッシュ ネイバー メッセージを介してコントローラにハニーポットがレポートされます。レポートは [Bridging Information] ページに表示されます。メッセージは、最初に除外リストに記載されたネイバーが見られた際にも表示されます。後続のソフトウェア リリースでは、このような状況が発生した場合、コントローラで SNMP トラップが生成され、Cisco Prime Infrastructure で記録できるようになります。
多くのノードは予定の(または予定外の)イベント後にネットワークに加入/再加入を試みる可能性があるので、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 % 減少します。