バーチャルシャーシスタック（VCS） / 運用

メンバー4台でVCSグループを構成する。メンバーIDは1、2、3、4とする。
各メンバーのプライオリティーは、ID=1を最優先の32とし、ID=2を2番手の64、ID=3を3番手の96、ID=4を4番手の128に設定する。これにより、初期状態ではID=1がマスターになる。
スタックリンクは、ID=1のスタックポート1をID=2のスタックポート2に接続、ID=2のスタックポート1をID=3のスタックポート2に接続、ID=3のスタックポート1をID=4のスタックポート2に接続、ID=4のスタックポート1にID=1のスタックポート2を接続したリング構成とする。
レジリエンシーリンク（RL）の接続には、各メンバーの本体スイッチポート1と2を使う。接続順序はスタックリンクと同じで、ID=1のスイッチポート1をID=2のスイッチポート2に接続、ID=2のスイッチポート1をID=3のスイッチポート2に接続、ID=3のスイッチポート1をID=4のスイッチポート2に接続、ID=4のスイッチポート1にID=1のスイッチポート2を接続したリング構成とする。
表中の「Pri」はプライオリティー、「RL 1」、「RL 2」は「レジリエンシーリンク用スイッチポート1」、「レジリエンシーリンク用スイッチポート2」を示す。「1（S1）」はSFP+スロットLEDの「S1 L/A」およびQSFP+スロットLEDの「1」、「2（S2）」はSFP+スロットLEDの「S2 L/A」およびQSFP+スロットLEDの「2」を示す。また、「緑」は「緑点灯」、「×」は「消灯」を示す。
AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/I、AT-QSFPSR、AT-QSFPLR4を使用しており、レジリエンシーリンクを使用していない場合、ポートLED「RL1」、「RL2」の表示は意味を持たない。

基本的な考え方

マスターの確認

どのメンバーがマスターとして動作しているかを確認します。CLIコマンドによってスタックメンバーの役割を確認するか、LED ON/OFFボタンによってLED OFF（エコLED）に設定することで確認します。エコLED設定時にはステータスLED（LED ON設定時にスタックメンバーIDが表示されている場所）の横3セグメントに、マスターであれば上側のライン"￣"、スレーブであれば下側のライン"＿"が点灯します。知らないうちにマスターのメンバーが変わっていたら、何らかの障害によりマスター切り替えが起きたと推測できます。また、マスターが 2 つ以上存在している場合は、スタックリンク障害の可能性があります。SFP+スロットのS1 L/A、S2 L/AやQSFP+スロットの1、2でスタックリンクが分断されていないか確認するとよいでしょう。

スタックリンク

SFP+スロットのS1 L/A、S2 L/AやQSFP+スロットの1、2で各メンバー間のスタックリンクが正常かどうか確認します。4台構成なら、各メンバー2ポートずつ、合計8ポートのLEDがすべて緑点滅しているのが正常です。1つでも消灯していたら、その部分のリンクに障害が発生しています。物理的に接続されているのに LED が消灯している場合はケーブルかモジュールの障害が考えられます。スタックリンク障害時は、まずはケーブルを交換してみるのがよいでしょう。

レジリエンシーリンク

レジリエンシーリンク用に設定したマネージメントポート（eth0）またはスイッチポートのポートLED でレジリエンシーリンクが正常かどうか確認します。4台構成なら、各メンバー2ポートずつ、合計8ポートのLEDがすべて緑点滅しているのが正常です。1つでも消灯していたら、その部分のリンクに障害が発生しています。物理的に接続されているのに LED が消灯している場合はケーブルかスイッチポートの障害が考えられます。まずはケーブルを交換してみて、それでもだめなら CLI でレジリエンシーリンクのポートを変更するのがよいでしょう。

初期状態

初期状態では、ID=1がマスターとなり、残りのメンバーがスレーブとなります。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター緑緑緑緑緑緑

2 64 スレーブ緑緑緑緑緑緑

3 96 スレーブ緑緑緑緑緑緑

4 128 スレーブ緑緑緑緑緑緑

Note - AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/I、AT-QSFPSR、AT-QSFPLR4を使用しており、レジリエンシーリンクを使用していない場合、ポートLEDの表示はVCSグループの運用状態を確認する上では意味を持ちません（以下同じです）。

マスター障害

マスターが何らかの原因でダウンすると、次点のプライオリティーを持つスレーブメンバーが新マスターに昇格します。
たとえば、初期状態でマスターとして動作していたID=1がダウンすると、2番目にプライオリティーの高いID=2が新マスターに昇格します。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 ダウン × × × × × ×

2 64 マスター緑 × 緑緑 × ×

3 96 スレーブ緑緑緑緑緑緑

4 128 スレーブ × 緑 × × 緑緑

ID=1がダウン後に再起動してきた場合は、マスターではなくスレーブとしてVCSグループに復帰します。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 スレーブ緑緑緑緑緑緑

2 64 マスター緑緑緑緑緑緑

3 96 スレーブ緑緑緑緑緑緑

4 128 スレーブ緑緑緑緑緑緑

スレーブ障害

スレーブ1台がダウンした場合は、ダウンしたスレーブ上のポートが使えなくなりますが、VCSグループ全体の状態は変化しません。
たとえば、スレーブとして動作していたID=2がダウンすると、次のようにID=1がマスター、ID=3、4がスレーブという状態のままVCSグループは動作し続けます。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター × 緑 × × 緑緑

2 64 ダウン × × × × × ×

3 96 スレーブ緑 × 緑緑 × ×

4 128 スレーブ緑緑緑緑緑緑

