こんにちは。TEと申します。
　
　今回は、Catalyst9100シリーズ（EWC-AP）の冗長化についてご紹介させて頂きます。

　EWC-APは、仮想コントローラによる集中管理型のソリューションであるため、仮想コントローラに障害が発生すると、電波の自動管理機能をはじめ集中管理の機能は停止してしまいます。しかしながら、EWC-APが同じネットワーク内に複数存在するネットワークでは、特別な設定をしなくても自動的にコントローラが冗長化されるため、集中管理機能が損なわれることは、ほとんどないかと思います。

　まずは、EWC-APの冗長化のプロセスについてです。
　EWC-APの冗長化プロセスとしては、同じネットワーク内にEWCモードで動作中のアクセスポイントが複数台存在する場合、まず仮想コントローラ機能を提供するアクセスポイント(Active AP)が1台選出されます。
　次にActive APは、その他の全てのEWCモードのアクセスポイントに優先順位の割り当てを行います。
　そして、一番優先順位が高いアクセスポイントからバックアップ用コントローラの役割を担うStandby APが1台選出されます。

　注意点としまして、EWC非対応のAironetシリーズのAP2802やAP1815などがActive APやStandby APに選出される事はありません。また、Catalyst9100シリーズやEWC型番であってもCAPWAPモードで動作中のアクセスポイントが選出されることも無いため、仮想コントローラとして動作させたいAPは、EWCモードで動作させておく必要があります。
※CAPWAPモードやEWCモードについては、こちらの記事をご参照ください。

　Active APの選出やStandby APの優先順位の割り当てルールについては、下記の通りとなっておりますので、参考にして頂ければと思います。
　これらのルールはあくまでも同時に起動したEWC-APの場合です。
　1台だけEWC-APの起動タイミングが少し早かった場合などは、ルール通りとはならず、型番が小さいモデルがアクティブAPとして選定されることがあります。そして、一度でもActive APになってしまうと手動での設定変更や障害が発生しない限り、Active APが切り替わることはありません。
　その為、例えばAPが51台〜100台存在する環境で最大AP管理台数が50台の9105や9115などのAPが誤ってActive APとなってしまうと一部のAPを管理することが出来なくなります。
　ルールでは、型番が大きいモデルがActive APとなりますが、こういったトラブルを避けるためにも、Active APにさせたくないAP（今回のケースでは、9105や9115）は、あらかじめCAPWAPモードに設定しておくことを個人的には推奨しております。

　今回は以上となります。
　次回は、Active APで障害が発生した場合のプロセスや手動でActive APやStandby APを指定する方法についてご紹介します。