高可用性

ハイ アベイラビリティの機能履歴

次の表に、このモジュールで説明する機能のリリースおよび関連情報を示します。

これらの機能は、特に明記されていない限り、導入されたリリース以降のすべてのリリースで使用できます。

表 1. ハイ アベイラビリティの機能履歴

リリース

機能

機能情報

Cisco IOS XE Amsterdam 17.1.1s

リダンダンシー マネジメント インターフェイス

リダンダンシー マネジメント インターフェイス（RMI）は、アクティブコントローラとスタンバイコントローラ間のセカンダリリンクとして使用されます。このインターフェイスはワイヤレス管理インターフェイスと同じであり、このインターフェイス上の IP アドレスはワイヤレス管理インターフェイスと同じサブネットで設定されます。

Cisco IOS XE Bengaluru 17.4.1

ゲートウェイ到達可能性検出

ゲートウェイ到達可能性機能は、アクティブコントローラでゲートウェイの到達可能性が失われた場合に、AP とクライアントのダウンタイムを最小限に抑えます。

Cisco IOS XE Bengaluru 17.5.1

スタンバイモニタリングの機能拡張

スタンバイモニタリングの拡張機能は、アクティブコントローラからのスタンバイ CPU またはメモリ情報を監視します。また、この機能は、インターフェイス MIB の SNMP を使用して、スタンバイコントローラを個別に監視します。

CISCO-HA-MIB の cLHaPeerHotStandbyEvent および cLHaPeerHotStandbyEvent MIB オブジェクトは、スタンバイ HA ステータスを監視するために使用されます。

Cisco IOS XE Bengaluru 17.5.1

自動アップグレード

自動アップグレード機能により、スタンバイコントローラがアクティブコントローラのソフトウェアイメージにアップグレードできるため、両方のコントローラがハイアベイラビリティ（HA）を形成できます。

Cisco IOS XE Bengaluru 17.6.1

アクティブな SNMP を使用したスタンバイ インターフェイス ステータス

この機能により、SNMP を使用してスタンバイ コントローラ インターフェイスのステータスをアクティブで照会できます。

Cisco IOS XE Cupertino 17.9.1

アプリケーション セントリック インフラストラクチャ（ACI）ネットワークのハイアベイラビリティ展開

この機能は、次の機能を使用して、古いアクティブコントローラと新しいアクティブコントローラ間のトラフィックのインターリーブを回避します。

  • ワイヤレス管理インターフェイス（WMI）をより迅速に停止します。

  • 高速スイッチオーバー通知を無効にします。

スタンバイコントローラでの Link Layer Discovery Protocol（LLDP）のサポート

このリリースから、Link Layer Discovery Protocol（LLDP）プロセスがアクティブコントローラとスタンバイコントローラの両方で起動および実行されるようになります。

ハイ アベイラビリティについて

ハイアベイラビリティ（HA）によって、コントローラのフェールオーバーで生じる無線ネットワークのダウンタイムを短縮することができます。コントローラの HA ステートフル スイッチオーバー（SSO）機能により、AP はアクティブコントローラとの CAPWAP トンネルを確立できます。アクティブコントローラは、AP およびクライアントデータベースのミラーコピーをスタンバイコントローラと共有します。アクティブコントローラに障害が発生しても、AP は検出状態にならず、クライアントは切断されません。スタンバイコントローラがアクティブコントローラとしてネットワークを引き継ぎます。AP とアクティブ状態のコントローラ間では、1 つの CAPWAP トンネルのみが維持されます。

HA は、完全な AP およびクライアント SSO をサポートします。クライアント SSO がサポートされるのは、認証および DHCP フェーズが完了し、トラフィックの送信を始めたクライアントのみです。クライアント SSO を使用することで、コントローラにクライアントが関連付けられたときか、クライアントのパラメータが変更されたときに、クライアント情報がスタンバイコントローラと同期されます。完全に認証されたクライアント（Run 状態のクライアントなど）は、スタンバイ側に同期されます。これによって、スイッチオーバー時にクライアントの再関連付けが回避され、AP およびクライアントのフェールオーバーがシームレスになります。その結果、クライアントサービスのダウンタイムがゼロになり、SSID の停止もなくなります。この機能により、プライマリサイトでのボックスフェールオーバー、ネットワークのフェールオーバー、停電などによるワイヤレスネットワークの大規模なダウンタイムが削減されます。


（注）  

  • HA モードでは、コントローラのブートアップ中に RP ポートの shut または no shut を実行しないでください。

  • HA の同期中にアクティブコントローラとスタンバイコントローラ間で RP 通信が失われると、IPC 通信が失敗してスタンバイコントローラがクラッシュします。このクラッシュは意図的なものです。

    RP リンクが復元されると、スタンバイコントローラは正常にリロードし、HA ペアを形成します。

（注）  

コントローラがスパニングツリープロトコルのホストとして動作する場合は、コンバージェンスを高速化するために、アップリンクスイッチで spanning-tree port type edge trunk または spanning-tree portfast trunk コマンドを使用して PortFast トランクを設定してください。


（注）  

HA の設定で FIPS を設定できます。詳細については、「HA 設定の FIPS の設定」を参照してください。


（注）  

IPv4 セカンダリアドレスは、RMI の目的で内部的に使用されます。そのため、セカンダリ IPv4 アドレスを設定することは推奨されません。

IPv6 の場合、1 つの管理 IPv6 のみが許可され、セカンダリアドレスは RMI-IPv6 用に設定されます。ワイヤレス管理インターフェイス（WMI）で複数の IPv6 管理を行うことは推奨されません。

WMI に複数の管理 IPv4 および IPv6 アドレスがあると、予期しない動作が発生する可能性があります。

ハイ アベイラビリティの前提条件

外部インターフェイスと IP

すべてのインターフェイスはアクティブボックスでのみ設定されますが、スタンバイボックスと同期されるため、両方のコントローラで同じインターフェイスセットが設定されます。外部ノードでは、接続先のコントローラに関係なく、インターフェイスは同じ IP アドレスに接続します。

このため、モビリティグループ内の AP、クライアント、DHCP、Cisco Prime Infrastructure、Cisco Catalyst Center、Cisco Identity Services Engine（ISE）サーバー、およびその他のコントローラのメンバーは、常に同じ IP アドレスに接続します。SSO スイッチオーバーは、これらに対して透過的です。ただし、外部ノードからコントローラへの TCP 接続がある場合は、TCP 接続をリセットして再確立する必要があります。

HA インターフェイス

HA インターフェイスは次の目的で使用されます。

  • IOSd が起動する前のコントローラペア間の接続を可能にする。

  • コントローラペア全体での IPC トランスポートを可能にする。

  • コントローラペア間で交換される制御メッセージ全体の冗長性を有効にする。制御メッセージには、HA ロールの解決、キープアライブ、通知、HA 統計情報などがあります。

HA ポートには、SFP 接続または RJ-45 接続のいずれかを選択できます。サポートされている Cisco SFP は次のとおりです。

  • GLC-SX-MMD

  • GLC-LH-SMD

SFP 接続または RJ-45 接続のいずれかが存在する場合、HA は 2 台のコントローラ間で機能します。SFP HA 接続は、RJ-45 HA 接続よりも優先されます。RJ-45 HA の稼働中に SFP が接続されると、HA ペアがリロードされます。リロードは、SFP 間のリンクが接続されていない場合も発生します。


（注）  

  • HA ペアが 2 台のホストマシンに展開されている場合は、RP 専用の物理 NIC とスイッチを使用することをお勧めします。これにより、キープアライブの損失や、誤った HA のスイッチオーバーやアラームを回避できます。

  • VMware 仮想インスタンスのセキュリティスキャンを無効にします。

ハイ アベイラビリティの制約事項

  • フェールセーフ SSO の場合は、スタンバイコントローラでの設定の同期が完了した後、スイッチオーバーイベントが受信されるまで待ちます。スタンバイコントローラが起動した直後の場合は、コントローラがスイッチオーバーイベントを問題なく処理できるようになるまで、x 分間待つことを推奨します。x の値は、プラットフォームに応じて異なります。たとえば、Cisco 9800-80 シリーズ コントローラが最大キャパシティで実行されている場合は、SSO の準備が整う前に、設定の同期が完了するまでに最大 24 分かかる場合があります。show wireless stats redundancy config database コマンドを使用して、データベース関連の統計を表示することができます。

  • ローカルモードの HA のシナリオでは、NBAR エンジンのフロー状態はスイッチオーバー中に失われます。このため、フローの分類が再開し、パケット分類の誤りが生じます。これは、フローの最初のパケットが失われているためです。

  • HA 接続では、IPv4 のみがサポートされます。

  • スイッチオーバーとアクティブリロードが行われると、新しいプライマリからハイアベイラビリティリンクが強制的にダウンします。

  • ハイパースレッディングはサポートされていません。有効にすると、HA システムの場合に HA キープアライブが失われ、スタックのマージが発生します。

  • スタンバイ RMI インターフェイスは Web UI アクセスをサポートしていません。

  • 2 つの HA インターフェイス（RMI と RP）を同じサブネット上に設定する必要があります。このサブネットをデバイス上の他のインターフェイスと共有することはできません。

  • TCP セッションはスイッチオーバー後に保持されず、再確立する必要があるため、TCP セッションの状態を同期することはできません。

  • RUN 状態に達していないクライアントはスイッチオーバー後に削除されるため、クライアント SSO の対象にはなりません。

  • 統計情報テーブルはアクティブからスタンバイコントローラに同期されません。

  • コントローラの HA インターフェイスをホストしている VM のマシンスナップショットはサポートされていません。これは、HA コントローラのクラッシュの原因となる可能性があります。

  • モビリティ側の制限：スイッチオーバー後に、RUN 状態ではないクライアントは強制的に再認証されます。

  • 次のアプリケーション分類は、SSO 後に保持されない場合があります。

    • AVC の制限：スイッチオーバー後、スタンバイ ボックスへのコンテキスト転送または同期は行われず、新しいアクティブ フローを再学習する必要があります。AVC QoS は、分類が失敗した場合は有効になりません。

    • 音声ポリシーは RTP または RTCP プロトコルに基づいているため、スイッチオーバー後に音声コールを認識することはできません。

    • AVC の制限により、自動 QoS は有効ではありません。

  • アクティブコントローラとスタンバイコントローラは、仮想プラットフォームの同じインターフェイスとペアリングする必要があります。ハードウェアアプライアンスには、専用の HA ポートがあります。

  • スタティック IP アドレッシングはスタンバイに同期できますが、スタンバイ コントローラの IP アドレスを使用することはできません。

  • 専用 HA ポートを 1 GB インターフェイスにのみマッピングできます。

  • Cisco IOS XE Gibraltar 16.12.x までのリリースで、HA モードで EtherChannel を使用するには、チャネルモードがオンに設定されていることを確認します。

  • Cisco IOS XE Gibraltar 16.12.x までのリリースでは、HA モードで EtherChannel の自動モードはサポートされていません。

  • Cisco IOS XE Gibraltar 16.12.x までのリリースでは、HA モードで LACP と PAGP はサポートされていません。

  • コントローラがスパニングツリープロトコルのホストとして動作する場合は、コンバージェンスを高速化するために、アップリンクスイッチで spanning-tree port type edge trunk または spanning-tree portfast trunk コマンドを使用して PortFast トランクを設定してください。

  • clear chassis redundancy および write erase コマンドを使用しても、シャーシ優先順位はデフォルト値にリセットされません。

  • HA でデバイスを設定する場合、メンバーは、名前が同じでキーが異なるワイヤレストラストポイントを持つことはできません。このようなシナリオでは、2 つのスタンドアロンコントローラ間で HA ペアを形成すると、後続の SSO の後にワイヤレストラストポイントが起動しません。この理由は、rsa keypair ファイルは存在しますが、nvram:private-config ファイルが実際の WLC_WLC_TP キーペアと同期されていないためです。

    ベストプラクティスとして、HA を形成する前に、以前にスタンドアロンとして展開されていた各コントローラ内の既存の証明書とキーを削除することを推奨します。

  • スイッチオーバー後、リカバリが進行中の場合は、WLAN または WLAN ポリシーを設定しないでください。設定すると、コントローラがクラッシュする可能性があります。

  • スイッチオーバー後、RUN 状態ではなく AP に接続されていないクライアントは、300 秒後に削除されます。

ハイ アベイラビリティ（CLI）の設定

始める前に

アクティブコントローラとスタンバイコントローラは、インストールモードまたはバンドルモードのどちらか同じモードで、同じイメージバージョンである必要があります。インストールモードを使用することを推奨します。

手順

  コマンドまたはアクション 目的

ステップ 1

chassis chassis-num priority chassis-priority

例:

Device# chassis 1 priority 1

（任意）指定されたデバイスの優先順位を設定します。

（注）  

 

Cisco IOS XE Gibraltar 16.12.x 以降では、シャーシの優先順位を有効にするためにデバイスをリロードする必要はありません。

  • chassis-num ：シャーシ番号を入力します。有効な範囲は 1 ～ 2 です。

  • chassis-priority ：シャーシのプライオリティを入力します。有効な範囲は 1 ～ 2 です。デフォルト値は 1 です。

（注）  

 

両方のデバイスが同時に起動すると、高い優先順位（2）のデバイスがアクティブになり、もう一方はスタンバイになります。両方のデバイスに同じ優先順位値が設定されている場合、MAC アドレスが小さいデバイスがアクティブとして機能し、そのピアがスタンバイとして機能します。

ステップ 2

chassis redundancy ha-interface GigabitEthernet numlocal-ip local-chassis-ip-addr network-mask remote-ip remote-chassis-ip-addr