ID=2がダウン後に再起動してきた場合は、再びスレーブとしてVCSグループに復帰します。

これは初期状態と同じ。したがって、このときのLED表示も次のように初期状態と同じになります。

スタックリンク障害（1箇所）

スタックリンクをリング状に接続している場合、スタックリンクが1箇所ダウンしても、VCSグループ全体の状態は変化しません。
たとえば、ID=1、2間のスタックリンクがダウンすると次のような構成になりますが、ID=1がマスター、ID=2、3、4がスレーブという状態のままVCSグループは動作し続けます。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター × 緑緑緑緑緑

2 64 スレーブ緑 × 緑緑緑緑

3 96 スレーブ緑緑緑緑緑緑

4 128 スレーブ緑緑緑緑緑緑

スタックリンクが1箇所だけダウンした場合、もっとも可能性が高いのはスタックケーブルの問題です。この場合は問題のあるケーブルを交換するだけで、VCSグループが元の構成に戻ります。

スタックリンク障害（2箇所以上）

スタックリンクをリング状に接続している場合でも、スタックリンクが2箇所以上ダウンするとVCSグループが分断されてしまいます。
ただし、VCSグループが分断されても、レジリエンシーリンクを使用している場合はマスターの存在を確認できるため、マスターとスタックリンク的に切り離されてしまったスレーブは、スイッチポートを無効化し、次点のスレーブがDisabled Master（DM）状態に移行します。
一方、レジリエンシーリンクを使用していない構成（AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/I、AT-QSFPSR、AT-QSFPLR4使用時のみサポート）でVCSグループが分断されると、マスターからスタックリンク的に切り離されてしまったスレーブの1台がマスターに昇格し、ネットワーク上に複数のマスターが存在する状態となります。

メンバーが1対3に分断された例

レジリエンシーリンクありの構成において、ID=1、2間とID=1、4間のスタックリンクがダウンすると次のような構成になります。このとき、ID=1はマスターのまま動作し続けますが、ID=1とのスタックリンク経由の接続を失ったID=2はスレーブ（Backup Member）からDisabled Master状態に移行し、レジリエンシーリンクとスタックリンク以外のポートを無効化します。ID=3、4はID=2のスレーブ（Backup Member）として同じようにポートの無効化を行います。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター × × 緑緑緑緑

2 64 ポート無効化緑 × 緑緑緑緑

3 96 ポート無効化緑緑緑緑緑緑

4 128 ポート無効化 × 緑緑緑緑緑

一方、レジリエンシーリンクなしの構成で、ID=1、2間とID=1、4間のスタックリンクがダウンすると次のような構成になります。このとき、ID=1はマスターのまま動作し続けますが、ID=1とのスタックリンク経由の接続を失ったID=2、3、4も、最も高いプライオリティーを持つID=2をマスターとして新たなVCSグループを構成するため、ネットワーク上にマスターが2台存在することとなります。ネットワーク構成にもよりますが、この状態では正常な通信ができなくなる可能性が高くなります。また、この状態からの自動復旧はできないため、ID=2、ID=3、ID=4の電源を切り、ID=1、ID=2間とID=1、ID=4間のスタックリンクの接続性を確認後、ID=2、ID=3、ID=4を再起動してください。これを回避するには、AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/I、AT-QSFPSR、AT-QSFPLR4使用時でもレジリエンシーリンクを使用してください。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター × × × × × ×

2 64 マスター緑 × × × × ×

3 96 スレーブ緑緑 × × × ×

4 128 スレーブ × 緑 × × × ×

復旧時は、複数のマスターが存在する状態になり、通常のマスター選出と同じ手順でアクティブマスターを選出し、それ以外のメンバーすべてで再起動が発生します。これはレジリエンシーリンクの有無に関係なく、同じ動作になります。

同一メンバー上のスタックリンクが両方ともダウンした場合は機器のスタックポート、スタックモジュール、スタックケーブルなどに問題が発生している可能性があります。

メンバーが2対2に分断された例

レジリエンシーリンクありの構成において、ID=1、4間とID=2、3間のスタックリンクがダウンすると次のような構成になります。このとき、ID=1はマスター、ID=2はスレーブのまま動作し続けますが、ID=1とのスタックリンク経由の接続を失ったID=3はスレーブ（Backup Member）からDisabled Master状態に移行し、レジリエンシーリンクとスタックリンク以外のポートを無効化します。ID=4はID=3のスレーブ（Backup Member）として同じようにポートの無効化を行います。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター緑 × 緑緑緑緑

2 64 スレーブ × 緑緑緑緑緑

3 96 ポート無効化緑 × 緑緑緑緑

4 128 ポート無効化 × 緑緑緑緑緑

一方、レジリエンシーリンクなしの構成で、ID=1、4間とID=2、3間のスタックリンクがダウンすると次のような構成になります。このとき、ID=1はマスター、ID=2はスレーブのまま動作し続けますが、ID=1、2とのスタックリンク経由の接続を失ったID=3、4も、最も高いプライオリティーを持つID=3をマスターとして新たなVCSグループを構成するため、ネットワーク上にマスターが2台存在することとなります。ネットワーク構成にもよりますが、この状態では正常な通信ができなくなる可能性が高くなります。また、この状態からの自動復旧はできないため、ID=3、ID=4の電源を切り、ID=1、ID=4 間とID=2、ID=3間のスタックリンクの接続性を確認後、ID=3、ID=4を再起動してください。これを回避するには、AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/I、AT-QSFPSR、AT-QSFPLR4使用時でもレジリエンシーリンクを使用してください。

このとき、LED表示は次のようになります。

