次の 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 

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 コンソール ポートを使用して直接入力できます。コントローラのリモート デバッグ機能を使用して入力することもできます。

次のコマンドは、メッシュ アクセス ポイントで 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 として動作させるには、メッシュ アクセス ポイントを再設定する必要があります。

バックホールは、メッシュ アクセス ポイント間に無線接続だけを作成するために使用します。

デフォルトでバックホール インターフェイスは 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 からのデバッグ メッセージでいっぱいになります。

ほとんどのレイヤ 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 サーバがあるが、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 つの手順に基づいています。

1. ハニーポットの検出：次の手順でハニーポットが最初に検出されます。

   次を試行することにより、AWPP モジュールによって親ノードが設定されます。

   • CAPWAP モジュールの固定 IP アドレス

   • DHCP モジュールの DHCP

   • CAPWAP による障害が発生したコントローラの検出および接続

2. ハニーポットの確定：ハニーポットが検出されると、それが確定されるまでの期間、除外リストのデータベースに配置されます。デフォルト値は 32 分です。その後、現在のメカニズムに障害が発生すると次にフォールバックされ、次の順序で他のノードが親になるよう試行されます。

   • 同じチャネル

   • 別のチャネル（最初は独自のブリッジ グループ名を持つチャネル、次にデフォルトのチャネル）

   • 現在のすべての除外リストのエントリの確定をクリアした、別のサイクル

   • AP のリブート

3. 非ハニーポットの信用：ノードが実際にはハニーポットではないにもかかわらず、次のような一時的なバックエンド状態によってハニーポットとして表示されることがよくあります。

   • DHCP サーバが、起動して実行していないか、一時的に障害が発生している、あるいはリブートが必要な状態

   • WLAN コントローラが、起動して実行していないか、一時的に障害が発生している、あるいはリブートが必要な状態

   • RAP 上のイーサネット ケーブルが誤って外れている状態

     このような非ハニーポットは、ノードができるだけ早くサービス状態に戻れるように正しく信用される必要があります。

4. ハニーポットの期限：期限に達すると、除外リストのノードは除外リストのデータベースから削除され、AWPP によって今後のために通常の状態に戻る必要があります。

5. ハニーポットのレポート：コントローラへの 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 % 減少します。