例:

Device# chassis redundancy ha-interface 
GigabitEthernet 2 local-ip 4.4.4.1 /24 remote-ip 4.4.4.2

シャーシのハイアベイラビリティ パラメータを設定します。

  • num ：GigabitEthernet インターフェイス番号。有効な範囲は 0 ～ 32 です。

  • local-chassis-ip-addr ：ローカル シャーシ HA インターフェイスの IP アドレスを入力します。

  • network-mask ：ネットワーク マスクかプレフィックス長を /nn または A.B.C.D の形式で入力します。

  • remote-chassis-ip-addr ：リモート シャーシの IP アドレスを入力します。

ステップ 3

chassis redundancy keep-alive timer timer

例:

Device# chassis redundancy keep-alive timer 6

ピア キープアライブ タイムアウト値を設定します。

インターバルは 100 ミリ秒の倍数で設定されます（デフォルトの場合は 1 を入力）。

ステップ 4

chassis redundancy keep-alive retries retry-value

例:

Device# chassis redundancy keep-alive retries 8

ピアがダウンしていると判断されるまでの、ピアのキープアライブの再試行値を設定します。デフォルト値は 5 です。

ハイアベイラビリティの無効化

SSO 設定の RP 方式を使用してコントローラが設定されている場合は、次のコマンドを使用して、すべての HA 関連のパラメータ（ローカル IP、リモート IP、HA インターフェイス、マスク、タイムアウト、プライオリティなど）をクリアします。

clear chassis redundancy

コントローラが RMI 方式を使用して設定されている場合は、次のコマンドを使用します。

no redun-management interface vlan chassis


（注）  

変更を有効にするには、デバイスをリロードします。

HA のペアリング解除後に、スタンバイコントローラのスタートアップ構成と HA 構成がクリアされ、スタンバイが 0 日目に移行します。

コマンドを実行する前に、アクティブコントローラで次の警告が表示されます。


Device# clear chassis redundancy

WARNING: Clearing the chassis HA configuration will result in both the chassis move into
Stand Alone mode. This involves reloading the standby chassis after clearing its HA
configuration and startup configuration which results in standby chassis coming up as a totally
clean after reboot. Do you wish to continue? [y/n]? [yes]:

*Apr 3 23:42:22.985: received clear chassis.. ha_supported:1yes
WLC#
*Apr 3 23:42:25.042: clearing peer startup config
*Apr 3 23:42:25.042: chkpt send: sent msg type 2 to peer..
*Apr 3 23:42:25.043: chkpt send: sent msg type 1 to peer..
*Apr 3 23:42:25.043: Clearing HA configurations
*Apr 3 23:42:26.183: Successfully sent Set chassis mode msg for chassis 1.chasfs file updated
*Apr 3 23:42:26.359: %IOSXE_REDUNDANCY-6-PEER_LOST: Active detected chassis 2 is no
longer standby

スタンバイコントローラでは、構成がクリアされることを示す次のメッセージが表示されます。

Device-stby#

*Apr 3 23:40:40.537: mcprp_handle_spa_oir_tsm_event: subslot 0/0 event=2
*Apr 3 23:40:40.537: spa_oir_tsm subslot 0/0 TSM: during state ready, got event 3(ready)
*Apr 3 23:40:40.537: @@@ spa_oir_tsm subslot 0/0 TSM: ready -> ready
*Apr 3 23:42:25.041: Removing the startup config file on standby

!Standby controller is reloaded after clearing the chassis.

スタンバイコントローラへの WebAuth Tar 形式バンドルのコピー

高可用性構成でスタンバイコントローラに WebAuth tar 形式バンドルをコピーするには、次の手順を活用します。

手順

ステップ 1

[Administration] > [Management] > [Backup & Restore] を選択します。

ステップ 2

[Copy] ドロップダウンリストから、[To Device] を選択します。

ステップ 3

[File Type] ドロップダウンリストから、[WebAuth Bundle] を選択します。

ステップ 4

[Transfer Mode] ドロップダウンリストから、[TFTP]、[SFTP]、[FTP]、または [HTTP] を選択します。

[Server Details] オプションは、選択したファイル転送オプションに基づいて変わります。

  • TFTP

    • [IP Address (IPv4/IPv6)]：使用する TFTP サーバーのサーバー IP アドレス（IPv4 または IPv6）を入力します。

    • [File Path]：ファイルのパスを入力します。ファイルパスはスラッシュ（/path）で始める必要があります。

    • [File Name]：ファイル名を入力します。

      ファイル名にスペースを含めることはできません。サポートされている特殊文字は、下線（_）とハイフン（-）のみです。ファイル名の末尾が .tar であることを確認します（例：webauthbundle.tar）。

  • SFTP

    • [IP Address (IPv4/IPv6)]：使用する SFTP サーバーのサーバー IP アドレス（IPv4 または IPv6）を入力します。

    • [File Path]：ファイルのパスを入力します。ファイルパスはスラッシュ（/path）で始める必要があります。

    • [File Name]：ファイル名を入力します。

      ファイル名にスペースを含めることはできません。サポートされている特殊文字は、下線（_）とハイフン（-）のみです。ファイル名の末尾が .tar であることを確認します（例：webauthbundle.tar）。

    • [Server Login UserName]：SFTP サーバーのログインユーザー名を入力します。

    • [Server Login Password]：SFTP サーバーのログインパスフレーズを入力します。

  • FTP

    • [IP Address (IPv4/IPv6)]：使用する TFTP サーバーのサーバー IP アドレス（IPv4 または IPv6）を入力します。

    • [File Path]：ファイルのパスを入力します。ファイルパスはスラッシュ（/path）で始める必要があります。

    • [File Name]：ファイル名を入力します。

      ファイル名にスペースを含めることはできません。サポートされている特殊文字は、下線（_）とハイフン（-）のみです。ファイル名の末尾が .tar であることを確認します（例：webauthbundle.tar）。

    • [Logon Type]：ログインタイプとして [Anonymous] または [Authenticated] を選択します。[Authenticated] を選択すると、次のフィールドがアクティブになります。

      • [Server Login UserName]：FTP サーバーのログインユーザー名を入力します。

      • [Server Login Password]：FTP サーバーのログインパスフレーズを入力します。

  • [HTTP]

    • [Source File Path]：[Select File] をクリックして構成ファイルを選択し、[Open] をクリックします。

ステップ 5

[Yes] または [No] オプションボタンをクリックして、既存のスタートアップ コンフィギュレーションをフラッシュにバックアップします。

設定をフラッシュに保存して、スタンバイコントローラを含む他のメンバーに WebAuth バンドルを伝播します。設定をフラッシュに保存しない場合、WebAuth バンドルはスタンバイコントローラを含む他のメンバーに伝播されません。

ステップ 6

[Download File] をクリックします。

システムおよびネットワークの障害処理

スタンバイコントローラがクラッシュすると、リブートしてスタンバイコントローラとして起動します。続いて一括同期が実行され、スタンバイがホットになります。アクティブコントローラがクラッシュすると、スタンバイがアクティブになります。新しいアクティブコントローラはプライマリのロールを引き受け、デュアルアクティブを検出しようとします。

次のマトリックスで、コントローラのスイッチオーバーがトリガーされる条件を明確に示しています。

表 2. システムおよびネットワークの障害処理

システムに関する問題

トリガー

RP リンクステータス

RMI を介したピアの到達可能性

スイッチオーバー

結果

クリティカルプロセスのクラッシュ

アップ

到達可能

対応

スイッチオーバー発生

強制スイッチオーバー

アップ

到達可能

対応

スイッチオーバー発生

クリティカルプロセスのクラッシュ

アップ

到達不能

対応

スイッチオーバー発生

強制スイッチオーバー

アップ

到達不能

対応

スイッチオーバー発生

クリティカルプロセスのクラッシュ

ダウン

到達可能

非対応

必要な作業はありません。　リカバリモードの 1 つのコントローラ。

強制スイッチオーバー

ダウン

到達可能

該当なし

必要な作業はありません。　リカバリモードの 1 つのコントローラ。

クリティカルプロセスのクラッシュ

ダウン

到達不能

非対応

二重障害：「ネットワークエラーの処理」を参照

強制スイッチオーバー

ダウン

到達不能

該当なし

二重障害：「ネットワークエラーの処理」を参照

RP リンク

RMI を介したピアの到達可能性

アクティブからのゲートウェイ

スタンバイからのゲートウェイ

スイッチオーバー

結果

アップ

到達可能

到達可能

到達可能

非 SSO

動作なし

アップ

到達可能

到達可能

到達不能

非 SSO

必要な作業はありません。　ゲートウェイに到達できないため、スタンバイはこの状態では SSO に対応できません。スタンバイは、スタンバイ-リカバリモードになります。RP がダウンすると、スタンバイ（リカバリモード）がアクティブになります。

アップ

到達可能

到達不能

到達可能

SSO

ゲートウェイ到達可能性メッセージは、RMI + RP リンク経由で交換されます。スタンバイがアクティブになるように、アクティブリブートが実行されます。

アップ

到達可能

到達不能

到達不能

非 SSO

これにより、アクティブ SVI がダウンすると、スタンバイ SVI もダウンします。スイッチオーバーがトリガーされます。新しいアクティブによってゲートウェイが到達可能であると検出された場合は、アクティブ-スタンバイのリカバリモードでシステムが安定します。それ以外の場合、スイッチオーバーはピンポン方式で行われます。

アップ

到達不能

到達可能

到達可能

非 SSO

動作なし

アップ

到達不能

到達可能

到達不能

非 SSO

ゲートウェイに到達できないため、スタンバイはこの状態では SSO に対応できません。LMP メッセージは RP リンク経由で交換されるため、スタンバイはリカバリモードになります。

アップ

到達不能

到達不能

到達可能

SSO

ゲートウェイ到達可能性メッセージは RP リンク経由で交換されます。スタンバイがアクティブになるように、アクティブのリブートが実行されます。

アップ

到達不能

到達不能

到達不能

非 SSO

これにより、アクティブ SVI がダウンすると、スタンバイ SVI もダウンします。スイッチオーバーがトリガーされます。新しいアクティブによってゲートウェイが到達可能であると検出された場合は、アクティブ-スタンバイのリカバリモードでシステムが安定します。それ以外の場合、スイッチオーバーはピンポン方式で行われます。

ダウン

到達可能

到達可能

到達可能

非 SSO

スタンバイは、RMI リンクを介してアクティブの存在を検出し、RP リンクがダウンしたときにスイッチオーバーを回避します。この場合、スタンバイはリカバリモードになります。このモードは、ホスト名のサフィックス rp-rec-mode で表されます。RP リンクがアップすると、リカバリモードのスタンバイがリロードされます。単一障害は、システムで適切に処理されます。

ダウン

到達可能

到達可能

到達不能

非 SSO

同上。

ダウン

到達可能

到達不能

到達可能

RP リンクがダウンし、アクティブが GW を失うと、SSO は行われません。GW がダウンすると、8 秒以内に RP リンクがダウンし、SSO が行われます。

ゲートウェイ到達可能性メッセージは RP+RMI リンク経由で交換されます。以前のアクティブはアクティブ-リカバリモードになります。コンフィギュレーション モードは、アクティブ-リカバリモードでは無効です。すべてのインターフェイスが「管理上ダウン」し、ワイヤレス管理インターフェイスに RMI IP が設定されます。アクティブ-リカバリのコントローラは、RP リンクがアップ状態になると、リロードしてスタンバイ（または、ゲートウェイの到達可能性がまだ使用できない場合はスタンバイ-リカバリ）になります。

ダウン

到達可能

到達不能

到達不能

非 SSO

スタンバイはスタンバイ-リカバリになります。

ダウン

到達不能

到達可能

到達可能

SSO

二重障害：アクティブコントローラが 2 台になるため、ネットワークの競合が生じます。スタンバイがアクティブになります。従来のアクティブも存在します。ロールネゴシエーションは、接続が復元された後に実行され、最後にアップ状態になった方のアクティブが維持されます。

ダウン

到達不能

到達可能

到達不能

SSO

同上。

ダウン

到達不能

到達不能

到達可能

SSO

同上。

ダウン

到達不能

到達不能

到達不能

SSO

同上。

リカバリメカニズムの処理

アクティブからアクティブへのリカバリ

  • 起動時に RP がダウンし、RMI が起動している場合、アクティブリカバリが発生します。

  • HA が安定しているとき（アクティブ-スタンバイ）、RMI が最初にダウンし、次に RP がダウンした後、RP が起動する前に RMI が起動する場合、アクティブからアクティブへのリカバリが発生します。RP が起動すると、アクティブリカバリがリロードされ、HA が形成されます。

スタンバイからスタンバイへのリカバリ

  • スタンバイがゲートウェイのみのスタンバイリカバリに移行した場合、ゲートウェイが起動すると、HA はリブートせずに起動します。

  • スタンバイが RP ダウンのスタンバイリカバリに移行した場合、RP が起動すると、スタンバイリカバリが自動的にリブートし、HA が形成されます。

ハイ アベイラビリティ設定の確認

HA 設定の詳細を表示するには、次のコマンドを使用します。

Device# show romvar
ROMMON variables:
 LICENSE_BOOT_LEVEL =
 MCP_STARTUP_TRACEFLAGS = 00000000:00000000
 BOOTLDR =
 CRASHINFO = bootflash:crashinfo_RP_00_00_20180202-034353-UTC
 STACK_1_1 = 0_0
 CONFIG_FILE =
 BOOT = bootflash:boot_image_test,1;bootflash:boot_image_good,1;bootflash:rp_super_universalk9.vwlc.bin,1;
 RET_2_RTS =
 SWITCH_NUMBER = 1
 CHASSIS_HA_REMOTE_IP = 10.0.1.9
 CHASSIS_HA_LOCAL_IP = 10.0.1.10
 CHASSIS_HA_LOCAL_MASK = 255.255.255.0
 CHASSIS_HA_IFNAME = GigabitEthernet2
 CHASSIS_HA_IFMAC = 00:0C:29:C9:12:0B
 RET_2_RCALTS =
 BSI = 0
 RANDOM_NUM = 647419395