メンバー スタックLED ポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター緑 × × × × ×

2 64 スレーブ × 緑 × × × ×

3 96 マスター緑 × × × × ×

4 128 スレーブ × 緑 × × × ×

復旧時は、複数のマスターが存在する状態になり、通常のマスター選出と同じ手順でアクティブマスターを選出し、それ以外のメンバーすべてで再起動が発生します。これはレジリエンシーリンクの有無に関係なく、同じ動作になります。

このように異なるメンバー上のスタックリンクが2箇所以上ダウンする確率は非常に低いはずですが、もし発生した場合、もっとも可能性が高いのはスタックケーブルの問題です。この場合はケーブルを交換するだけで、VCSグループが元の構成に戻ります。

レジリエンシーリンク障害

レジリエンシーリンクに障害が発生しても、VCSグループの動作に直接的な影響はありません。しかし、レジリエンシーリンクが2箇所以上ダウンした場合は、そのままではスタックリンク障害の発生時にスレーブがマスターの存在を確認できず、複数のスイッチがマスターとして動作してしまう可能性がありますので、なるべく早めにイーサネットケーブルの交換やレジリエンシーリンク用スイッチポートの変更などを行ってください。
たとえば、ID=1、4間とID=2、3間のレジリエンシーリンクがダウンした場合、VCSグループの構成は次のように初期状態のまま変わりません。

このとき、LED表示は次のようになります。

メンバー SFP+スロットLED/QSFP+スロットLED ポートLED/マネージメントポートLED

RL 1 RL 2

ID Pri 状態 1（S1） 2（S2） L/A DPX L/A DPX

1 32 マスター緑緑緑緑 × ×

2 64 スレーブ緑緑 × × 緑緑

3 96 スレーブ緑緑緑緑 × ×

4 128 スレーブ緑緑 × × 緑緑

このように異なるメンバー上のレジリエンシーリンクが2箇所以上ダウンする確率は非常に低いはずですが、もし発生した場合、もっとも可能性が高いのはイーサネットケーブルの問題です。この場合はケーブルを交換するだけでレジリエンシーリンクが復旧します。

VCSグループ運用中のメンテナンス作業

メンバーの追加

ここでは例として、次の3台構成にID=4、プライオリティー80のメンバーを追加することを考えます。追加場所はID=1、3間です。

追加するスイッチ（以下「新メンバー」とします）を単体起動し、ファームウェアバージョン統一などの初期設定を行い、いったん電源を切ります（導入編のスタックメンバーの初期設定を参照）。
新メンバーにスタックモジュールを取り付け、スタックケーブルは接続せずに起動します。

新メンバーのスタックメンバーIDとプライオリティーをそれぞれ「4」と「80」に設定します。最初にshow stackコマンドを実行して、現在のIDとプライオリティーを確認します。この例ではID=8、プライオリティー128（初期値）に設定されていることがわかります。

awplus> show stack ↓ Virtual Chassis Stacking summary information ID Pending ID MAC address Priority Status Role 8 - 0015.77ad.f818 128 Ready Active Master Operational Status Standalone unit Stack MAC address 0015.77ad.f818

スタックメンバーIDを変更するには、stack renumberコマンドを使って次のようにします。

awplus> enable ↓ awplus# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. awplus(config)# stack 8 renumber 4 ↓ Warning: the new ID will not become effective until the stack-member reboots. Warning: the boot configuration may now be invalid.

新しいスタックメンバーIDを有効にするため、reloadコマンドかrebootコマンドで新メンバーをいったん再起動します（再起動の前に設定を保存する必要はありません）。
awplus(config)# end ↓ awplus# reload ↓ reboot system? (y/n): y ↓

再起動後にログインしたら、もう一度show stackコマンドを実行して、現在のIDとプライオリティーを確認します。この例ではIDが4に変更されているのがわかります。

awplus> show stack ↓ Virtual Chassis Stacking summary information ID Pending ID MAC address Priority Status Role 4 - 0015.77ad.f818 128 Ready Active Master Operational Status Standalone unit Stack MAC address 0015.77ad.f818

次にプライオリティーを変更します。これは、stack priorityコマンドを使います。

awplus> enable ↓ awplus# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. awplus(config)# stack 4 priority 80 ↓

再度show stackコマンドを実行して、現在のIDとプライオリティーを確認します。これでID=4、プライオリティー80と希望の状態になりました。

awplus> show stack ↓ Virtual Chassis Stacking summary information ID Pending ID MAC address Priority Status Role 4 - 0015.77ad.f818 80 Ready Active Master Operational Status Standalone unit Stack MAC address 0015.77ad.f818

以下のコマンドを用いてスイッチチップに対する設定やVCSに関する設定を変更している場合は、運用中のマスタースイッチと同一に設定します。

Note - 同一ネットワーク上に複数のVCSグループが存在するときは、該当するVCSグループ間でバーチャルシャーシID（stack virtual-chassis-id）が重複しないよう注意して設定してください。バーチャルシャーシIDは、show stackコマンドをdetailオプション付きで実行したときに表示される「Virtual Chassis ID」欄で確認できます。

Note - VCS使用時はバーチャルMACアドレス機能の有効化（stack virtual-mac）が必須です。

Note - 上記コマンド以外にも設定変更時に以下のメッセージが表示されるコマンドにつきましても同様に運用中のマスタースイッチと同一に設定してください。

% The device needs to be restarted for this change to take effect.

以下の例では、VCS管理用VLAN 4000, VCS管理用サブネットアドレス 172.21.255.64、バーチャルシャーシID 127（0x07f）と仮定しています。

