バーチャルMACアドレス機能の有効化は、stack virtual-macコマンドで行います。
バーチャルMACアドレス機能は初期設定では無効ですが、VCS使用時は必ずバーチャルMACアドレス機能を有効にした状態で運用してください。無効状態での運用はサポート対象外となります。
なお、同一ネットワーク上に複数のVCSグループが存在する場合は、バーチャルMACアドレスの下位12ビットとして使用されるバーチャルシャーシIDを、該当するVCSグループ間で重複しないように設定してください。バーチャルシャーシIDの設定は、stack virtual-chassis-idコマンドで行います。また、VCSグループのバーチャルシャーシIDは、show stackコマンドをdetailオプション付きで実行したときに表示される「Virtual Chassis ID」欄で確認できます。
VCSマスター・スレーブ間において、メンテナンスバージョン間（5.4.9-2.1から5.4.9-2.2など）のファームウェア自動同期が可能です。(メジャーバージョン、マイナーバージョンが異なるファームウェア間の同期は未サポート)
フィーチャーライセンスの対象機能を使用する場合は、すべてのメンバーで同一のライセンスを有効化してください。
なお、フィーチャーライセンスが適用された機器でVCS 構成を利用する場合は、各VCSメンバーに同一の「License issue date」を持つフィーチャーライセンスがインストールされている必要があります。
各VCSメンバー間でフィーチャーライセンスの「License issue date」が異なる場合には、ライセンスパスワードを更新する必要がありますので、弊社窓口までご連絡ください。フィーチャーライセンスの「License issue date」は、show licenseコマンドでご確認いただけます。
VCS構成時にアニュアルライセンスを適用する場合は、VCSスレーブ含む全メンバーのライセンスファイルをVCSマスター側に転送した上で、ライセンスファイルごとにlicense update fileコマンドを実行してください。
コマンド入力による設定変更はただちにVCSグループの動作に反映されます。未保存のままマスターが切り替わっても、新マスターは設定変更後のコンフィグで起動しますが、設定変更後はただちにコンフィグを保存することを推奨します。
NoteスレーブメンバーがVCSグループに加入しようとしているときにコンフィグを変更すると、再加入したスレーブメンバーにコンフィグが反映されないことがあります。スレーブメンバーが加入中に設定の変更はしないでください。
マスターに新たにファイルが作成された場合、VCSグループのメンバーにファイルがコピーされますが、スレーブメンバーのフラッシュメモリーに充分な空きがない場合は、ファイルがコピーされません。この際、ファームウェアのイメージファイルやJavaアプレットファイルが未保存のままマスターが切り替わると、ファームウェアのアップデートやWeb GUIの表示が行われません。これを避けるため、大容量のファイルをインストールする場合は、各メンバーの空き領域を確認し、空き領域が不足している場合は不要なファイルを削除するなどして、充分な空き領域を確保するようにしてください。
| コンフィグファイル | ○ ※1 | |
| スクリプトファイル | ○ | |
| テキストファイル | × ※2 | |
| HTMLファイル | × ※2 | |
| cssファイル | × ※2 | |
| GIFファイル | × ※2 | |
| Javaアプレットファイル | ○ | |
| リモートSSHユーザーの公開鍵 | × ※2 | |
| ルートCA証明書（ローカルRadius） | ○ | |
| ユーザ証明書（ローカルRadius） | ○ | |
| ローカルユーザパスワードファイル | ○ | |
| DHCPリース関連ファイル | ○ | |
| DHCPリースバックアップファイル | ○ | |
| GUIファイル | ○ | |
| GUIファイル | ○ |
※2 ファイルをマスターからメンバーに移行させる、または障害機から退避させる必要があります。
VCS構成時、VCSグループに設定するVLANの数は2000個以内にしてください。
VCSグループをEPSRマスターノードに設定した場合、epsrコマンドのfailovertimeパラメーターを使用して、EPSRマスターノードが送出するHealthcheckメッセージのタイムアウト時間を5秒に設定してください。
DHCPサーバー機能を有効にしIPアドレスをリースしている状態で、マスター切り替えが発生すると、DHCPサーバー機能も再起動され、リース中のIP アドレスのリースタイムが更新されます。
VCSと認証の併用時、トランクグループが認証ポートとして動作している場合、スレーブがVCSグループに参加すると、全Supplicantの認証は解除されます。
VCSのマスター切り替えが発生しても、Supplicantの認証情報は保持されますが、スレーブがVCSグループに参加すると、認証は解除されます。
VCS構成でトリガーを使用する場合は、次の点にご注意ください。
- マスター切り替え時、新マスターではスタックマスターフェイルトリガー、スタックメンバートリガー（leave）の両方が起動されます。
- スタックリンク障害によってスレーブがポートをリンクダウンしたとき（VCSグループが分断されたとき）、マスターではスタックメンバートリガー（leave）が起動されます。また、スレーブではスタックマスターフェイルトリガーとスタックメンバートリガー（leave）の両方が起動されます。
- スタックリンクトリガーは、2つあるスタックポートのうち、どちらか一方のリンクステータスが変化すれば起動されます。
VCS構成でSSHサーバー機能の公開鍵認証を使用する場合は、あらかじめ同一VCSグループを構成するすべてのスタックメンバーにSSHのユーザー公開鍵を登録しておいてください（任意のスタックメンバーにログインするには、remote-loginコマンドを使います。また、ユーザー公開鍵の登録はcrypto key pubkey-chain userkeyコマンドで行います）。マスターにだけユーザー公開鍵が登録されている状態でマスター切り替えが発生すると、新マスターにはユーザー公開鍵の情報が存在しない状態となり、公開鍵によるSSHログインができなくなります。
VCS構成でlinkUp/linkDownトラップを有効にしている場合、両方のスタックモジュール・ケーブルに障害が発生すると、スレーブメンバーがマスター側スイッチポートの不在を検知し、マスター側スイッチポートのlinkDownトラップを送信します。このとき、マスター側スイッチポートやVLANインターフェースは実際にはダウンしていないので、上位のプロトコルや通信に影響を与えることはありません。
VCS構成でEPSR-SLP機能を使用する場合は、次の点にご注意ください。
なお、以下の説明では、EPSRのリング接続用ポートのうち、複数のEPSRドメインに所属している共有ポートを「Common Link」と呼びます。
- Common Linkを持つノードがVCS構成の場合、マスターノードでfailovertimeを5秒に設定してください（epsrコマンドのfailovertimeパラメーターで設定）。
- Common Linkを持つノードがVCS構成の場合、次図のように通常のリング接続用ポート（同 (N)）では、MasterとSlaveをまたぐトランクグループで設定してください。Common Link（図の(C)）は単一ポートでも構いません。
- Common Linkを持つノードがVCS構成であり、かつリング接続用ポートとしてトランクグループではなく単一ポートを使用している場合、スタックリンクがダウンすると1秒未満のループが発生することがあります。
OSPFv2/v3 と併用する場合、グレースフルリスタートは有効（初期設定）にしてください。
同一VCSグループにPoE対応機種（AT-x930-28GPX, AT-x930-52GPX）と非対応機種（AT-x930-28GTX, AT-x930-52GTX, AT-x930-28GSTX）を混在させる場合は、次の点にご注意ください。
- PoE非対応機種がマスターになっている状態でCLIから設定を保存すると、コンフィグファイルに「service power-inline」が入りません。この状態でPoE対応機種が後からVCSグループに加入（ジョイン）すると、PoE関連コマンドが有効になりません。PoE対応機種と非対応機種を混在させる場合は、VCSグループで使用するスタートアップコンフィグにservice power-inlineが記述されているかどうかを確認し、記述されていない場合は同コマンドを実行した上で設定を保存しなおしてください（PoE非対応機種がマスターのときでも同コマンドの実行は可能です）。
VCS構成において、CLIからプライベートVLANの設定をダイナミックに行った場合は、設定を保存して再起動してください。
メンバー3台以上のVCS構成では、マルチキャストドメイン境界ルーター機能（ip multicast-routing borderコマンド）を使用しないでください。
VCS構成において、auth supplicant-macコマンドのport-controlパラメーターで特定Supplicantの認証状態を「認証済み」（force-authorized）あるいは「未認証」（force-unauthorized）に固定設定している場合、VCSマスターがダウンすると該当Supplicantの認証状態の表示がそれぞれ次のようになりますが、通信への影響はありません。また、ダウンした旧マスターがVCSグループに復帰（ジョイン）すると正しい表示に戻ります。
| Force-Authorized | Authenticated |
| Force-Unauthorized | Down |
VCS構成時、スレーブに接続したコンソールターミナルからのCLIログイン時には、RADIUSサーバーを用いたログイン認証ができません（ユーザー認証データベースによる認証は可能です）。
VCS構成時やスタックメンバー参加時に access-groupコマンドが多数設定されていると（例: 複数ポートに大量のaccess-groupコマンドを設定している)、以下のログメッセージが出力される場合があります。
Failed to send ATL CPG msg (udt_data 0) - result -23この場合、スタックメンバーに一部のハードウェアパケットフィルターが適用されていないため、ハードウェアアクセスリスト（シーケンス番号対応）などを利用して、各スイッチポートに適用するaccess-groupコマンドの行数を減らしてください。
以下の制限事項はVCS構成時に限定されるものではありませんが、とりわけVCS構成において大きな意味を持ちますので、あらためてここに記載します。
- 複数のスイッチチップ（インスタンス）にまたがるトランクグループ（スタティック・LACPとも）では、QoSのメータリングが動作しません。複数インスタンスにまたがるトランクグループに対しては、メータリング（ポリサー）設定（police single-rateコマンド、police twin-rateコマンド）を含むポリシーマップを適用しないでください（適用してもメータリングが動作しません）。
VCS構成で一般的に使用されるマスター・スレーブにまたがったポートトランキングの構成はこのケースにあたりますのでご注意ください。