AP またはクライアントの SSO 統計情報の確認

AP SSO の統計情報を表示するには、次のコマンドを使用します。

Device# show wireless stat redundancy statistics ap-recovery wnc all
AP SSO Statistics                                                     

Inst    Timestamp     Dura(ms)   #APs  #Succ  #Fail  Avg(ms)  Min(ms)  Max(ms)
------------------------------------------------------------------------------
   0    00:06:29.042        98     34     34      0        2        1       35
   1    00:06:29.057        56     33     30      3        1        1       15
   2    00:06:29.070        82     33     33      0        2        1       13


Statistics:

WNCD Instance   : 0
No. of AP radio recovery failures          : 0
No. of AP BSSID recovery failures          : 0
No. of CAPWAP recovery failures            : 0
No. of DTLS recovery failures              : 0
No. of reconcile message send failed       : 0
No. of reconcile message successfully sent : 34
No. of Mesh BSSID recovery failures: 0
No. of Partial delete cleanup done : 0
.
.
.

クライアント SSO の統計情報を表示するには、次のコマンドを使用します。

Device# show wireless stat redundancy client-recovery wncd all
Client SSO statistics                                                      
----------------------                                                     

WNCD instance  : 1
Reconcile messages received from AP                     : 1
Reconcile clients received from AP                      : 1
Recreate attempted post switchover                      : 1
Recreate attempted by SANET Lib                         : 0
Recreate attempted by DOT1x Lib                         : 0
Recreate attempted by SISF Lib                          : 0
Recreate attempted by SVC CO Lib                        : 1
Recreate attempted by Unknown Lib                       : 0
Recreate succeeded post switchover                      : 1
Recreate Failed post switchover                         : 0
Stale client entries purged post switchover             : 0

Partial delete during heap recreate                     : 0
Partial delete during force purge                       : 0
Partial delete post restart                             : 0
Partial delete due to AP recovery failure               : 0
Partial delete during reconcilation                     : 0

Client entries in shadow list during SSO                : 0
Client entries in shadow default state during SSO       : 0
Client entries in poison list during SSO                : 0

Invalid bssid during heap recreate                      : 0
Invalid bssid during force purge                        : 0
BSSID mismatch with shadow rec during reconcilation     : 0
BSSID mismatch with shadow rec reconcilation(WGB client): 0
BSSID mismatch with dot11 rec during heap recreate      : 0

AID mismatch with dot11 rec during force purge          : 0
AP slotid mismatch during reconcilation                 : 0
Zero aid during heap recreate                           : 0
AID mismatch with shadow rec during reconcilation       : 0
AP slotid mismatch shadow rec during reconcilation      : 0
Client shadow record not present                        : 0

モビリティの詳細を表示するには、次のコマンドを使用します。

Device# show wireless stat redundancy client-recovery mobilityd
Mobility Client Deletion Reason Statistics
-------------------------------------------
Mobility Incomplete State         : 0
Inconsistency in WNCD & Mobility  : 0
Partial Delete                    : 0

General statistics
--------------------
Cleanup sent to WNCD, Missing Delete case   : 0

クライアント SSO の SISF に関する統計情報を表示するには、次のコマンドを使用します。

Device# show wireless stat redundancy client-recovery sisf
Client SSO statistics for SISF
--------------------------------
Number of recreate attempted post switchover    : 1
Number of recreate succeeded post switchover    : 1
Number of recreate failed because of no mac     : 0
Number of recreate failed because of no ip      : 0
Number of ipv4 entry recreate success           : 1
Number of ipv4 entry recreate failed            : 0
Number of ipv6 entry recreate success           : 0
Number of ipv6 entry recreate failed            : 0
Number of partial delete received               : 0
Number of client purge attempted                : 0
Number of heap and db entry purge success       : 0
Number of purge success for db entry only       : 0
Number of client purge failed                   : 0
Number of garp sent                             : 1
Number of garp failed                           : 0
Number of IP entries validated in cleanup       : 0
Number of IP entry address errors in cleanup    : 0
Number of IP entry deleted in cleanup           : 0
Number of IP entry delete failed in cleanup     : 0
Number of IP table create callbacks on standby  : 0
Number of IP table modify callbacks on standby  : 0
Number of IP table delete callbacks on standby  : 0
Number of MAC table create callbacks on standby : 1
Number of MAC table modify callbacks on standby : 0
Number of MAC table delete callbacks on standby : 0

HA 冗長性の概要を表示するには、次のコマンドを使用します。

Device# show wireless stat redundancy summary
HA redundancy summary
---------------------

AP recovery duration (ms)        : 264
SSO HA sync timer expired        : No

ハイ アベイラビリティの確認

表 3. シャーシと冗長性のモニタリング用コマンド
コマンド名 説明
show chassis

シャーシ情報を表示します。

（注）  

 

ピアのタイムアウトと再試行回数が設定されている場合、show chassis ha-status マンドの出力に誤った値が表示されることがあります。

ピアのキープアライブタイマーと再試行回数を確認するには、次のコマンドを使用します。

  • show platform software stack-mgr chassis active r0 peer-timeout

  • show platform software stack-mgr chassis standby r0 peer-timeout

show redundancy

アクティブ ボックスとスタンバイ ボックスに関する詳細を表示します。

show redundancy switchover history

スイッチオーバーのカウント、スイッチオーバーの理由、およびスイッチオーバーの時間を表示します。

冗長性 HA ポート（RP）でパケットキャプチャを開始するには、次のコマンドを使用します。

  • test wireless redundancy packet dump start

  • test wireless redundancy packet dump stop

  • test wireless redundancy packet dump start filter port 2300

Device# test wireless redundancy packetdump start
Redundancy Port PacketDump Start
Packet capture started on RP port.

Device# test wireless redundancy packetdump stop
Redundancy Port PacketDump Start
Packet capture started on RP port.
Redundancy Port PacketDump Stop
Packet capture stopped on RP port.
Device# dir bootflash:                           
Directory of bootflash:/
1062881  drwx           151552  Oct 20 2020 23:15:25 +00:00  tracelogs
47      -rw-            20480  Oct 20 2020 23:15:24 +00:00  haIntCaptureLo.pcap
1177345  drwx             4096  Oct 20 2020 19:56:14 +00:00  certs
294337  drwx             8192  Oct 20 2020 19:56:05 +00:00  license_evlog
15      -rw-              676  Oct 20 2020 19:56:01 +00:00  vlan.dat
14      -rw-               30  Oct 20 2020 19:55:16 +00:00  throughput_monitor_params
13      -rw-           134808  Oct 20 2020 19:54:57 +00:00  memleak.tcl
1586145  drwx             4096  Oct 20 2020 19:54:45 +00:00  .inv
1103761  drwx             4096  Oct 20 2020 19:54:39 +00:00  dc_profile_dir
17      -r--              114  Oct 20 2020 19:54:17 +00:00  debug.conf
1389921  drwx             4096  Oct 20 2020 19:54:17 +00:00  .installer
46      -rw-       1104760207  Oct 20 2020 19:26:41 +00:00  leela_katar_rping_test.SSA.bin
49057   drwx             4096  Oct 20 2020 16:11:21 +00:00  .prst_sync
45      -rw-       1104803200  Oct 20 2020 15:39:19 +00:00  C9800-L-universalk9_wlc.2020-10-20_14.57_yavadhan.SSA.bin
269809  drwx             4096  Oct 19 2020 23:41:49 +00:00  core
44      -rw-       1104751981  Oct 19 2020 17:42:12 +00:00  C9800-L-universalk9_wlc.BLD_POLARIS_DEV_LATEST_20201018_053825_2.SSA.bin
43      -rw-       1104286975  Oct 16 2020 12:05:47 +00:00  C9800-L-universalk9_wlc.BLD_POLARIS_DEV_LATEST_20201010_001654_2.SSA.bin

Device# test wireless redundancy packetdump start filter port 2300
Redundancy Port PacketDump Start
Packet capture started on RP port with port filter 2300.

2 つの HA ポート（RP）間の接続を確認し、接続にドロップ、遅延、またはジッターがあるかどうかを確認するには、次のコマンドを使用します。

Device# test wireless redundancy rping
Redundancy Port ping
PING 169.254.64.60 (169.254.64.60) 56(84) bytes of data.
64 bytes from 169.254.64.60: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 169.254.64.60: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 169.254.64.60: icmp_seq=3 ttl=64 time=0.074 ms

--- 169.254.64.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2041ms
rtt min/avg/max/mdev = 0.074/0.082/0.091/0.007 ms
test wireless redundancy

HA ポートインターフェイスの設定ステータスを表示するには、show platform hardware slot R0 ha_port interface stats コマンドを使用します。 


Device# show platform hardware slot R0 ha_port interface stats
HA Port
ha_port   Link encap:Ethernet  HWaddr 70:18:a7:c8:80:70
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:e0900000-e0920000

Settings for ha_port:
        Supported ports:            [ TP ]
        Supported link modes:       10baseT/Half 10baseT/Full
                                    100baseT/Half 100baseT/Full
                                    1000baseT/Full
        Supported pause frame use:   Symmetric
        Supports auto-negotiation:   Yes
        Supported FEC modes:         Not reported
        Advertised link modes:       10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
                                     1000baseT/Full
        Advertised pause frame use:  Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes:        Not reported
        Speed:                       Unknown!
        Duplex:                      Unknown! (255)
        Port:                        Twisted Pair
        PHYAD:                       1
        Transceiver:                 internal
        Auto-negotiation:            on
        MDI-X:                       off (auto)
        Supports Wake-on:            pumbg
        Wake-on:                     g
        Current message level:       0x00000007 (7)
                                     drv probe link
        Link detected:               no

NIC statistics:
     rx_packets:             0
     tx_packets:             0
     rx_bytes:               0
     tx_bytes:               0
     rx_broadcast:           0
     tx_broadcast:           0
     rx_multicast:           0
     tx_multicast:           0
     multicast:              0
     collisions:             0
     rx_crc_errors:          0
     rx_no_buffer_count:     0
     rx_missed_errors:       0
     tx_aborted_errors:      0
     tx_carrier_errors:      0
     tx_window_errors:       0
     tx_abort_late_coll:     0
     tx_deferred_ok:         0
     tx_single_coll_ok:      0
     tx_multi_coll_ok:       0
     tx_timeout_count:       0
     rx_long_length_errors:  0
     rx_short_length_errors: 0
     rx_align_errors:        0
     tx_tcp_seg_good:        0
     tx_tcp_seg_failed:      0
     rx_flow_control_xon:    0
     rx_flow_control_xoff:   0
     tx_flow_control_xon:    0
     tx_flow_control_xoff:   0
     rx_long_byte_count:     0
     tx_dma_out_of_sync:     0
     tx_smbus:               0   
     rx_smbus:               0
     dropped_smbus:          0
     os2bmc_rx_by_bmc:       0
     os2bmc_tx_by_bmc:       0
     os2bmc_tx_by_host:      0
     os2bmc_rx_by_host:      0
     tx_hwtstamp_timeouts:   0
     rx_hwtstamp_cleared:    0
     rx_errors:              0
     tx_errors:              0
     tx_dropped:             0
     rx_length_errors:       0
     rx_over_errors:         0
     rx_frame_errors:        0
     rx_fifo_errors:         0
     tx_fifo_errors:         0
     tx_heartbeat_errors:    0
     tx_queue_0_packets:     0
     tx_queue_0_bytes:       0
     tx_queue_0_restart:     0
     tx_queue_1_packets:     0
     tx_queue_1_bytes:       0
     tx_queue_1_restart:     0
     rx_queue_0_packets:     0
     rx_queue_0_bytes:       0
     rx_queue_0_drops:       0
     rx_queue_0_csum_err:    0
     rx_queue_0_alloc_failed:0
     rx_queue_1_packets:     0
     rx_queue_1_bytes:       0
     rx_queue_1_drops:       0
     rx_queue_1_csum_err:    0
     rx_queue_1_alloc_failed:0

アプリケーション セントリック インフラストラクチャ（ACI）ネットワークのハイアベイラビリティ展開

コントローラでの ACI ネットワークの展開について

Cisco Application Centric Infrastructure（ACI）テクノロジーによって、プログラム可能なマルチハイパーバイザ ファブリック内で仮想ワークロードと物理ワークロードが統合され、マルチサービス データセンターまたはクラウドデータセンターが構築されます。


（注）  

Cisco ACI テクノロジーは、冗長管理インターフェイス（RMI）の高可用性ネットワークでのみサポートされます。

次の図は、スパインおよびリーフスイッチトポロジで接続され、単一のエンティティとしてプロビジョニングおよび管理される個別のコンポーネントを示しています。

図 1. Cisco ACI ネットワークの展開

次のメカニズムは、トラフィックのインターリーブを回避するのに役立ちます。

ワイヤレス管理インターフェイスをより迅速に停止