awplus> enable ↓ awplus# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. awplus(config)# stack management vlan 4000 ↓ awplus(config)# stack management subnet 172.21.255.64 ↓ awplus(config)# stack virtual-mac ↓ awplus(config)# stack virtual-chassis-id 127 ↓

設定内容を確認し、スタートアップコンフィグに保存します。

awplus(config)# end ↓ awplus# show running-config ↓ ...（表示されるコンフィグに問題がないことを確認） ... awplus# copy running-config startup-config ↓ This will lose configuration for non-existent stack members, continue? (y/n): y Building configuration... [OK]

新メンバーの電源を切ります。
ID=1（マスター）、ID=3（スレーブ）間を接続しているスタックケーブルを取り外し、ID=1（マスター）とID=4（新メンバー）、ID=3（スレーブ）とID=4（新メンバー）をスタックケーブルで接続して、新メンバーの電源を入れます。これにより、新メンバーはスレーブとしてVCSグループに加わります。

Note - 新メンバーの電源は切った状態でスタックケーブルを接続してください。電源オンの状態でVCSグループに接続するとマスター重複の状態となり、プライオリティーの低い機器でリブートが発生します。
レジリエンシーリンクの設定と接続をします。
（AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/Iを使用しており、レジリエンシーリンクを使わない場合、本手順は不要です）
- ID=4に対してレジリエンシーリンクの設定を行います。ここでは、ポート1と2（4.0.1と4.0.2）をレジリエンシーリンク用に使うものとします。
  vcg(config)# interface port4.0.1-4.0.2 ↓ vcg(config-if)# switchport resiliencylink ↓
- ID=3・4間、および、ID=4・1間のレジリエンシーリンク用スイッチポートをイーサネットケーブルで接続します。

設定内容を確認し、スタートアップコンフィグに保存します。

vcg(config)# end ↓ vcg# show running-config ↓ ...（表示されるコンフィグに問題がないことを確認） ... vcg# copy running-config startup-config ↓ Building configuration... [OK] VCS synchronizing file across the stack, please wait.. File synchronization with stack member-2 successfully completed File synchronization with stack member-3 successfully completed File synchronization with stack member-4 successfully completed [DONE]

新メンバー追加後の構成は次のようになります。

運用中のVCSグループにメンバーを追加した場合、新メンバーはつねにスレーブとしてグループに加入します（既存メンバーよりもプライオリティー値が小さくてもマスターにはなりません）。新メンバーをマスターとして動作させたいときは、VCSグループを再起動してください。

メンバーの取り外し

ここでは例として、次の4台構成からID=4のメンバーを取り外すことを考えます。

取り外すスイッチの電源を切ります。
ID=1（マスター）、ID=4（取り外すスイッチ）間、ID=3（スレーブ）、ID=4（取り外すスイッチ）間を接続しているスタックケーブルを取り外し、ID=1（マスター）とID=3（スレーブ）間をスタックケーブルで接続します。これにより、VCSグループはID=4を除く3台構成で運用を継続します。

このように、スレーブを取り外した場合は、取り外したスレーブ上のポートが使えなくなりますが、VCSグループ全体の状態への影響はありません。
一方、マスターを取り外した場合は、次点のスレーブへのマスター切り替えが発生するため、一定時間の通信断が発生します。

メンバーの交換

メンバーの交換手順は「メンバーの取り外し」と「メンバーの追加」の手順を組み合わせたものとなります。
（メンバーの取り外し、メンバーの追加をご参照ください）

「メンバーの取り外し」でも述べたように、スレーブの交換はVCSグループ全体の状態には影響しませんが、マスターの交換はマスター切り替えをともないます。マスターとして動作中のメンバーを交換した後、交換後のメンバーをマスターにしたいときは、VCSグループを再起動してください。

スタックケーブルの交換

各メンバーの電源は入れたまま、問題のあるスタックケーブルを取り外し、新しいスタックケーブルをつなぎなおしてください。

スタックモジュールの交換

スタックモジュールの交換は、基本的に「メンバーの交換」と同じ手順で行います。
（メンバーの交換をご参照ください）

スタックモジュールの故障しているメンバーを「メンバーの取り外し」にしたがって取り外し、モジュールを交換した上で、「メンバーの追加」にしたがい再度追加してください。

レジリエンシーリンクの交換

各メンバーの電源は入れたまま、問題のあるイーサネットケーブルを取り外し、新しいケーブルをつなぎなおしてください。

レジリエンシーリンクのポート変更

レジリエンシーリンク用に設定したスイッチポートが故障した場合は、次の手順でレジリエンシーリンク用のポートを変更してください。
ここでは、ID=4のメンバーのレジリエンシーリンク用スイッチポート2（port4.0.2）が故障したため、代わりにport4.0.3をレジリエンシーリンク用ポートに設定するものとします。

ID=4のスイッチポート2（port4.0.2）からレジリエンシーリンク用のイーサネットケーブルを抜きます。

port4.0.2をレジリエンシーリンク用ポートから通常のポートに戻します。

vcg> enable ↓ vcg# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. vcg(config)# interface port4.0.2 ↓ vcg(config-if)# no switchport resiliencylink ↓

port4.0.3をレジリエンシーリンク用ポートに設定します。

vcg(config)# interface port4.0.3 ↓ vcg(config-if)# switchport resiliencylink ↓

ランニングコンフィグをスタートアップコンフィグに保存します。

vcg(config-if)# end ↓ vcg# copy running-config startup-config ↓ Building configuration... [OK]

手順1で抜いたイーサネットケーブルを、ID=4のスイッチポート3（port4.0.3）に接続します。