ACI 展開でのスイッチオーバーの場合、古いアクティブコントローラと新しいアクティブコントローラ間のトラフィックのインターリーブが原因で、AP とクライアントがドロップされます。この問題を解決するには、古いアクティブコントローラからのトラフィックをより迅速にダウンさせます。これを行うには、障害が検出されたらすぐにワイヤレス管理インターフェイスをダウンします。ワイヤレス管理インターフェイスがシャットダウンすると、古いアクティブワイヤレス管理インターフェイスから送信されるトラフィックが停止します。これにより、管理 IP アドレスの競合を回避できます。スタンバイコントローラは、新しい IP- MAC バインドを持つアクティブコントローラのロールに移行します。


（注）  

ACI 展開の IP データプレーン学習機能は、次を追跡します。

  • 同じ IP の重複 MAC アドレス。

  • 設定された期間、IP アドレスをブロックするアラーム。

障害検出中に、コントローラはシャーシプロパティ non-participant を設定します。IP データプレーン学習機能では、ワイヤレス管理インターフェイスを停止し、古いアクティブコントローラのトラフィックをより迅速にシャットダウンするためのプロパティをリッスンすることで、古いアクティブコントローラと新しいアクティブコントローラ間のトラフィックのインターリーブを回避します。

高速スイッチオーバー通知の無効化

このメカニズムにより、トラフィックのインターリーブを回避するための制御が強化されます。

障害の処理中に、アクティブコントローラはスタンバイコントローラに明示的な通知を送信し、ダウンしていることを示します。これにより、スタンバイノードがアクティブノードとして引き継がれます。障害が発生した場合は、高速スイッチオーバー通知の無効化オプションを使用して、アクティブからスタンバイへの明示的な通知を制御できます。明示的な通知がない場合、スタンバイコントローラはキープアライブタイムアウトに基づいてアクティブコントローラを引き継ぎます。


（注）  

キープアライブタイムアウトを設定して、障害が発生した場合に、新しいアクティブコントローラからのトラフィックがいつ開始されるかを制御できます。このような障害のシナリオでは、スイッチオーバーも遅延します。

このオプションを有効にすると、アクティブコントローラはスタンバイコントローラに明示的な障害の通知メッセージを送信できません。スタンバイコントローラは、キープアライブタイムアウトの障害のみに依存してアクティブコントローラがいつダウンしたかを検出します。

これにより、新しいアクティブコントローラで開始されるトラフィックのキープアライブタイムアウトが遅延し、古いアクティブコントローラからのトラフィックの重複が回避されます。したがって、高速スイッチオーバー通知を無効にすると、追加のキープアライブタイムアウト時間だけスイッチオーバー時間が長くなります。

GARP バースト

コントローラのスイッチオーバーイベント中に、GARP トラフィックがバーストで生成され、ACI の ARP 学習が過剰になります。この機能により、新しいアクティブコントローラからのスイッチオーバー後に、はるかに低いレートで GARP パケットを再送信する方法が考案されます。

コントローラで ACI ネットワークを展開するための前提条件

Cisco ACI が設定された IPv4 および IPv6 エンドポイントを超えないように、高可用性でサポートされるクライアントの最大数を確認します。

高速スイッチオーバー通知メカニズムの無効化（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

no redun-management fast-switchover

例:

Device(config)# no redun-management fast-switchover

明示的に高速スイッチオーバー通知を無効にします。

（注）  

 

プライマリコントローラで高速スイッチオーバー通知メカニズムを設定します。この設定は、セカンダリコントローラでは必要ありません。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

Gratuitous ARP（GARP）再送信の設定（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

redun-management garp-retransmit burst packet-burst-size interval time-interval

例:

Device(config)# redun-management garp-retransmit burst 0 interval 0

GARP 再送信が実行されるレートを決定します。

（注）  

 

  • packet-burst-size ：有効な範囲は 0 ～ 1000 です。値を 0 にすると、再送信が無効になります。

  • time-interval ：時間間隔を秒単位で示します。有効な範囲は 0 ～ 5 秒です。値を 0 にすると、再送信が無効になります。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

初期 GARP の無効化（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

no redun-management garp-retransmit initial

例:

Device(config)# no redun-management garp-retransmit initial

初期 GARP を無効にします。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

スイッチオーバーの設定

手順

コマンドまたはアクション 目的

To force a failover to the standby unit, use the following command:

例:

Device#redundancy force-switchover

この場合、スタンバイコントローラがアクティブコントローラの役割を担い、アクティブコントローラがリロードされて新しいスタンバイコントローラになります。このコマンドを使用して、高可用性クラスタの安定性をテストし、スイッチオーバーが期待どおりに機能しているかどうかを確認することができます。

（注）  

 

Cisco Catalyst 9800 シリーズ ワイヤレス コントローラ間のスイッチオーバーをテストするために、他のコマンドを使用しないでください。"reload slot X"（X はアクティブコントローラ）などのコマンドを使用すると予期しない動作が発生する可能性があるため、スイッチオーバーを実行するために使用しないでください。

リダンダンシー マネジメント インターフェイスについて

リダンダンシー マネジメント インターフェイス（RMI）は、アクティブおよびスタンバイの Cisco Catalyst 9800 シリーズ ワイヤレス コントローラ間のセカンダリリンクとして使用されます。このインターフェイスはワイヤレス管理インターフェイスと同じであり、このインターフェイス上の IP アドレスはワイヤレス管理 IP と同じサブネットで設定されます。RMI は、次の目的で使用されます。

  • デュアルアクティブ検出

  • コントローラ間のリソースの正常性情報（たとえば、いずれかのコントローラからのゲートウェイ到達可能性ステータス）を交換します。

  • この機能が有効になっている場合、ゲートウェイの到達可能性が、RMI を介してアクティブコントローラとスタンバイコントローラでチェックされます。コントローラがゲートウェイの到達可能性を失ったことを検出するには、おおよそで設定されたゲートウェイモニタリング間隔だけかかります。デフォルトのゲートウェイモニタリング間隔値は 8 秒です。


（注）  

  • RMI により、アクティブコントローラのゲートウェイステータスに基づいてスイッチオーバーがトリガーされる可能性があります。

  • Cisco TrustSec は RMI でサポートされていません。

    デバイス SGT を使用する場合、RMI アドレスの IP-SGT マッピングも WMI アドレスとともに適用されます。そのため、アクティブ RMI アドレスとスタンバイ RMI アドレス間の ICMP および ARP トラフィックを許可するように、SGACL が適切に定義されていることを確認する必要があります。

  • RP リンクと RMI リンクがダウンしている場合、HA セットアップは 2 つのアクティブコントローラに分割されます。これにより、ネットワーク内で IP の競合が発生します。RP リンクがアップすると、HA セットアップが再び形成されます。このときの外部スイッチの状態によって、ARP テーブルがアクティブコントローラを指すように更新される場合と更新されない場合があります。つまり、スイッチはコントローラからの GARP パケットの処理に失敗する可能性があります。ベストプラクティスとして、複数の障害シナリオからより迅速に回復するために、ARP キャッシュタイムアウト値を低い値に保つことをお勧めします。ネットワークトラフィックに影響を与えない値（たとえば 30 分）を選択する必要があります。


（注）  

コントローラから発信される AAA パケットは、ワイヤレス管理 IP または RMI IP のいずれかを使用できます。そのため、AAA サーバーで WMI IP とともに送信元 IP として RMI IP を追加してください。

アクティブコントローラ

アクティブコントローラのプライマリアドレスは、管理 IP アドレスです。管理 VLAN のセカンダリ IPv4 アドレスは、アクティブコントローラの RMI IP アドレスです。セカンダリ IPv4 アドレスを明示的に設定しないでください。単一のセカンダリ IPv4 アドレスが RMI によって RMI の下に自動的に設定されるためです。

スタンバイコントローラ

スタンバイコントローラには、ワイヤレス管理 IP が設定されておらず、RMI IP アドレスがプライマリ IP アドレスとして設定されています。スタンバイコントローラがアクティブになると、管理 IP アドレスがプライマリ IP アドレスになり、RMI IP アドレスがセカンダリ IP アドレスになります。アクティブコントローラのインターフェイスが管理上ダウン状態になった場合は、同じ状態がスタンバイコントローラに反映されます。

RMI を使用した管理 VLAN でのデュアルスタックのサポート

デュアルスタックとは、ワイヤレス管理インターフェイスを IPv4 および IPv6 アドレスで設定できることを指します。RMI IPv4 アドレスが IPv4 管理 IP アドレスとともに設定されている場合は、ワイヤレス管理インターフェイスで IPv6 管理アドレスを追加で設定できます。この IPv6 管理 IP アドレスは、スタンバイコントローラでは表示されません。

RMI IPv6 アドレスが IPv6 管理 IP アドレスとともに設定されている場合は、ワイヤレス管理インターフェイスで IPv4 管理アドレスを追加で設定できます。この IPv4 管理 IP アドレスは、スタンバイコントローラでは表示されません。

そのため、RMI IPv6 アドレスが設定されている場合は IPv6 ゲートウェイのみ、または RMI IPv4 アドレスが設定されている場合は IPv4 ゲートウェイのみをモニターできます。


（注）  

RMI 機能は RMI IPv4 または IPv6 アドレスをサポートします。

RMI ベースのハイ アベイラビリティ ペアリング

HA ペアリングについては、次のシナリオを考慮する必要があります。

  • 新規インストール

  • すでにペアリングされているコントローラ

  • アップグレード シナリオ

  • ダウングレードのシナリオ

動的な HA ペアリングを行うには、アクティブコントローラとスタンバイコントローラの両方をリロードする必要があります。ただし、Cisco Catalyst 9800-L ワイヤレスコントローラ、Cisco Catalyst 9800-40 ワイヤレスコントローラ、および Cisco Catalyst 9800-80 ワイヤレスコントローラのいずれかがリロードされてスタンバイコントローラになった場合は、それらのコントローラで動的な HA ペアリングが発生します。


（注）  

シャーシ番号は個々のコントローラを識別します。HA ペアを形成する前に、一意のシャーシ番号を設定する必要があります。

以前の設定を使用しない HA ペアリング

HA ペアリングが初めて実行されるときは、RP IP アドレスの ROMMON 変数は見つかりません。既存の特権 EXEC モードの RP ベースのコマンドか、RMI IP ベースのメカニズムから選択できます。ただし、特権 EXEC モードの RP ベースのコマンドは間もなく廃止されます。Cisco Catalyst Center を使用する場合は、Cisco Catalyst Center が RMI をサポートするように移行するまで、特権 EXEC モードの RP ベース CLI のメカニズムを選択できます。

RP IP は、HA ペアが形成された後に RMI IP から導出されます。また、RMI IP ベースの HA メカニズムが選択された後は、特権 EXEC モードの RP ベース CLI による HA ペアのクリアと形成の方法は使用できません。


（注）  

  • 新規インストールには RP または RMI を選択できますが、RMI のインストール方法を使用することを推奨します。

  • ROMMON 変数を表示するには、show romvars コマンドを使用します。

特権 EXEC モードの RP ベース CLI のメカニズムを選択した場合、RP IP は 16.12 リリースと同じ方法で設定されます。

RMI ベースの HA ペアリングが新しいシステムで実行されると、次のことが行われます。

  • RP IP が RMI IP から導出され、HA ペアリングで使用されます。

  • 特権 EXEC モードの RP ベース CLI がブロックされます。


（注）  

RMI の移行は、Cisco Catalyst Center、2.3.3.x リリースバージョンからサポートされています。

RMI の移行時には次の制限があります。

  • 適切でないケースは、次の理由により失敗します。

    • デバイスに到達できない場合。

    • Cisco Catalyst 9800 シリーズ以外のワイヤレスコントローラが使用されている場合。

    • 以前のバージョンのコントローラ（Cisco IOS XE 17.3）が使用されている場合。

    • 高可用性が設定されていない場合。

    • 高可用性 RMI がすでに設定されている場合。

  • 高可用性が Cisco IOS XE リリースバージョン 17.3 以降の RMI ベースの高可用性にアップグレードされた場合。

  • すでに失敗した高可用性ペアコントローラに対してアップグレードする場合。

  • コントローラ GUI では、高可用性が失敗したデバイスに RMI 移行設定を適用することが禁止されています。

ペアリングされているコントローラ

コントローラがすでに HA ペアになっている場合は、既存の EXEC モードの RP ベースのコマンドが引き続き使用されます。RMI を有効にして、RMI ベースの HA ペアリングに移行することができます。

コントローラがすでにペアリングされていて、RMI が設定されている場合は、コントローラによって、RP IP が RMI から導出された IP に上書きされます。HA ペアはすぐには妨害されませんが、次のリロードが発生するとコントローラによって新しい IP が選択されます。RMI 機能を有効にするには、リロードする必要があります。両方のコントローラがリロードされると、RMI から導出された新しい RP IP とのペアとして起動します。

RMI の設定が完了すると、次の動作が発生します。

  • RMI IP から導出された RP IP は上書きされ、HA ペアリングに使用されます。

  • EXEC モードの RP ベースのコマンドのメカニズムによる HA ペアリングの前にアクティブコントローラとスタンバイコントローラがすでに存在している場合、ペアは中断されません。

  • ペアが後でリロードされると、新しい RP IP が使用されます。

  • EXEC モードの RP ベースのコマンドがブロックされます。

Cisco IOS XE 16.1.x から以降のリリースへのアップグレード

アップグレード中のシステムでは、次のいずれかを選択できます。

  • 既存の RP IP 設定をそのまま使用して移行する：この場合は、既存の RP IP 設定が引き続き使用されます。EXEC モードの RP ベースのコマンドは、将来の変更の場合に使用されます。

  • HA 設定をクリアした後に移行する：この場合は、古い方法（EXEC モードの RP ベースのコマンド）か、新しい RMI ベースの RP のいずれかの設定方法から選択できます。


（注）  

古い設定を保持した場合は、RMI 設定によって、RP IP が、RMI IP から導出された IP に更新されます。