ファームウェアバージョンアップ

VCSグループの運用中にファームウェアをバージョンアップする場合は、次の手順にしたがってください。
ここでは説明のため、次の環境を想定します。

マスター（ID=1）、スレーブ（ID=2）でVCSグループを運用中
VCSグループのホスト名は「vcg」
現在のファームウェアバージョンは5.4.5-2.1
新しいファームウェアバージョンは5.4.5-2.2
新しいファームウェアのイメージファイルx930-5.4.5-2.2.relは、VCSグループからアクセス可能なTFTPサーバー10.100.10.70上に置かれている

Note - 5.4.5-2.2は説明上使用している架空のファームウェアです。5.4.5-2.1リリース時点では実在しませんのでご注意ください。

show stackコマンドを実行し、VCSグループが正しく構築されていることを確認してください。

vcg# show stack ↓ Virtual Chassis Stacking summary information ID Pending ID MAC address Priority Status Role 1 - 0009.41fb.c7eb 128 Ready Active Master 2 - 0009.41fb.cfaf 128 Ready Backup Member Operational Status Normal operation Stack MAC address 0009.41fb.c7eb

TFTPサーバー上などで、新しいファームウェアイメージファイルのサイズを確認してください。Windowsならファイルの「プロパティ」や「dir」コマンド、UNIXなら「ls -l」コマンドなどで確認します。

show file systemsコマンドを実行して、各メンバーのフラッシュメモリー空き容量を確認します。

vcg# show file systems ↓ Stack member 1: Size(b) Free(b) Type Flags Prefixes S/D/V Lcl/Ntwk Avail ------------------------------------------------------------------- 63.0M 47.2M flash rw flash: static local Y - - system rw system: virtual local - ... Stack member 2: Size(b) Free(b) Type Flags Prefixes S/D/V Lcl/Ntwk Avail ------------------------------------------------------------------- 63.0M 47.3M flash rw flash: static local Y - - system rw system: virtual local - ...

この例では、メンバー1の空き容量が47.2MByte、メンバー2の空き容量が47.3MByteであると確認できます。空き容量とイメージファイルのサイズを比較して、すべてのメンバーにイメージファイルを格納するのに充分な空きがあることを確認してください。

いずれかのメンバーの空き容量が足りない場合は、deleteコマンドで不要なファイルを削除して空きを作ってください。たとえば、メンバー2の空き容量が足りない場合は、次のようにして不要なファイルを削除します。

vcg# dir vcg-2/flash:/*.rel ↓ ... 1401740 -rw- Jan 01 2011 00:00:00 vcg-2/flash:/x930-nolonger-used.rel ... vcg# delete vcg-2/flash:/x930-nolonger-used.rel ↓ Deleting.................................................... Successful operation

ここで、コマンド中の「vcg-2/」はスレーブのファイルシステムを指定するための書式で、VCSグループのホスト名（例ではvcg）、半角ハイフン、スレーブのスタックメンバーID（例では2）、半角スラッシュをつなげたものです。

「vcg-2/」は一例ですので、実際にはご使用の環境におけるホスト名とスタックメンバーIDを指定してください。たとえば、VCSグループのホスト名が「november」でスレーブのスタックメンバーIDが「3」のときは、「vcg-2/」の代わりに「november-3/」と指定します。なお、ホスト名を明示的に設定していない場合、VCSグループのホスト名は「awplus」となります（たとえば、「awplus-2/」などと指定します）。

スレーブファイルシステムの指定方法については、応用編をご覧ください。

新しいファームウェアのイメージファイルをマスターにダウンロードします。

vcg# copy tftp://10.100.10.70/x930-5.4.5-2.2.rel flash ↓ Enter destination file name [x930-5.4.5-2.2.rel]: Copying.................................................... Successful operation

boot systemコマンドを使って、新しいイメージファイルを通常用ファームウェアに指定します。このコマンドを実行すると、マスター上のイメージファイルがスレーブメンバーに自動的にコピーされます。イメージファイルの設定は、コマンド実行時にシステムファイルに保存されるため、copyコマンドやwrite fileコマンド、write memoryコマンドなどでコンフィグに保存する必要はありません。

vcg# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. vcg(config)# boot system x930-5.4.5-2.2.rel ↓ VCS synchronizing file across the stack, please wait........................ File synchronization with stack member-2 successfully completed [DONE]

show bootコマンドを実行して、通常用ファームウェアイメージの設定を確認します。また、各メンバーに対してdirコマンドを実行し、すべてのメンバーに新しいファームウェアのイメージファイルが存在することを確認してください。

vcg# show boot ↓ Boot configuration -------------------------------------------------------------------------------- Current software : x930-5.4.5-2.1.rel Current boot image : flash:/x930-5.4.5-2.2.rel Backup boot image : Not set Default boot config: flash:/default.cfg Current boot config: flash:/default.cfg (file exists) Backup boot config : Not set Autoboot status : disabled vcg# dir *.rel ↓ 14492851 -rw- May 11 2012 06:42:05 flash:/x930-5.4.5-2.2.rel ... vcg# dir vcg-2/flash:/*.rel ↓ 14492851 -rw- May 11 2012 06:42:05 vcg-2/flash:/x930-5.4.5-2.2.rel ...

VCSグループ全体を再起動します。

Note - 再起動中は通信断が発生します。

vcg(config)# end ↓ vcg# reload ↓ Are you sure you want to reboot the whole stack? (y/n): y ↓ ...

再起動完了後、show systemコマンドでファームウェアバージョンを確認し、show stackコマンドでVCSグループが正しく構築されていることを確認します。問題がなければ、以上でバージョンアップは完了です。