ダウングレードのシナリオ


（注）  

次に示すダウングレードシナリオは、Cisco IOS XE Amsterdam 17.1.x には適用されません。

このダウングレードシナリオでは、EXEC モードの RP ベースのコマンドのみを扱います。次の 2 つの可能性があります。

  • アップグレードしたシステムで RMI ベースの RP 設定を使用していた場合。

  • アップグレードしたシステムで引き続き EXEC モードの RP ベースのコマンドを使用していた場合。


（注）  

上記の場合、ダウングレードしたシステムは、EXEC モードの RP ベースのコマンドを使用して設定を変更します。ただし、ダウングレードしたシステムでは、導出された新しい RP IP が引き続き使用されます。

（注）  

Cisco Catalyst 9800 シリーズ ワイヤレス コントローラを 17.1 より前のバージョンにダウングレードし、WLAN/RLAN/GLAN インターフェイスで mDNS ゲートウェイが有効になっている場合、ダウングレード後に mdns-sd-interface ゲートウェイがダウンします。

16.12 以前のバージョンの WLAN/RLAN/GLAN インターフェイスで mDNS ゲートウェイを有効にするには、次のコマンドを使用します。

wlan test 1 test

mdns-sd gateway

バージョン 17.1 以降の WLAN/RLAN/GLAN インターフェイスで mDNS ゲートウェイを有効にするには、次のコマンドを使用します。

mdns-sd-interface gateway

ゲートウェイのモニタリング

Cisco IOS XE Amsterdam 17.2.1 以降では、ゲートウェイ IP を設定する方法が変更されました。ip default-gateway gateway-ip コマンドは使用されません。代わりに、設定されたスタティックルートに基づいてゲートウェイ IP が選択されます。設定されたスタティックルートの中から、RMI サブネットと同じサブネットに属するゲートウェイ IP（最も広いマスクと最も小さいゲートウェイ IP）が選択されます。一致するスタティックルートが見つからない場合、（管理ゲートウェイのフェールオーバーが有効になっている場合でも）ゲートウェイのフェールオーバーは機能しません。

リダンダンシー マネジメント インターフェイス（RMI）の設定

始める前に

GUI を使用して RMI + RP を設定する前に、WMI が使用可能であることを確認します。

手順

ステップ 1

[Administration] > [Device] > [Redundancy] ウィンドウで、次の手順を実行します。

  1. [Redundancy Configuration] トグルボタンを [Enabled] に設定して冗長性設定をアクティブ化します。

  2. [Redundancy Pairing Type] フィールドで、[RMI+RP] を選択し、次のように RMI+RP 冗長性ペアリングを実行します。

    • [RMI IP for Chassis 1] フィールドに、シャーシ 1 の RMI IP アドレスを入力します。

    • [RMI IP for Chassis 2] フィールドに、シャーシ 2 の RMI IP アドレスを入力します。

    • [HA Interface] ドロップダウンリストから、いずれかの HA インターフェイスを選択します。

      （注）  

       

      HA インターフェイスは、Cisco Catalyst 9800 シリーズ ワイヤレス コントローラに対してのみ選択できます。

    • [Management Gateway Failover] トグルボタンを [Enabled] に設定して、管理ゲートウェイのフェールオーバーをアクティブにします。

    • [Gateway Failure Interval] フィールドに、適切な値を入力します。有効な範囲は、6 ～ 12 秒です。デフォルトは 8 秒です。

  3. [Redundancy Pairing Type] フィールドで、[RP] を選択し、次のように RMI 冗長性ペアリングを実行します。

    • [Local IP] フィールドに、ローカル IP の IP アドレスを入力します。

    • [Netmask] フィールドに、すべてのワイヤレスクライアントに割り当てられたサブネットマスクを入力します。

    • [HA Interface] ドロップダウンリストから、いずれかの HA インターフェイスを選択します。

      （注）  

       

      HA インターフェイスは、Cisco Catalyst 9800 シリーズ ワイヤレス コントローラに対してのみ選択できます。

    • [Remote IP] フィールドに、リモート IP の IP アドレスを入力します。

  4. [Keep Alive Timer] フィールドに、適切なタイマー値を入力します。有効な範囲は 1 ～ 10（x100 ミリ秒）です。

  5. [Keep Alive Retries] フィールドに、適切な再試行値を入力します。有効な範囲は 3 ～ 10 秒です。

  6. [Active Chassis Priority] フィールドに、値を入力します。

ステップ 2

[Apply] をクリックし、コントローラをリロードします。

リダンダンシー マネジメント インターフェイスの設定（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

chassis chassis-num priority chassis-priority

例:

Device# chassis 1 priority 1

（オプション）指定されたデバイスの優先順位を設定します。

（注）  

 

Cisco IOS XE Gibraltar 16.12.x 以降では、シャーシの優先順位を有効にするためにデバイスをリロードする必要はありません。

  • chassis-num ：シャーシ番号を入力します。有効な範囲は 1 ～ 2 です。

  • chassis-priority ：シャーシのプライオリティを入力します。有効な範囲は 1 ～ 2 です。デフォルト値は 1 です。

（注）  

 

両方のデバイスが同時に起動すると、優先順位が高いデバイスがアクティブになり、もう一方はスタンバイになります。両方のデバイスに同じ優先順位値が設定されている場合、MAC アドレスが小さいデバイスがアクティブとして機能し、そのピアがスタンバイとして機能します。

ステップ 2

chassis redundancy ha-interface GigabitEthernet interface-number

例:

Device# chassis redundancy ha-interface 
GigabitEthernet 3

コントローラの HA インターフェイスを作成します。

  • interface-number ：ギガビットイーサネット インターフェイス番号。指定できる範囲は 1 ～ 32 です。

（注）  

 

この手順は、Cisco Catalyst 9800-CL シリーズ ワイヤレス コントローラにのみ適用されます。選択したインターフェイスは、2 つのコントローラ間の HA 通信の専用インターフェイスとして使用されます。

ステップ 3

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 4

redun-management interface vlan vlan-interface-number chassis chassis-number address ip-address chassis chassis-number address ip-address

例:

Device(config)# redun-management interface 
Vlan 200 chassis 1 address 9.10.90.147 
chassis 2 address 9.10.90.149

リダンダンシー マネジメント インターフェイスを設定します。

  • vlan-interface-number ：VLAN インターフェイス番号。有効な範囲は 1 ～ 4094 です。

    （注）  

     

    ここで、vlan-interface-number は管理 VLAN と同じ VLAN です。つまり、両方とも同じサブネット上に存在する必要があります。

  • chassis-number ：シャーシ番号。有効な範囲は 1 ～ 2 です。

  • ip-address ：リダンダンシー マネジメント インターフェイスの IP アドレス。

（注）  

 

HA ペアを形成するには、各コントローラに RMI の一意のシャーシ番号が必要です。シャーシ番号は、show romvar コマンドの出力の SWITCH_NUMBER として確認できます。現在、SWITCH_NUMBER の変更は Web UI では使用できません。

HA ペアを無効にするには、no redun-management interface vlan chassis コマンドを使用します。

ステップ 5

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

ステップ 6

write memory

例:

Device# write memory

設定を保存します。

ステップ 7

reload

例:

Device# reload

コントローラをリロードします。

（注）  

 

RMI の設定が完了したら、設定を有効にするためにコントローラをリロードする必要があります。

Cisco Catalyst 9800-CL ワイヤレスコントローラ VM の場合、アクティブコントローラとスタンバイコントローラの両方が自動的にリロードします。ハードウェア プラットフォームの場合は、コントローラが自動的にリロードするのはスタンバイのみであるため、アクティブコントローラを手動でリロードする必要があります。

ゲートウェイモニタリングの設定（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

[no] management gateway-failover enable

例:

Device(config)# management gateway-failover enable

ゲートウェイモニタリングを有効にします。（ゲートウェイモニタリングを無効にするには、このコマンドの no 形式を使用します）。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

（注）  

 

コンフィギュレーションを保存するには、write memory コマンドを使用します。

ゲートウェイモニタリング間隔の設定（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

management gateway-failover interval interval-value

例:

Device(config)# management gateway-failover interval 6

ゲートウェイモニタリング間隔を設定します。

interval-value ：ゲートウェイモニタリング間隔を示します。有効な範囲は 6 ～ 12 です。デフォルト値は 8 です。

ステップ 3

end

例:

Device(config)# end

設定を保存し、コンフィギュレーション モードを終了して、特権 EXEC モードに戻ります。

ゲートウェイ到達可能性検出

ゲートウェイ到達可能性検出について

ゲートウェイ到達可能性検出機能は、アクティブコントローラでゲートウェイの到達可能性が失われた場合に、AP とクライアントのダウンタイムを最小限に抑えます。

アクティブコントローラとスタンバイコントローラの両方がゲートウェイの到達可能性を追跡します。ゲートウェイの到達可能性は、Internet Control Message Protocol（ICMP）および ARP 要求をゲートウェイに定期的に送信することで検出されます。

アクティブコントローラとスタンバイコントローラの両方が、送信元 IP として RMI IP を使用します。このメッセージは 1 秒間隔で送信されます。ゲートウェイへの到達に 8（または設定値）回連続して失敗すると、コントローラはそのゲートウェイを到達不能と宣言します。コントローラがゲートウェイの到達可能性を失ったかどうかを検出するには、約 8 秒かかります。

ネイティブ IPv6 を使用したゲートウェイモニタリングでは、ICMP ネイバー探索プロトコルと ICMPv6 ECHO を使用してゲートウェイの到達可能性を確認します。

そのため、RMI IPv6 が設定されている場合は、IPv6 ゲートウェイのみをモニターできます。

つまり、IPv4 または IPv6 ゲートウェイのうち 1 つのみをモニターできます。


（注）  

スタンバイコントローラがゲートウェイを失うと、スタンバイがスタンバイリカバリモードに移行します。

アクティブコントローラがゲートウェイを失うと、アクティブがリロードされ、スタンバイがアクティブになります。

設定ワークフロー

  1. リダンダンシー マネジメント インターフェイスの設定（GUI）（または）リダンダンシー マネジメント インターフェイスの設定（CLI）。詳細については、リダンダンシー マネジメント インターフェイス（RMI）の設定を参照してください。


    （注）  

    RMI 設定を有効にするには、コントローラをリロードしてください。

  2. IPv6 スタティックルートの設定。詳細については、「ゲートウェイのモニタリング」を参照してください。

  3. ゲートウェイモニタリング間隔の設定（CLI）。詳細については、ゲートウェイモニタリング間隔の設定（CLI）を参照してください。

RMI IPv6 への移行

RMI IPv4 から

  1. 次の CLI を使用して、RMI IPv4 の設定を解除します。

    
Device# conf t
Device(config)# no redun-management interface <vlan_name> chassis 1 address <ip_address1> chassis 2 address <ip_address2>

    （注）  

    この CLI は、両方のコントローラの RMI の設定を解除します。

  2. （注）  

    コントローラをリロードする前に、アクティブで実行中の設定のバックアップを作成します。

    コントローラをリロードします。

  3. すべての設定が失われているボックスの実行中の設定に、バックアップした設定をコピーします。

  4. 両方のコントローラで RMI IPv6 を設定します。CLI の詳細については、「」を参照してください。

  5. コントローラをリロードします。

HA ペアリングから（RMI なし）

HA ペアリングの詳細については、「リダンダンシー マネジメント インターフェイスの設定（GUI）」を参照してください。

スタンバイコントローラの正常性のモニタリング

スタンバイモニタリング機能を使用すると、プログラムインターフェイスとコマンドを使用して、スタンバイコントローラ上のシステムの正常性をモニターすることができます。この機能を使用すると、CPU、メモリ、インターフェイスステータス、電源、ファン障害、システム温度などのパラメータをモニターすることができます。スタンバイモニタリングは、リダンダンシー マネジメント インターフェイス（RMI）が設定されている場合に有効になります。他の設定は必要ありません。RMI 自体は、スタンバイに接続し、スタンバイモニタリングを実行するために使用されます。スタンバイモニタリング機能を動的に有効または無効にすることはできません。


（注）  

アクティブコントローラは、管理 IP または RMI IP を使用して AAA 要求を開始します。一方、スタンバイコントローラは RMI IP を使用して AAA 要求を開始します。そのため、シームレスなクライアント認証とスタンバイモニタリングのために、RMI IP を AAA サーバーに追加する必要があります。

スタンバイコンソールを有効にするには、次の設定が行われていることを確認します。

redundancy
main-cpu
secondary console enable

（注）  

スタンバイモニタリング機能は、アクティブリカバリモードとスタンバイリカバリモードのコントローラではサポートされていません。

スタンバイモニタリング機能は、スタンバイコントローラの RMI インターフェイスで次のトラフィックのみをサポートしています。

  • Address Resolution Protocol（ARP）

  • インターネット制御メッセージ プロトコル（ICMP）

  • TCP トラフィック（送受信）ポート：22、443、830、および 3200

  • UDP RADIUS ポート：1645 および 1646

  • UDP 拡張 RADIUS ポート：21645 ～ 21844

機能のシナリオ

  • スタンバイ RMI IP を使用して、スタンバイコントローラからスタンバイの正常性を直接モニターします。

  • スタンバイ RMI IP を使用して、スタンバイコントローラから syslog を取得します。

ユースケース

  • スタンバイコントローラでの SNMP エージェントおよびプログラムインターフェイスの有効化：スタンバイの RMI IP およびアクティブコントローラに対して、SNMP クエリまたはプログラム インターフェイス クエリを直接実行できます。

  • スタンバイコントローラでの syslog の有効化：スタンバイコントローラからスタンバイ syslog を直接取得できます。

RADIUS アカウンティングのサポート

スタンバイデバイスにログインするたびに、RADIUS 開始レコードを外部 RADIUS サーバーに送信する必要があります。同様に、デバイスからログアウトしたときに、RADIUS 停止レコードを外部 RADIUS サーバーに送信する必要があります。

TACACS+ 認証のサポート

ユーザーは、外部 TACACS+ サーバーを使用して、RMI を介して認証されます。ユーザー名とパスワードは、TACACS+ サーバーで評価されます。サーバーから受信した応答に応じて、ユーザーはスタンバイデバイスにログインできます。

TACACS+ アカウンティングのサポート

スタンバイデバイスにログインするたびに、TACACS+ アカウンティング開始レコードを外部 TACACS+ サーバーに送信する必要があります。同様に、デバイスからログアウトしたときに、TACACS+ アカウンティング停止レコードを外部 TACACS+ サーバーに送信する必要があります。


（注）  

アカウンティングパケットを送信するように AAA を設定するには、次の設定を行う必要があります。

aaa accounting exec {default | named-list} start-stop group {RAD | tac-group-name}

（注）  

TACACS+ サーバーがホスト名で設定されている場合、スタンバイデバイスへの TACACS+ ログインはサポートされません。

SNMP を使用したスタンバイパラメータの正常性のモニタリング

スタンバイ RMI IP を使用したスタンバイのモニタリング

スタンバイコントローラで SNMP エージェントが有効になっている場合は、スタンバイの RMI IP に対して SNMP クエリを直接実行できます。リリース 17.5 以降では、スタンバイコントローラで次の MIB をクエリできます。

表 4. MIB 名と注意事項

MIB 名

注意

IF-MIB

この MIB は、スタンバイ RMI IP アドレスを使用してスタンバイコントローラのインターフェイス統計をモニターするために使用されます。

（注）  

アクティブなコントローラで SNMP エージェントが有効になっている場合、デフォルトではスタンバイコントローラで SNMP が有効になります。

アクティブコントローラを使用したスタンバイのモニタリング

CISCO-LWAPP-HA-MIB

CISCO-LWAPP- HA -MIB は、スタンバイコントローラの正常性パラメータ（メモリ、CPU、ポートステータス、電力統計、ピアゲートウェイの遅延など）をモニタリングします。

CISCO-LWAPP-HA-MIB の次の MIB オブジェクトをクエリできます。

表 5. MIB オブジェクトと注記

MIB オブジェクト

注

cLHaPeerHotStandbyEvent

このオブジェクトを使用して、スタンバイコントローラがホットスタンバイになったかどうかを確認できます。

cLHaBulkSyncCompleteEvent

このオブジェクトは、一括同期が完了した時刻を表します。

CISCO-PROCESS-MIB

CISCO-PROCESS-MIB は、CPU およびプロセスの統計をモニタリングします。これを使用して、CPU 関連またはメモリ関連の BINOS プロセスをモニタリングします。スタンバイ CISCO-PROCESS-MIB は、アクティブコントローラを使用してモニタリングできます。

ENTITY-MIB

ENTITY-MIB は、アクティブコントローラを使用してアクティブコントローラおよびスタンバイコントローラのハードウェアの詳細をモニタリングするために使用されます。


（注）  

スタンバイルートプロセッサ（RP）センサーは、アクティブ RP センサーに追加されます。

スタンバイ IOS Linux Syslog

スタンバイログは、ワイヤレスコントローラのアクティブ Cisco IOS と同じ方法を使用してリレーされます。

リリース 17.5 以降では、スタンバイ IOS の syslog の外部ロギングが有効になっています。スタンバイの BINOS プロセスも syslog を Cisco IOS に転送するため、スタンバイコントローラで生成されたすべての syslog は設定された外部サーバーに転送されます。


（注）  

RMI IP アドレスは、ロギングの目的で使用されます。

HA ペアが RMI IPv6 アドレスで設定され、アクティブコントローラにデュアルスタックがあり、ロギングが IPv4 アドレスで設定されている場合、予想される動作は次のとおりです。

IPv4 がスタンバイでサポートされていない場合でも、ロギングは IPv4 でのみ設定されるため、スタンバイコントローラは IPv4 サーバーに syslog を送信しようとします。

アクティブな SNMP を使用したスタンバイ インターフェイス ステータス

スタンバイインターフェイス情報は、次のシナリオで IPC を使用してアクティブコントローラに送信されます。

  • インターフェイスのステータスに変更があった場合。

  • スタンバイコントローラで新しいインターフェイスが追加または削除された場合。

アクティブコントローラがスタンバイコントローラからインターフェイス情報を受信すると、アクティブコントローラのデータベースにスタンバイインターフェイス情報が入力されます。

スタンバイインターフェイス情報の SNMP クエリを受信すると、CISCO-LWAPP-HA-MIB に対応する SNMP ハンドラは、アクティブ上のスタンバイ インターフェイス データベースからそれらの情報を読み取り、CISCO-LWAPP-HA-MIB の MIB オブジェクトに書き込みます。

CISCO-LWAPP-HA-MIB の次の MIB オブジェクトをクエリできます。

表 6. CISCO-LWAPP-HA-MIB の MIB オブジェクト

MIB オブジェクト

注

stbyIfIndex

これは、スタンバイコントローラの各インターフェイスに固有の（ゼロより大きい）値です。

stbyIfName

これは、スタンバイインターフェイスの名前です。

stbyIfPhysAddress

これは、プロトコルサブレイヤのスタンバイコントローラのインターフェイスアドレスです。

stbyifOperStatus

これは、スタンバイコントローラのインターフェイスの現在の動作状態です。

stbyifAdminStatus

これは、スタンバイコントローラのインターフェイスの望ましい状態です。

スタンバイがインターフェイス統計の送信に失敗した場合にアクティブでのロギングを確認するには、次のコマンドを使用します。


Device# debug snmp ha-chkpt
Device# debug snmp ha-intf_db

プログラムインターフェイスを使用したスタンバイコントローラの正常性のモニタリング

NETCONF や RESTCONF などのプログラムインターフェイスを使用して、スタンバイコントローラの CPU、メモリ、センサー、インターフェイスのステータスなどのパラメータをモニターできます。スタンバイコントローラの RMI IP は、次の運用モデルへのアクセスに使用できます。

モデルには、以下からアクセスできます。

  • Cisco-IOS-XE-device-hardware-oper.yang

  • Cisco-IOS-XE-process-cpu-oper.yang

  • Cisco-IOS-XE-platform-software-oper.yang

  • Cisco-IOS-XE-process-memory-oper.yang

  • Cisco-IOS-XE-interfaces-oper.yang

YANG モデルの詳細については、『Programmability Configuration Guide, Cisco IOS XE Amsterdam 17.3.x』を参照してください。

CLI を使用したスタンバイコントローラの正常性のモニタリング

このセクションでは、スタンバイデバイスのモニターに使用できるさまざまなコマンドについて説明します。

スタンバイコントローラの RMI IP を使用して、SSH 経由でスタンバイコントローラに接続できます。ユーザーのログイン情報はすでに設定されている必要があります。ローカル認証と RADIUS 認証の両方がサポートされています。


（注）  

高可用性（HA）ペアリングの前に、プライマリとスタンバイの両方のコントローラで redun-management コマンドを設定する必要があります。

ポート状態のモニタリング

次に、show interfaces interface-name コマンドの出力例を示します。 

Device-standby# show interfaces GigabitEthernet1        

GigabitEthernet1 is down, line protocol is down                                 
Shadow state is up, true line protocol is up
  Hardware is CSR vNIC, address is 000c.2909.33c2 (bia 000c.2909.33c2)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1000Mbps, link type is force-up, media type is Virtual
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:06, output 00:00:24, output hang never
  Last clearing of "show interface" counters never
  Input queue: 30/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 389000 bits/sec, 410 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     3696382 packets input, 392617128 bytes, 0 no buffer
     Received 0 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     18832 packets output, 1218862 bytes, 0 underruns
     Output 0 broadcasts (0 multicasts)
     0 output errors, 0 collisions, 2 interface resets
     3 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

次に、show ip interface brief コマンドの出力例を示します。 

Device# show ip interface brief

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       unassigned      YES unset  down                  down    
GigabitEthernet0       unassigned      YES NVRAM  administratively down down    
Capwap1                unassigned      YES unset  up                    up      
Capwap2                unassigned      YES unset  up                    up      
Capwap3                unassigned      YES unset  up                    up           
Capwap10               unassigned      YES unset  up                    up      
Vlan1                  unassigned      YES NVRAM  down                  down    
Vlan56                 unassigned      YES unset  down                  down    
Vlan111                111.1.1.85      YES NVRAM  up                    up

CPU またはメモリのモニタリング

次に、show process cpu sorted 5sec コマンドの出力例を示します。 

Device-standby# show process cpu sorted 5sec

CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process 
  10     1576556      281188       5606  0.15%  0.05%  0.05%   0 Check heaps      
 232      845057    54261160         15  0.07%  0.05%  0.06%   0 IPAM Manager     
 595         177         300        590  0.07%  0.02%  0.01%   2 Virtual Exec     
 138     1685973   108085955         15  0.07%  0.08%  0.08%   0 L2 LISP Punt Pro 
 193       19644      348767         56  0.07%  0.00%  0.00%   0 DTP Protocol     
   5           0           1          0  0.00%  0.00%  0.00%   0 CTS SGACL db cor 
   4          24          15       1600  0.00%  0.00%  0.00%   0 RF Slave Main Th 
   6           0           1          0  0.00%  0.00%  0.00%   0 Retransmission o 
   7           0           1          0  0.00%  0.00%  0.00%   0 IPC ISSU Dispatc 
   2      117631      348801        337  0.00%  0.00%  0.00%   0 Load Meter       
   8           0           1          0  0.00%  0.00%  0.00%   0 EDDRI_MAIN

binOS プロセスの CPU とメモリの使用率を確認するには、次のコマンドを実行します。

Device-standby# show platform software process slot chassis standby R0 monitor 

top - 23:24:14 up 8 days, 3:38, 0 users, load average: 0.69, 0.79, 0.81 
Tasks: 433 total, 1 running, 431 sleeping, 1 stopped, 0 zombie 
%Cpu(s): 1.7 us, 2.8 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 32059.2 total, 21953.7 free, 4896.8 used, 5208.6 buff/cache 
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 26304.6 avail Mem 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23565 root 20 0 2347004 229116 130052 S 41.2 0.7 5681:44 ucode_pkt+
2306 root 20 0 666908 106760 46228 S 5.9 0.3 15:06.14 smand 
22807 root 20 0 3473004 230020 152120 S 5.9 0.7 510:56.90 fman_fp_i+
1 root 20 0 14600 11324 7424 S 0.0 0.0 0:31.07 systemd 
2 root 20 0 0 0 0 S 0.0 0.0 0:00.28 kthreadd 
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0+
7 root 20 0 0 0 0 I 0.0 0.0 0:00.49 kworker/u+
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu+
9 root 20 0 0 0 0 S 0.0 0.0 0:03.26 ksoftirqd+
.
.
.
32258 root 20 0 57116 3432 2848 S 0.0 0.0 0:00.00 rotee
32318 root 20 0 139560 9500 7748 S 0.0 0.0 0:55.67 pttcd
32348 root 20 0 31.6g 3.1g 607364 S 0.0 9.8 499:12.04 linux_ios+
32503 root 20 0 3996 3136 2852 S 0.0 0.0 0:00.00 stack_snt+
32507 root 20 0 3700 1936 1820 S 0.0 0.0 0:00.00 sntp

ハードウェアのモニタリング

次に、show environment summary コマンドの出力例を示します。 

Device# show environment summary