VCSホットソフトウェアアップグレード

VCSホットソフトウェアアップグレードは、reload rolling/reboot rollingコマンドを用いて、マスターの切り替えと再起動、ファームウェアバージョンアップをメンバーごとに順番に行う機能です。

Note - reload rolling/reboot rollingコマンドは、メジャーバージョンアップには使用できません。

reload rolling/reboot rollingコマンドを使用して、VCSグループの運用中にファームウェアをバージョンアップする場合は、次の手順にしたがってください。ここでは説明のため、次の環境を想定します。（以下の説明では、実際のバージョンや画面とは異なる場合があります。）

マスター（ID=1）、スレーブ（ID=2）でVCSグループを運用中
VCSグループのホスト名は「vcg」
現在のファームウェアバージョンは5.4.5-2.1
新しいファームウェアバージョンは5.4.5-2.2
新しいファームウェアのイメージファイルx930-5.4.5-2.2.relは、VCSグループからアクセス可能なTFTPサーバー10.100.10.70上に置かれている

Note - 5.4.5-2.2は説明上使用している架空のファームウェアです。5.4.5-2.1リリース時点では実在しませんのでご注意ください。

show stackコマンドを実行し、VCSグループが正しく構築されていることを確認してください。

TFTPサーバー上などで、新しいファームウェアイメージファイルのサイズを確認してください。Windowsならファイルの「プロパティ」や「dir」コマンド、UNIXなら「ls -l」コマンドなどで確認します。

show file systemsコマンドを実行して、各メンバーのフラッシュメモリー空き容量を確認します。

新しいファームウェアのイメージファイルをマスターにダウンロードします。

vcg# copy tftp://10.100.10.70/x930-5.4.5-2.2.rel flash ↓ Enter destination file name [x930-5.4.5-2.2.rel]: Copying.................................................... Successful operation

reload rolling/reboot rollingコマンドによりVCSグループを再起動します。

vcg# reboot rolling ↓ The stack master will reboot immediately and boot up with the configuration file settings. The remaining stack members will then reboot once the master has finished re-configuring. Continue the rolling reboot of the stack? (y/n): y 21:21:40 vcg VCS[1034]: Automatically rebooting stack member-1 (MAC: 0009.41fb. c7eb) due to Rolling reboot

起動方法は以下のとおりです。

(1) マスター（ID=1）から再起動します。

(2) スレーブ（ID=2）がマスター（ID=2）として起動します。

Note - スレーブからマスターへ遷移するとき、リンクダウンはしません。

(3) 再起動している旧マスター（ID=1）が各プロセスの起動を完了し、コンフィグを読み込んだ後に、マスター（ID=2）が再起動します。
3台以上のVCSグループ構成の場合は、旧マスター（ID=1）以外のメンバーが同時に再起動します。

(4) （ID=1）がマスターとして起動します。

Note - マスター（ID=1）は正常起動するまでポートをリンクアップしません。旧マスター（ID=2）も再起動中はリンクダウンするため、マスター（ID=1）がコンフィグを読み込んでから正常起動するまでの間、一時的にVCSグループの全ポートがリンクダウンしている状態になります。

マスター（ID=1）の正常起動後にポートがリンクアップして通信が可能な状態になりますが、通信が復旧するまでの時間は、ネットワーク環境と使用しているプロトコルの復旧時間に依存します。

(5) 旧マスター（ID=2）が自動的にVCSメンバーにスレーブとして追加されます。
3台以上のVCSグループ構成の場合は、マスター（ID=1）以外のメンバーがスレーブとして追加されます。

(6) 5.4.5-2.2にバージョンアップし、VCS再運用が可能となります。

USBオートブート機能を使用したファームウェアバージョンアップ

本製品では、USBメモリーにファームウェアイメージファイルやコンフィグファイル、および、これらのファイル名を記載した設定ファイル（autoboot.txt）を格納しておき、このUSBメモリーを装着した状態でシステムを起動することにより、ファームウェアやコンフィグファイルの更新を自動的に行う「USBオートブート機能」をサポートしています。

USBオートブート機能自体は単体構成時（非VCS構成時）のみのサポートですが、下記手順にしたがって実行することにより、VCSグループのバージョンアップに利用することも可能です。

以下ではUSBオートブート機能を使用してVCS構成の全スタックメンバーのファームウェアをバージョンアップする方法を紹介します。

なお、この方法で必要なUSBメモリーはマスターで使用する1つだけとなります。

本機能を使用してファームウェアをバージョンアップする場合は次の手順にしたがってください。ここでは説明のため、次の環境を想定します。（以下の説明では、実際のバージョンや画面とは異なる場合があります。）

マスター（ID=1）、スレーブ（ID=2）でVCS グループを運用中
VCSグループのホスト名は「vcg」
現在のファームウェアバージョンは5.4.5-2.1
新しいファームウェアバージョンは5.4.5-2.2

Note - 5.4.5-2.2は説明上使用している架空のファームウェアです。5.4.5-2.1リリース時点では実在しませんのでご注意ください。

Note - 本手順を実行する場合は、各メンバーへの物理的アクセスと、レジリエンシーリンクの接続が必要です。AT-StackOP/0.3、AT-StackOP/9.0、AT-SP10SR、AT-SP10LR、AT-SP10ER40/Iを使用する構成でレジリエンシーリンクを使用していない場合や、いずれかのメンバーが遠隔地に設置されており物理的にアクセスできない場合、本手順は使用できません。

Note - USBメモリー上のファームウェアへバージョンアップするには、USB 2.0である必要があります。ご使用の際には、お客様の使用環境で事前に検証を行った上で導入してください。

新しいファームウェアイメージファイルをUSBメモリーのルートディレクトリーにコピーします。
USBオートブート機能で使用する設定ファイル（autoboot.txt）を作成します。本設定ファイルはプレインテキストファイルです。コマンドリファレンスに記載されている書式にしたがって編集してください。
[AlliedWare Plus] Copy_from_external_media_enabled=yes Boot_Release=x930-5.4.5-2.2.rel
前の手順で作成したautoboot.txtをUSBメモリーのルートディレクトリーにコピーします。

[バージョンアップ]
PC上などで、新しいファームウェアイメージファイルのサイズを確認してください。Windows ならファイルの「プロパティ」や「dir」コマンド、UNIX なら「ls -l」コマンドなどで確認します。

show file systemsコマンドを実行して、各メンバーのフラッシュメモリー空き容量を確認します。

vcg# show file systems ↓ Stack member 1: Size(b) Free(b) Type Flags Prefixes S/D/V Lcl/Ntwk Avail ------------------------------------------------------------------- 63.0M 35.5M flash rw flash: static local Y - - system rw system: virtual local - ... Stack member 2: Size(b) Free(b) Type Flags Prefixes S/D/V Lcl/Ntwk Avail ------------------------------------------------------------------- 63.0M 38.5M flash rw flash: static local Y - - system rw system: virtual local - ...

この例では、メンバー1 の空き容量が35.5MByte、メンバー2 の空き容量が38.5MByteであると確認できます。空き容量とイメージファイルのサイズを比較して、すべてのメンバーにイメージファイルを格納するのに充分な空きがあることを確認してください。いずれかのメンバーの空き容量が足りない場合は、deleteコマンドで不要なファイルを削除して空きを作ってください。たとえば、メンバー2 の空き容量が足りない場合は、次のようにして不要なファイルを削除します。

ここで、コマンド中の「vcg-2/」はスレーブのファイルシステムを指定するための書式で、VCSグループのホスト名（例ではvcg）、半角ハイフン、スレーブのスタックメンバーID（例では2）、半角スラッシュをつなげたものです。「vcg-2/」は一例ですので、実際にはご使用の環境におけるホスト名とスタックメンバーID を指定してください。たとえば、VCS グループのホスト名が「november」でスレーブのスタックメンバーID が「3」のときは、「vcg-2/」の代わりに「november-3/」と指定します。なお、ホスト名を明示的に設定していない場合、VCS グループのホスト名は「awplus」となります（たとえば、「awplus-2/」などと指定します）。
スレーブファイルシステムの指定方法については、応用編をご覧ください。

レジリエンシーリンクが接続されていることを確認します。
VCSのスレーブ側のスタックケーブルを抜きます。
コンソール上でautoboot enableコマンドを実行し、USBオートブート機能を有効にします。同コマンドの設定は、実行と同時にシステムファイルに保存されるため、copyコマンドやwrite fileコマンド、write memoryコマンドなどでコンフィグに保存する必要はありません。
vcg# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. vcg(config)# autoboot enable ↓
現在のコンフィグを念のためバックアップします。ここでは例としてbefore-autoboot-upgrade.cfgというファイル名でバックアップしています。
vcg(config)# exit ↓ vcg# copy running-config before-autoboot-upgrade.cfg ↓
USBメモリーをマスターのUSBポートに挿入します。
次のコマンドを実行して、マスターを再起動します。マスターの再起動により、スレーブがマスターに昇格します。
vcg# reload ↓

旧マスターの再起動中に、USBオートブート機能が動作していることを示す次のメッセージが表示され、その後再度旧マスターが自動的に再起動します。

09:28:21 awplus Autoboot: autoboot.txt file detected awplus login: 09:29:21 awplus Autoboot: Restoring release from usb:/x930-5.4.5-2.2.rel to flash:x930-5.4.5-2.2.rel. This may take several minutes to complete. 09:29:21 awplus Autoboot: Please wait until the device reboots. 09:30:21 awplus Autoboot: Release successfully restored 09:30:21 awplus Autoboot: Autoboot restore successful, rebooting device.

旧マスターの2回目の起動が完了して、ログインプロンプトが表示されたら、旧スレーブ（現マスター）の電源を切ります。これにより、旧マスターが再びマスターに昇格します。
旧スレーブ側のスタックケーブルを接続し、再度電源を入れます。起動中、マスターと同期をとるためにもう一度自動的に再起動します。

旧スレーブの再起動が完了したら、マスター側でshow bootコマンドを実行し、USBメモリー上のautoboot.txtファイルで指定したファームウェアイメージファイルが通常用ファームウェアとして設定されており、実際にロードされていることを確認してください。また、バージョンアップ前に使用していたファームウェアイメージファイルがバックアップ用ファームウェアとして設定されていることを確認してください。問題がなければ、以上でバージョンアップは完了です。

vcg# show boot ↓ Boot configuration -------------------------------------------------------------------------------- Current software : x930-5.4.5-2.2.rel Current boot image : flash:/x930-5.4.5-2.2.rel Backup boot image : flash:/x930-5.4.5-2.1.rel Default boot config: flash:/default.cfg Current boot config: flash:/default.cfg (file exists) Backup boot config: Not set Autoboot status : enabled

バージョンアップが完了したら、autoboot enableコマンドをno形式で実行し、USBオートブート機能を無効にしてください。
同コマンドの設定は、実行と同時にシステムファイルに保存されるため、copyコマンドやwrite fileコマンド、write memoryコマンドなどでコンフィグに保存する必要はありません。
vcg# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. vcg(config)# no autoboot enable ↓