Number of Critical alarms:  0
Number of Major alarms:     0
Number of Minor alarms:     0

 Slot        Sensor          Current State   Reading        Threshold(Minor,Major,Critical,Shutdown)
 ----------  --------------  --------------- ------------   ---------------------------------------
 P0          Vin             Normal          231  V AC   	na
 P0          Iin             Normal          2    A      	na
 P0          Vout            Normal          12   V DC   	na
 P0          Iout            Normal          30   A      	na
 P0          Temp1           Normal          25   Celsius	(na ,na ,na ,na )(Celsius)
 P0          Temp2           Normal          31   Celsius	(na ,na ,na ,na )(Celsius)
 P0          Temp3           Normal          37   Celsius	(na ,na ,na ,na )(Celsius)
 R0          VDMB1: VX1      Normal          1226 mV     	na
 R0          VDMB1: VX2      Normal          6944 mV     	na
 R0          Temp: DMB IN    Normal          26   Celsius	(45 ,55 ,65 ,70 )(Celsius)
 R0          Temp: DMB OUT   Normal          40   Celsius	(70 ,75 ,80 ,85 )(Celsius)
 R0          Temp: Yoda 0    Normal          54   Celsius	(95 ,105,110,115)(Celsius)
 R0          Temp: Yoda 1    Normal          62   Celsius	(95 ,105,110,115)(Celsius)
 R0          Temp: CPU Die   Normal          43   Celsius	(100,110,120,125)(Celsius)
 R0          Temp: FC FANS   Fan Speed 70%   26   Celsius	(29 ,39 ,0  )(Celsius)
 R0          VDDC1: VX1      Normal          1005 mV     	na
 R0          VDDC1: VX2      Normal          7084 mV     	na
 R0          VDDC2: VH       Normal          12003mV     	na
 R0          Temp: DDC IN    Normal          25   Celsius	(55 ,65 ,75 ,80 )(Celsius)
 R0          Temp: DDC OUT   Normal          35   Celsius	(75 ,85 ,95 ,100)(Celsius)
 P0          Stby Vin        Normal          230  V AC   	na
 P0          Stby Iin        Normal          2    A      	na
 P0          Stby Vout       Normal          12   V DC   	na
 P0          Stby Iout       Normal          32   A      	na
 P0          Stby Temp1      Normal          24   Celsius	(na ,na ,na ,na )(Celsius)
 P0          Stby Temp2      Normal          29   Celsius	(na ,na ,na ,na )(Celsius)
 P0          Stby Temp3      Normal          35   Celsius	(na ,na ,na ,na )(Celsius)
 R0          Stby VDMB1: VX1 Normal          1225 mV     	na
 R0          Stby VDMB1: VX2 Normal          6979 mV     	na
 R0          Stby VDMB2: VX2 Normal          5005 mV     	na
 R0          Stby VDMB2: VX3 Normal          854  mV     	na
 R0          Stby VDMB3: VX1 Normal          972  mV     	na
 R0          Stby Temp: DMB INormal          22   Celsius	(45 ,55 ,65 ,70 )(Celsius)
 R0          Stby Temp: DMB ONormal          32   Celsius	(70 ,75 ,80 ,85 )(Celsius)
 R0          Stby Temp: Yoda Normal          43   Celsius	(95 ,105,110,115)(Celsius)
 R0          Stby Temp: Yoda Normal          45   Celsius	(95 ,105,110,115)(Celsius)
 R0          Stby Temp: CPU DNormal          33   Celsius	(100,110,120,125)(Celsius)
 R0          Stby Temp: FC FAFan Speed 70%   22   Celsius	(29 ,39 ,0  )(Celsius)
 R0          Stby VDDC1: VX1 Normal          1005 mV     	na
 R0          Stby VDDC1: VX2 Normal          7070 mV     	na
 R0          Stby VDDC2: VX2 Normal          752  mV     	na
 R0          Stby VDDC2: VX3 Normal          750  mV     	na
 R0          Stby Temp: DDC INormal          22   Celsius	(55 ,65 ,75 ,80 )(Celsius)
 R0          Stby Temp: DDC ONormal          28   Celsius	(75 ,85 ,95 ,100)(Celsius)

（注）  

コマンドでは、アクティブとスタンバイの両方のハードウェアの詳細が表示されます。

（注）  

show environment summary コマンドでは、Cisco Catalyst 9800-80 ワイヤレス コントローラ、Cisco Catalyst 9800-40 ワイヤレス コントローラ、Cisco Catalyst 9800-L ワイヤレス コントローラ、スイッチ用 Cisco Catalyst 9800 組み込みワイヤレス コントローラなどの物理アプライアンスのデータのみが表示されます。コマンドでは、クラウド向け Cisco Catalyst 9800 ワイヤレス コントローラのデータは表示されません。

ゲートウェイモニタリング設定の確認

アクティブコントローラにおけるゲートウェイモニタリング設定のステータスを確認するには、次のコマンドを実行します。

Device# show redundancy states

my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = enabled
Communications = Up

client count = 129
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0
Gateway Monitoring = Disabled
Gateway monitoring interval = 8 secs

スタンバイコントローラにおけるゲートウェイモニタリング設定のステータスを確認するには、次のコマンドを実行します。

Device-stby# show redundancy states

my state = 8 -STANDBY HOT
peer state = 13 -ACTIVE
Mode = Duplex
Unit = Primary
Unit ID = 2

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Manual Swact = cannot be initiated from this the standby unit
Communications = Up

client count = 129
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0
Gateway Monitoring = Disabled
Gateway monitoring interval = 8 secs

RMI IPv4 設定の確認

RMI IPv4 設定を確認します。

Device# show running-config interface vlan management-vlan

Building configuration...

Current configuration : 109 bytes
!
interface Vlan90
ip address 9.10.90.147 255.255.255.0 secondary
ip address 9.10.90.41 255.255.255.0
end

スタンバイコントローラのインターフェイス設定を確認するには、次のコマンドを使用します。

Device-stby# show running-config interface vlan 90

Building configuration...
 
Current configuration : 62 bytes
!
interface Vlan90
ip address 9.10.90.149 255.255.255.0
end

アクティブコントローラにおけるシャーシのリダンダンシー マネジメント インターフェイスの設定を確認するには、次のコマンドを使用します。

Device# show chassis rmi

Chassis/Stack Mac Address : 000c.2964.1eb6 - Local Mac Address
Mac persistency wait time: Indefinite
			H/W Current
Chassis# Role      Mac Address     Priority  Version  State  IP             RMI-IP
--------------------------------------------------------------------------------------------------------
*1       Active    000c.2964.1eb6  1         V02      Ready  169.254.90.147 9.10.90.147
2        Standby   000c.2975.3aa6  1         V02      Ready  169.254.90.149 9.10.90.149

スタンバイコントローラにおけるシャーシのリダンダンシー マネジメント インターフェイスの設定を確認するには、次のコマンドを使用します。

Device-stby# show chassis rmi

Chassis/Stack Mac Address : 000c.2964.1eb6 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Chassis#   Role    Mac Address     Priority Version  State  IP              RMI-IP
------------------------------------------------------------------------------------------------
1         Active   000c.2964.1eb6     1      V02     Ready  169.254.90.147  9.10.90.147
*2        Standby  000c.2975.3aa6     1      V02     Ready  169.254.90.149  9.10.90.149

アクティブコントローラの ROMMON 変数を確認するには、次のコマンドを使用します。

Device# show romvar | include RMI

RMI_INTERFACE_NAME = Vlan90
RMI_CHASSIS_LOCAL_IP = 9.10.90.147
RMI_CHASSIS_REMOTE_IP = 9.10.90.149

スタンバイコントローラの ROMMON 変数を確認するには、次のコマンドを使用します。

Device-stby# show romvar | include RMI

RMI_INTERFACE_NAME = Vlan90
RMI_CHASSIS_LOCAL_IP = 9.10.90.149
RMI_CHASSIS_REMOTE_IP = 9.10.90.147

スイッチオーバーの理由を確認するには、次のコマンドを使用します。

Device# show redundancy switchover history

Index  Previous  Current  Switchover             Switchover
       active    active   reason                 time
-----  --------  -------  ----------             ----------
   1       2        1     Active lost GW         17:02:29 UTC Mon Feb 3 2020

RMI IPv6 設定の確認

アクティブコントローラとスタンバイコントローラ両方のシャーシのリダンダンシー マネジメント インターフェイス設定を確認するには、次のコマンドを実行します。

Device# show chassis rmi

Chassis/Stack Mac Address : 00a3.8e23.a540 - Local Mac Address
Mac persistency wait time: Indefinite
Local Redundancy Port Type: Twisted Pair
                                             H/W   Current
Chassis#   Role     Mac Address    Priority Version State     IP             RMI-IP
---------------------------------------------------------------------------------------------
  1        Standby  706d.1536.23c0    1      V02     Ready  169.254.254.17   2020:0:0:1::211
 *2        Active   00a3.8e23.a540    1      V02     Ready  169.254.254.18   2020:0:0:1::212

アクティブコントローラとスタンバイコントローラ両方の RMI 関連 ROMMON 変数を確認するには、次のコマンドを実行します。

Device# show romvar | i RMI

RMI_INTERFACE_NAME = Vlan52
RMI_CHASSIS_LOCAL_IPV6 = 2020:0:0:1::212
RMI_CHASSIS_REMOTE_IPV6 = 2020:0:0:1::211

冗長ポートインターフェイス設定の確認

アクティブインスタンスの冗長ポートインターフェイス（RIF）リソースのステータスを確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 resource-status
RIF Resource Status

    RP Status             : Up
    RMI Status            : Up
    Current Chassis State : Active
    Peer Chassis State    : Standby

スタンバイインスタンスの RIF リソースのステータスを確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 resource-status
RIF Resource Status

    RP Status             : Up
    RMI Status            : Up
    Current Chassis State : Standby
    Peer Chassis State    : Active

RMI リンクの再確立カウントと、アクティブインスタンスで RMI リンクがアップになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 rmi-connection-details
RMI Connection Details
    RMI Link re-establish count : 2
    RMI Link Uptime             : 21 hours 8 minutes 43 seconds
    RMI Link Upsince            : 08/05/2021 13:46:01

RMI リンクの再確立カウントと、アクティブインスタンスで RMI リンクがダウンになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 rmi-connection-details
RMI Connection Details
    RMI Link re-establish count : 1
    RMI Link Downtime           : 28 seconds
    RMI Link Downsince          : 07/16/2021 03:19:11

RMI リンクの再確立カウントと、スタンバイインスタンスで RMI リンクがアップになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 rmi-connection-details
RMI Connection Details
    RMI Link re-establish count : 1
    RMI Link Uptime             : 1 hour 39 minute 9 seconds
    RMI Link Upsince            : 07/16/2021 01:31:41

RMI リンクの再確立カウントと、スタンバイインスタンスで RMI リンクがダウンになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 rmi-connection-details
RMI Connection Details
    RMI Link re-establish count : 1
    RMI Link Downtime           : 22 seconds
    RMI Link Downsince          : 07/16/2021 03:19:17

RP リンクの再確立カウントと、アクティブインスタンスで RP リンクが数日間アップになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 rp-connection-details
RP Connection Details
    RP Connection Uptime  : 12 days 17 hours 1 minute 39 seconds
    RP Connection Upsince : 07/03/2021 07:06:20

RP リンクの再確立カウントと、アクティブインスタンスで RP リンクがダウンになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 rp-connection-details
RP Connection Details
    RP Connection Downtime     : 4 seconds
    RP Connection Downsince    : 07/16/2021 03:33:04

RP リンクの再確立カウントと、スタンバイインスタンスで RP リンクがアップになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 rp-connection-details
RP Connection Details
    RP Connection Uptime  : 12 days 17 hours 2 minutes 1 second
    RP Connection Upsince : 07/03/2021 07:05:58

RP リンクの再確立カウントと、スタンバイインスタンスで RP リンクがダウンになってからの時間を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 rp-connection-details
RP Connection Details
    RP Connection Downtime    : 22 seconds
    RP Connection Downsince   : 07/16/2021 03:19:17

アクティブインスタンスの RIF およびスタックマネージャの内部統計を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 rif-stk-internal-stats
RIF Stack Manager internal stats

    Stack-mgr reported RP down            : False
    DAD link status reported to Stack-Mgr : True

スタンバイインスタンスの RIF およびスタックマネージャの内部統計を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 rif-stk-internal-stats
RIF Stack Manager internal stats

    Stack-mgr reported RP down            : False
    DAD link status reported to Stack-Mgr : True

アクティブインスタンスでタイプごとに送受信されたパケット数を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis active R0 lmp-statistics
LMP Statistics

Info Type Sent                    : 6
Solicit Info Type Sent            : 0
Unsolicit Info Type Sent          : 6
Reload Type Sent                  : 0
Recovery Type Sent                : 1 
Gateway Info Type Sent            : 0
Enquiry Type Sent                 : 0
Solicit Enquiry Type Sent         : 0
Unsolicit Enquiry Type Sent       : 0 

Info Type Received                : 5
Solicit Info Type Received        : 2
Unsolicit Info Type Received      : 3
Reload Type Received              : 0
Recovery Type Received            : 0
Gateway Info Type Received        : 4
Enquiry Type Received             : 0
Solicit Enquiry Type Received     : 0
Unsolicit Enquiry Type Received   : 0

スタンバイインスタンスでタイプごとに送受信されたパケット数を確認するには、次のコマンドを実行します。

Device# show platform software rif-mgr chassis standby R0 lmp-statistics
LMP Statistics

Info Type Sent                   : 6
Solicit Info Type Sent           : 0
Unsolicit Info Type Sent         : 6
Reload Type Sent                 : 0
Recovery Type Sent               : 0
Gateway Info Type Sent           : 4
Enquiry Type Sent                : 0
Solicit Enquiry Type Sent        : 0
Unsolicit Enquiry Type Sent      : 0

Info Type Received               : 5
Solicit Info Type Received       : 3
Unsolicit Info Type Received     : 2
Reload Type Received             : 0
Recovery Type Received           : 1
Gateway Info Type Received       : 0
Enquiry Type Received            : 0
Solicit Enquiry Type Received    : 0
Unsolicit Enquiry Type Received  : 0

自動アップグレードについて

自動アップグレード機能により、スタンバイコントローラはアクティブコントローラのソフトウェアイメージを使用してアップグレードできるため、両方のコントローラがハイアベイラビリティ（HA）を形成できます。


（注）  

  • この機能は、インストールモードのアクティブコントローラをサポートします。

  • この機能は、Cisco Catalyst 9800 シリーズ ワイヤレス コントローラのソフトウェアバージョン 17.5.1 以降をサポートします。

  • この機能は、アクティブイメージがコミット状態の場合にのみ、スタンバイコントローラでトリガーされます。

使用例

自動アップグレード機能でサポートされる使用例と機能は次のとおりです。

  • ソフトウェアバージョンの不一致の処理：アップグレード中に、冗長性ポートの 1 つが新しいバージョンにアップグレードされ、別のポートが同時にアップグレードされない場合、アクティブポートは自動アップグレード機能を使用してパッケージを別のポートにコピーしようとします。この状況で自動アップグレードを有効にするには、設定を使用するか、software auto-upgrade enable 特権 EXEC コマンドを手動で実行します。

    自動アップグレードの設定はデフォルトでは有効になっています。


    （注）  

    自動アップグレードは、アクティブな冗長性ポートと不一致の冗長性ポートの両方が INSTALL モードの場合にのみ、不一致の冗長性ポートをアップグレードします。

  • HA ペア：コントローラの 1 つが正常にアップグレードされなかった場合は、自動アップグレードを使用して、新しく展開された HA ペアのコントローラをアップグレードします。この場合、それぞれのバージョンが異なる場合があります。

  • SMU（APSP、APDP など）：スタンバイコントローラがオフラインのときにアクティブコントローラに正常にインストールされた SMU の場合。このシナリオでは、スタンバイコントローラがオンラインになると、自動アップグレードによってこの SMU がスタンバイコントローラにコピーされ、インストールされます。