USBメモリー上のファームウェアを通常用ファームウェアに指定する

本製品では、USBメモリーに保存したファームウェアイメージファイルを、通常用ファームウェアとして直接使用することができます。スタックメンバーのフラッシュメモリー上にファームウェアを保存する必要がないので、スタックメンバーのフラッシュメモリーの空き容量を気にする必要がありません。また、USBメモリーに保存したコンフィグファイルを通常用コンフィグとして直接使用することもできます。
本機能を使用するときは、同一種類かつ同一容量のUSBメモリーがスタックメンバーの台数分必要となります。

本機能を使用してファームウェアをバージョンアップする場合は次の手順にしたがってください。ここでは説明のため、次の環境を想定します（以下の説明では、実際のバージョンや画面とは異なる場合があります）。

マスター（ID=1）、スレーブ（ID=2）でVCS グループを運用中
VCSグループのホスト名は「vcg」
現在のファームウェアバージョンは5.4.5-2.1
新しいファームウェアバージョンは5.4.5-2.2

Note - 5.4.5-2.2は説明上使用している架空のファームウェアです。5.4.5-2.1リリース時点では実在しませんのでご注意ください。

show stackコマンドを実行し、VCS グループが正しく構築されていることを確認してください。

vcg# show stack ↓ Virtual Chassis Stacking summary information ID Pending ID MAC address Priority Status Role 1 - 0015.7793.23cb 128 Ready Active Master 2 - 0015.77df.f59d 128 Ready Backup Member Operational Status Normal operation Stack MAC address 0000.cd37.03db (Virtual MAC)

新しいファームウェアイメージファイルをUSBメモリーに保存します。新しいファームウェアイメージファイルを保存するのはマスターで使用するUSBメモリーのみでも問題ありませんが、この場合はスレーブで使用するすべてのUSBメモリーに新しいファームウェアイメージファイルを保存できる空き容量があることを確認してください。
USBメモリーをすべてのスタックメンバーのUSBポートに挿入します。

boot systemコマンドのbackupパラメーターを使って、USBメモリーが挿入されていなかったときに使用するバックアップ用ファームウェアを指定します。バックアップ用ファームウェアが設定されていないと、USBメモリーに保存されているファームウェアを通常用ファームウェアに設定できません。現在通常用ファームウェアとして指定しているファームウェアをバックアップ用ファームウェアとして指定する場合は、「no boot system」を先に実行してください。

vcg# configure terminal ↓ Enter configuration commands, one per line. End with CNTL/Z. vcg(config)# no boot system ↓ vcg(config)# boot system backup x930-5.4.5-2.1.rel ↓ VCS synchronizing file across the stack, please wait... File synchronization with stack member-2 successfully completed [DONE]

boot systemコマンドを使って、USBメモリーに保存されている新しいファームウェアを通常用ファームウェアに指定します。

vcg(config)# boot system usb:/x930-5.4.5-2.2.rel ↓ VCS synchronizing file across the stack, please wait....... File synchronization with stack member-2 successfully completed [DONE]

show bootコマンドを実行して、通常用ファームウェアとバックアップ用ファームウェアの設定を確認します。

reload/rebootコマンドもしくは、reload rolling/reboot rollingコマンドによりVCSグループ全体を再起動します。

Note - reload rolling/reboot rollingコマンドは、メジャーバージョンアップには使用できません。
vcg# reload ↓ Are you sure you want to reboot the whole stack? (y/n): y ↓
再起動完了後、show systemコマンドでファームウェアバージョンを確認し、show stackコマンドでVCS グループが正しく構築されていることを確認します。問題がなければ、以上でバージョンアップは完了です。

メンバー			スタックLED		ポートLED
メンバー			スタックLED		RL 1		RL 2
ID	Pri	状態	1（S1）	2（S2）	L/A	DPX	L/A	DPX
1	32	マスター	緑	緑	緑	緑	緑	緑
2	64	スレーブ	緑	緑	緑	緑	緑	緑
3	96	スレーブ	緑	緑	緑	緑	緑	緑
4	128	スレーブ	緑	緑	緑	緑	緑	緑

メンバー			SFP+スロットLED/QSFP+スロットLED		ポートLED/マネージメントポートLED
メンバー			SFP+スロットLED/QSFP+スロットLED		RL 1		RL 2
ID	Pri	状態	1（S1）	2（S2）	L/A	DPX	L/A	DPX
1	32	マスター	緑	緑	緑	緑	×	×
2	64	スレーブ	緑	緑	×	×	緑	緑
3	96	スレーブ	緑	緑	緑	緑	×	×
4	128	スレーブ	緑	緑	×	×	緑	緑

バーチャルシャーシスタック（VCS） / 運用

VCSグループの運用状態確認

前提事項

基本的な考え方

マスターの確認

スタックリンク

レジリエンシーリンク

初期状態

マスター障害

スレーブ障害

スタックリンク障害（1箇所）

スタックリンク障害（2箇所以上）

メンバーが1対3に分断された例

メンバーが2対2に分断された例

レジリエンシーリンク障害

VCSグループ運用中のメンテナンス作業

メンバーの追加

メンバーの取り外し

メンバーの交換

スタックケーブルの交換

スタックモジュールの交換

レジリエンシーリンクの交換

レジリエンシーリンクのポート変更

ファームウェアバージョンアップ

VCSホットソフトウェアアップグレード

USBオートブート機能を使用したファームウェアバージョンアップ

USBメモリー上のファームウェアを通常用ファームウェアに指定する

ナビゲーション