設定ワークフロー

自動アップグレードの設定（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

software auto-upgrade enable

例:

Device(config)# software auto-upgrade enable

自動アップグレード機能を有効にします。（この機能はデフォルトで有効になっています。）

このコマンドの no 形式を使用してこの機能を無効にした場合は、特権 EXEC モードで install autoupgrade コマンドを使用して、手動で自動アップグレードする必要があります。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

Link Layer Discovery Protocol（LLDP）の使用例

高可用性（HA）セットアップでは、2 つのワイヤレスユニットがアクティブとスタンバイとして機能する場合、LLDP は両方で独立して実行されます。

LLDP neighbors コマンドを実行すると、アップリンクスイッチのネイバーエントリとしてのシステム名が hostname-stbdy と表示されます。

LLDP の有効化（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

lldp run

例:

Device(config)# lldp run

Link Layer Discovery Protocol（LLDP）を有効にします。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

LLDP タイマーの有効化（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

lldp holdtime time_in_secs

例:

Device(config)# lldp holdtime 100

LLDP タイマーを有効にします。このタイマーは、受信者がパケットを保持する必要がある期間を決定します。有効な範囲は 0 ～ 65535 秒です。

ステップ 3

lldp reinit delay_in_secs

例:

Device(config)# lldp reinit 3

LLDP を初期化する際の遅延を秒単位で指定します。有効な範囲は 2 ～ 5 秒です。

ステップ 4

lldp timer time_in_secs

例:

Device(config)# lldp timer 7

LLDP パケットが送信されるレートを秒単位で指定します。有効な範囲は 5 ～ 65534 秒です。

ステップ 5

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

LLDP TLV 選択の有効化（CLI）

手順

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

Device# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 2

lldp tlv-select [mac-phy-cfg | management-address | port-description | port-vlan | system-capabilities | system-description]

例:

Device(config)# lldp tlv-select port-vlan

LLDP のタイプ、長さ、および値（TLV）の選択を有効にします。

  • mac-phy-cfg ：IEEE 802.3 MAC、物理構成、またはステータス TLV。

  • management-address ：管理アドレス TLV。

  • port-description ：ポート記述 TLV。

  • port-vlan ：ポート VLAN ID TLV。

  • system-capabilities ：システム機能 TLV。

  • system-description ：システム記述 TLV。

ステップ 3

end

例:

Device(config)# end

特権 EXEC モードに戻ります。

LLDP の確認

アクティブコントローラとスタンバイコントローラで LLDP の詳細を個別に表示するには、次の show コマンドを活用します。

アクティブコントローラとスタンバイコントローラのタイマーとステータスを確認するには、次のコマンドを使用します。

Device# show lldp
Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds

アクティブコントローラでネイバーの詳細を確認するには、次のコマンドを使用します。

Device# show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
9500-SW             Tw0/0/0        120        B,R             Twe1/0/14

スタンバイコントローラでネイバーの詳細を確認するには、次のコマンドを使用します。

Device# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
9500-SW             Tw0/0/0        120        B,R             Twe1/0/13
Total entries displayed: 1

LLDP ネイバー（TLV）の詳細を確認するには、次のコマンドを使用します。

Device# show lldp neighbors detail
------------------------------------------------
Local Intf: Te0/0/0
Chassis id: 2cd0.2d62.be80
Port id: Te1/1
Port Description: TenGigabitEthernet1/1
System Name: HSRP-ROUTER-1-15.cisco.com
 
System Description:
Cisco IOS Software, IOS-XE Software, Catalyst 4500 L3 Switch  Software (cat4500e-UNIVERSAL-M), Version 03.09.00.E RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Tue 19-Jul
 
Time remaining: 99 seconds
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses:
    IP: 8.109.0.1
    IPV6: 2001:12:1::2
Auto Negotiation - not supported
Physical media capabilities:
    Other/unknown
Media Attachment Unit type - not advertised
Vlan ID: 109
Peer Source MAC: 2cd0.2d62.be80

アップリンクスイッチの LLDP の詳細を確認するには、次のコマンドを使用します。

Device# show lldp neighbors detail
------------------------------------------------
Local Intf: Te1/1
Chassis id: d4e8.80b3.0420
Port id: Te0/0/0
Port Description: TenGigabitEthernet0/0/0
System Name: WLC-BGL15.cisco.com
 
System Description:
Cisco IOS Software [Bangalore], C9800 Software (C9800_IOSXE-K9), Experimental Version 17.9.20220630:200739
Copyright (c) 1986-2022 by Cisco Systems, Inc.
Compiled Thu 30-Jun-22 13:19
 
Time remaining: 107 seconds
System Capabilities: B,R
Enabled Capabilities: R
Management Addresses:
    IP: 8.109.0.47
    IPV6: FD09:8:109::45
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: 109

LLDP パケットエラーを確認するには、次のコマンドを使用します。

Device# show lldp errors
LLDP errors/overflows:
Total memory allocation failures: 0
Total encapsulation failures: 0
Total input queue overflows: 0
Total table overflows: 0

LLDP トラフィックの統計情報を確認するには、次のコマンドを使用します。

Device# show lldp traffic
LLDP traffic statistics:
Total frames out: 18470
Total entries aged: 0
Total frames in: 6156
Total frames received in error: 0
Total frames discarded: 0
Total TLVs discarded: 0
Total TLVs unrecognized: 0

リロード理由履歴の機能履歴

次の表に、このセクションで説明する機能のリリースおよび関連情報を示します。

この機能は、特に明記されていない限り、導入されたリリース以降のすべてのリリースでも使用できます。

表 7. リロード理由履歴の機能履歴

リリース

機能

機能情報

Cisco IOS XE Dublin 17.11.1

リロード理由履歴

リロード理由履歴機能は、コントローラのリロードの理由をトラッキングします。これは、過去 10 回のリロードに対して実行されます。

Cisco IOS-XE Dublin 17.10.x 以前のリリースでは、最後のリロードの理由のみがトラッキング可能でした。

リロード理由履歴について

リロード理由履歴機能は、コントローラのリロードの理由をトラッキングします。これは、直近の 10 回のリロードに対して実行されます。show version およびネットワーク設定プロトコル（NETCONF）を使用して履歴を表示できます。この履歴は、保守やトラブルシューティングに役立ちます。


（注）  

スタンバイコントローラをリロードすると、コントローラのハードディスクにシステムレポートファイルが生成されます。

リロード理由履歴の確認

リロード履歴の詳細を表示するには、次のコマンドを使用します。

Device# show reload-history

Reload History:

Reload Index: 1
Reload Code: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 01:33:44 UTC Wed Nov 30 2022

Reload Index: 2
Reload Code: Critical Process Fault
Reload Description: Critical process stack_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-012929-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 01:31:11 UTC Wed Nov 30 2022

Reload Index: 3
Reload Code: Image Install
Reload Description: Image Install 
Reload Severity: Normal Reboot
Reload Time: 01:25:03 UTC Wed Nov 30 2022

Reload Index: 4
Reload Code: Critical Process Fault
Reload Description: Critical process rif_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-011127-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 01:13:08 UTC Wed Nov 30 2022

Reload Index: 5
Reload Code: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 01:08:26 UTC Wed Nov 30 2022

Reload Index: 6
Reload Code: Critical Process Fault
Reload Description: Critical process wncmgrd fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-010338-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 01:05:23 UTC Wed Nov 30 2022

Reload Index: 7
Reload Code: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 01:01:09 UTC Wed Nov 30 2022

Reload Index: 8
Reload Code: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 00:57:27 UTC Wed Nov 30 2022

Reload Index: 9
Reload Code: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 00:22:34 UTC Wed Nov 30 2022

Reload Index: 10
Reload Code: Fast Switchover
Reload Description: redundancy force-switchover
Reload Severity: Normal Reboot
Reload Time: 23:40:01 UTC Tue Nov 29 2022

最後のリロードの理由を表示するには、次のコマンドを使用します。

Device# show platform software tdl-database content ios device data
Device Current time: 04:06:04
Device boot time: 01:33:37
Software version: Cisco IOS Software [Dublin], C9800-CL Software (C9800-CL-K9_IOSXE), Experimental Version 17.11.20221012:120806 [BLD_POLARIS_DEV_S2C_20221010_023625-1-g5ebdd5c35512:/nobackup/saikarth/polaris_relhis 103]
Copyright (c) 1986-2022 by Cisco Systems, Inc.
Compiled Wed 12-Oct-22 05:08 by saikarth
Rommon version: IOS-XE ROMMON
Last Reboot reason: Reload Command
Reboot reason severity: Normal Reboot
Unsaved configuration:  * Unknown boolean * 

Reload History:

Reload Category: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 01:33:44 UTC

Reload Category: Critical Process Fault
Reload Description: Critical process stack_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-012929-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 11/30/2022 01:31:11 UTC

Reload Category: Image Install
Reload Description: Image Install 
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 01:25:03 UTC

Reload Category: Critical Process Fault
Reload Description: Critical process rif_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-011127-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 11/30/2022 01:13:08 UTC

Reload Category: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 01:08:26 UTC

Reload Category: Critical Process Fault
Reload Description: Critical process wncmgrd fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-010338-UTC.tar.gz
Reload Severity: Abnormal Reboot
Reload Time: 11/30/2022 01:05:23 UTC

Reload Category: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 01:01:09 UTC
          
Reload Category: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 00:57:27 UTC
          
Reload Category: Reload
Reload Description: Reload Command
Reload Severity: Normal Reboot
Reload Time: 11/30/2022 00:22:34 UTC
          
Reload Category: Fast Switchover
Reload Description: redundancy force-switchover
Reload Severity: Normal Reboot
Reload Time: 11/29/2022 23:40:01 UTC

YANG を使用したリロード理由履歴の要求

YANG を NETCONF および RESTCONF で使用すると、自動化されたプログラム可能なネットワーク操作の望ましいソリューションが実現します。

次の RPC を使用して、リロード履歴データの NETCONF GET 要求を作成します。


<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:da15955f-5bb7-437c-aeb5-0fc7901a1e9e">
  <nc:get>
    <nc:filter>
      <device-hardware-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-device-hardware-oper">
        <device-hardware>
          <device-system-data>
            <reload-history/>
          </device-system-data>
        </device-hardware>
      </device-hardware-data>
    </nc:filter>
  </nc:get>
</nc:rpc> 

<rpc-reply message-id="urn:uuid:da15955f-5bb7-437c-aeb5-0fc7901a1e9e" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <device-hardware-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-device-hardware-oper">
      <device-hardware>
        <device-system-data>
          <reload-history>
            <rl-history>
              <reload-category>rc-rld</reload-category>
              <reload-desc>Reload Command</reload-desc>
              <reload-time>2022-11-30T01:33:44+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-crit-proc-fault</reload-category>
              <reload-desc>Critical process stack_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-012929-UTC.tar.gz</reload-desc>
              <reload-time>2022-11-30T01:31:11+00:00</reload-time>
              <reload-severity>abnormal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-img-install</reload-category>
              <reload-desc>Image Install </reload-desc>
              <reload-time>2022-11-30T01:25:03+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-crit-proc-fault</reload-category>
              <reload-desc>Critical process rif_mgr fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-011127-UTC.tar.gz</reload-desc>
              <reload-time>2022-11-30T01:13:08+00:00</reload-time>
              <reload-severity>abnormal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-rld</reload-category>
              <reload-desc>Reload Command</reload-desc>
              <reload-time>2022-11-30T01:08:26+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-crit-proc-fault</reload-category>
              <reload-desc>Critical process wncmgrd fault on rp_0_0 (rc=137), system report at bootflash:core/Yang_Test-system-report_20221130-010338-UTC.tar.gz</reload-desc>
              <reload-time>2022-11-30T01:05:23+00:00</reload-time>
              <reload-severity>abnormal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-rld</reload-category>
              <reload-desc>Reload Command</reload-desc>
              <reload-time>2022-11-30T01:01:09+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-rld</reload-category>
              <reload-desc>Reload Command</reload-desc>
              <reload-time>2022-11-30T00:57:27+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-rld</reload-category>
              <reload-desc>Reload Command</reload-desc>
              <reload-time>2022-11-30T00:22:34+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
            <rl-history>
              <reload-category>rc-force-switchover</reload-category>
              <reload-desc>redundancy force-switchover</reload-desc>
              <reload-time>2022-11-29T23:40:01+00:00</reload-time>
              <reload-severity>normal</reload-severity>
            </rl-history>
          </reload-history>
        </device-system-data>
      </device-hardware>
    </device-hardware-data>
  </data>
</rpc-reply>

YANG モデルの詳細については、次のドキュメントを参照してください。https://www.cisco.com/c/en/us/support/wireless/catalyst-9800-series-wireless-controllers/products-installation-and-configuration-guides-list.html にある『Cisco IOS XE Programmability Configuration Guide』

https://github.com/YangModels/yang/tree/main/vendor/cisco/xe にある Github の YANG データモデル。

次の URL から、NETCONF および YANG 機能の開発者のサポートコミュニティに問い合わせます。

https://developer.cisco.com/