この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Backbone Fast の設定方法を説明します。Backbone Fast は、Cisco 独自の機能であり、ブリッジ ネットワークのすべてのスイッチで有効にすると、スイッチが間接リンク障害から回復するまでの時間を最大 20 秒(max_age)短縮できます。まずスパニングツリー プロトコル(STP)の基本を簡単に説明してから、Backbone Fast が適用される典型的な障害のケースを紹介します。さらに、CatOS と Cisco IOS® ソフトウェアの両方が稼働する Catalyst スイッチに Backbone Fast を設定する方法について説明します。
このドキュメントに特有の要件はありません。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
Cisco IOS ソフトウェア リリース 12.1(6)EA2 以降を実行する Catalyst 2950 シリーズ スイッチ
Cisco IOS ソフトウェア リリース 12.1(4)EA1 以降を実行する Catalyst 3550 シリーズ スイッチ
CatOS 5.1(1a) 以降を実行する Catalyst 4000 シリーズ スイッチ
Cisco IOS ソフトウェア リリース 12.1(8a)EW 以降を実行する Catalyst 4500/4000 シリーズ スイッチ
CatOS バージョン 4.1(1) 以降を実行する Catalyst 5500/5000 シリーズ スイッチ
CatOS バージョン 5.1(1)CSX 以降を実行する Catalyst 6500/6000 シリーズ スイッチ
Cisco IOS ソフトウェア リリース 12.0-7XE 以降を実行する Catalyst 6500/6000 シリーズ スイッチ
ブリッジ プロトコル データ ユニット(BPDU)は、伝送するフィールドによって厳密に分類できます。BPDU が伝送するフィールドは、ルート ブリッジ ID、ルートへのパス コスト、送信元ブリッジ ID です。BPDU 同士の相対的な上位/下位を決定する基準は以下のとおりです。
ある BPDU が別の BPDU より優れたルート ID を伝送している場合は、上位 BPDU となる。ルート ID は、値が小さければ小さいほど優れていることになります。
ルート ID の値が等しい場合は、BDPDU のルートへのパス コストが他よりも小さい BPDU が上位 BPDU となる。
ルート ID の値が等しく、ルートが同じ場合は、送信元ブリッジ ID が他よりも優れている BPDU が上位 BPDU となる。ルート ID は、値が小さければ小さいほど優れていることになります。
同点決着要因としての役割を果たす他の変数もありますが、BPDU が優れていれば、それだけルート ブリッジへのアクセスも優良ということになります。
送信する BPDU よりも高位の BPDU をポートで受信するブリッジは、そのポートがルート ポートでない限り、そのポートをブロック モードの状態にします。これは、そのポートに接続するセグメント上に、代表ブリッジとして別のブリッジがあることを意味します。ブリッジは、現在の代表ブリッジから送信された BPDU の値をポートで保管します。
以下の図に、間接リンク障害の発生後に再計算が必要となる場合の STP の動作を示します。間接リンク障害とは、ブリッジが、直接接続されていないリンクで障害が発生したためにポートのステータスを変更しなければならない場合を意味します。
この図には、フル メッシュ構造のスイッチ R、B、および S が示されています。R はルート ブリッジで、B はバックアップ ルート ブリッジという設定です。S が自身のポート P をブロックし、B がリンク L3 の代表ブリッジとなっています。
リンク L1 がダウンすると、スイッチ B は直ちに障害を検出し、自身が新しいルートになるものと想定します。そのため、スイッチ B は新しいルートであると主張するために S に BPDU を送信し始めます。
S は B から新しい BPDU を受信すると、その BPDU がポート P で保管されている BPDU よりも下位であると判断して無視します。
max_age タイマーが満了すると(デフォルトでは 20 秒)、S のポート P で保管されている BPDU がエージ アウトします。ポート P は直ちにリスニング中の状態になり、S が自身の上位 BPDU を B に送信し始めます。
B は S から BPDU を受信すると同時に、BPDU の送信を停止します。
これにより、ポート P がリスニング中および学習中の状態からフォワーディング ステートに遷移します。この遷移には、fw_delay 値を 2 倍にした値に 30 秒を足した時間がかかります。遷移が完了すると、完全な接続性が回復します。
このように、間接リンク障害から回復するまでに、max_age 値(20 秒)に fw_delay 値の 2 倍(2x15 秒)の値を足した時間がかかっています。つまり、デフォルトのパラメータでは 50 秒かかるということです。Backbone Fast は、max_age(20 秒)時間の排除を提案する機能です。 Backbone Fast はそのために、ポートで下位 BPDU を受信すると、該当するポートを即時にエージ アウトします。
前の例では、STP は間接リンク障害によって正しくなくなった情報を無効化します。情報を無効化するために、STP は受動的に max_age を待機します。この max_age 遅延を排除するために、Backbone Fast は以下の 2 つの機能拡張を導入します。
間接リンク障害をできるだけ短時間で検出できるようにします。その方法として、間接リンク障害が発生すると、代表ブリッジが送信する下位 BPDU をトラッキングします。
ポートで保管されている BPDU 情報がまだ有効であるかどうかを即時にチェックするためのメカニズムを追加します。新しいプロトコル データ ユニット(PDU)と Root Link Query(RLQ)を使用して実装されるこのメカニズムを、このドキュメントでは RLQ PDU と呼びます。
ポートで代表ブリッジから下位 BPDU を受信した場合、そのブリッジはルートを失っていることになるため、ブリッジ ID の値が大きいルート(劣ったルート)のアドバタイズメントを開始します。
電気電子学会(IEEE)仕様に従った通常の動作では下位 BPDU が無視されるだけですが、Backbone Fast では下位 BPDU を利用します。それは、下位 BPDU を受信すると同時に、ルートへのパスで障害が発生したこと、そして少なくとも 1 つのポートをエージ アウトしなければならないことが確実になるためです。
注:間接リンク障害が発生しても、ネットワーク内で下位 BPDU が生成されない場合もあります。以下の図は、前の図にハブを追加しただけのものです。
この図では、ルート ブリッジ R とハブの間でリンク障害が発生しています。この場合、B はリンクがダウンしたことを検出しません。したがって、max_age を待ってから自身を新しいルートとして主張します。このメカニズムは、ブリッジが直接リンク障害を検出した場合にのみ機能することに注意してください。
トラッキングする BPDU は、代表ブリッジから送信された下位 BPDU だけです。これが、ポートで保管される BPDU であるためです。たとえば、最近挿入したブリッジが下位 BPDU の送信を開始しても、Backbone Fast 機能は起動されません。
非代表ポートで下位 BPDU が検出されると、Backbone Fast の 2 番目のフェーズがトリガーされます。受動的に max_age を待ってから、障害による影響を受ける可能性のあるポートをエージ アウトするのではなく、RLQ PDU を使用した、即時にテストするプロアクティブな方法が導入されます。RLQ を使用して、非代表ポート上のルートに対してある種の ping を行い、ポートで保管されている BPDU がまだ有効であるか、破棄しなければならないかを迅速に確認できるようにします。
代表ブリッジから下位 BPDU を受信すると、下位 BPDU を受信したポートとセルフループ ポートを除くすべての非代表ポートで RLQ PDU が送信されます。その目的は、BPDU を受信するために使用しているポートから引き続き応答があるかどうかを確認するためです。下位 BPDU を受信したポートを除外する理由は、障害の影響を受けていることはすでにわかっているからです。また、セルフループ ポートと代表ポートはルートに至らないため、この場合は役立ちません。
RLQ 応答をポートで受信すると、それが否定応答であれば、ポートはルートへの接続を失っているため、そのポートの BPDU をエージ アウトできます。さらに、他のすべての非代表ポートも否定応答を受信している場合は、ブリッジ全体がルートを失っていることになるため、STP 計算を最初から開始できます。
応答により、そのポートで引き続きルート ブリッジにアクセスできることが確認できた場合は、当初下位 BPDU を受信したポートを即時にエージ アウトできます。
以下の例では、ポート A、B、D、および E はスイッチ S の非代表ポートです。A はルート ポートで、他のポートはブロックされています。ポート E で下位 BPDU を受信すると(1)、Backbone Fast が開始して STP 再計算を高速化します。
ポート E を除くすべての非代表ポートで、ルート R を見つけるための RLQ 要求が送信されます(2)。 RLQ 要求に対する応答には、それらのポートを介してアクセス可能なルートが示されます。ポート D が受信した RLQ 応答には、ポート D がルート R へのパスを失ったことが示されているため、このポートの BPDU が即時にエージ アウトされます(3)。 ポート A と B は、R へのパスがまだ有効であるという確認を受け取ります(4)。 したがって、スイッチ S はまだルートに接続できるため、ポート E が即時にエージ アウトされ、通常の STP ルールが続行されます(5)。
スイッチ S が R とは異なるルートを指定した応答しか受信しなかった場合、ルートは失われたと見なされ、即時に STP 計算が最初から再開されます。この事態は、ブリッジ上の非代表(およびセルフ ループ)ポートだけがルート ポートとして機能していて、そのポートで下位 BPDU を受信した場合にも発生します。
RLQ には、RLQ 要求と RLQ 応答という 2 つの形があります。
RLQ 要求は、通常 BPDU を受信するポートで送信されます。これは、この通常のポートを介してまだルートに接続できることを確認するためです。要求にはルート ブリッジを指定しますが、最終的にはこのポートを介してアクセス可能なルート ブリッジを示した RLQ 応答が返されます。2 つのルートが同じであれば接続はまだ有効であり、そうでなければ接続は失われています。
ブリッジは RLQ 要求を受信するとすぐに応答を返し、RLQ クエリに指定されているルート ブリッジが異なることからクエリ対象のルートへの接続を失っていることを把握したかどうか、そしてそのブリッジがルートであるかどうかを通知します。
ブリッジがルートでない場合は、ブリッジはルート ポートを介してクエリをルートに転送します。
RLQ 応答は代表ポートでフラッディングされます。RLQ 要求の送信元は、自身のブリッジ ID を PDU に挿入します。これは、独自のクエリに対する応答を受信する際に、自身の代表ポートで応答がフラッディングされないようにするためです。
RLQ PDU のパケット構造は、通常の STP BPDU と同じです。唯一の違いは、2 つの異なる Cisco 固有の SNAP アドレスが使用されるという点です。一方は要求に使用され、もう一方は応答に使用されます。
BPDU の標準形式は以下のとおりです。
DA | SA | 長さ | DSAP | SSAP | CNTL | SNAP | PDU |
---|---|---|---|---|---|---|---|
PDU フィールドは以下のとおりです。
プロトコル識別子 | バージョン | メッセージの種類 | フラグ | ルート ID | ルートパスコスト |
---|---|---|---|---|---|
送信元 ID | ポートID | メッセージ期間 | 最大経過時間 | Helloタイム | 転送遅延 |
PDU で使用されるメッセージ タイプも、標準の BPDU とは異なります。
使用されるフィールドは、ルート ID と送信元ブリッジ ID だけです。
これらの PDU を処理するためには、この Cisco 固有の機能をネットワーク内のすべてのスイッチに設定する必要があります。
このシナリオは最初の例に基づいていますが、Backbone Fast が 3 つのスイッチで有効にされています。
最初の段階は、前に説明したとおりです。
S が B から下位 BPDU を受信すると、max_age を待つことなく、すぐにその非代表ポートの再確認を開始します。S はルート ポートでルート ブリッジ R の RLQ クエリを送信します。
ルート ブリッジ R はこのクエリを受信するとすぐに RLQ 応答を送信し、その方向にまだルート R があることを示します。
すると、S はそのすべての非代表ポートをチェックし、ルートにまだ接続できることを確認します。その上で、ポート P で保管されている情報を即時にエージ アウトします。これにより、P がリスニング状態に遷移して BPDU の送信を開始します。この段階で、すでに max_age 秒の時間は節約されており、標準スパニング ツリー アルゴリズム(STA)が適用されます。
B は S から上位 BPDU(R の方が B よりもルートが優れています)を受信し、L3 に至るポートをそのルート ポートと見なすようになります。
Backbone Fast を使用する場合は、ネットワーク内のすべてのスイッチで有効にする必要があります。これは、Backbone Fast はスイッチにルート パスの安定を通知するために、RLQ 要求/応答メカニズムを使用する必要があるためです。RLQ プロトコルは、Backbone Fast がスイッチ上で有効にされている場合にのみアクティブになります。また、Backbone Fast がすべてのスイッチで有効にされていなければ、ネットワークで RLQ フラッディングの問題が発生する可能性があるます。デフォルトでは、この機能は無効にされています。
Backbone Fast は、Catalyst 2900XL および 3500XL スイッチではサポートされていません。一般に、スイッチ ドメインに Backbone Fast をサポートしている Catalyst スイッチに加え、上述のスイッチが含まれる場合、Backbone Fast を有効にする必要があります。厳格なトポロジで XL スイッチが含まれる環境に Backbone Fast を実装する場合は、回線上の最後のスイッチが XL スイッチであり、2 箇所でだけコアに接続されているのであれば、この機能を有効にできます。XL スイッチのアーキテクチャがデイジー チェーン形式の場合は、この機能を実装しないでください。
RSTP や IEEE 802.1w を使用して Backbone Fast を設定する必要はありません。このメカニズムは RSTP にネイティブに組み込まれて自動的に有効にされるためです。RSTP または IEEE 802.1w について詳しくは、PVST+ から rapid-PVST へのスパニング ツリー移行の設定例を参照してください。
CatOS を実行する Catalyst 4000、5000、および 6000 シリーズ スイッチでは、以下のコマンドを使用して、すべてのポートに対してグローバルに Backbone Fast を有効にし、設定を検証します。
Console> (enable) set spantree backbonefast enable Backbonefast enabled for all VLANs Console> (enable) show spantree backbonefast ! This command show that the backbonefast feature is enabled. Backbonefast is enabled. Console> (enable)
Backbone Fast 統計情報を表示するには、以下のコマンドを使用します。
Console> (enable) show spantree summary Summary of connected spanning tree ports by vlan Uplinkfast disabled for bridge. Backbonefast enabled for bridge. Vlan Blocking Listening Learning Forwarding STP Active ----- -------- --------- -------- ---------- ---------- 1 0 0 0 1 1 Blocking Listening Learning Forwarding STP Active ----- -------- --------- -------- ---------- ---------- Total 0 0 0 1 1 BackboneFast statistics ! The show spantree summary command displays all backbonefast statistics. ----------------------- Number of inferior BPDUs received (all VLANs): 0 Number of RLQ req PDUs received (all VLANs): 0 Number of RLQ res PDUs received (all VLANs): 0 Number of RLQ req PDUs transmitted (all VLANs): 0 Number of RLQ res PDUs transmitted (all VLANs): 0 Console> (enable)
Cisco IOS ソフトウェアを実行する Catalyst スイッチでは、以下のコマンドを使用して、すべてのインターフェイスに対してグローバルに Backbone Fast を有効にします。
CAT-IOS# configure terminal CAT-IOS(config)# spanning-tree backbonefast CAT-IOS(config)# end CAT-IOS#
Backbone Fast が有効にされていることを確認し、統計情報を表示するには、以下のコマンドを使用します。
CAT-IOS# show spanning-tree backbonefast BackboneFast is enabled BackboneFast statistics ----------------------- Number of transition via backboneFast (all VLANs) : 0 Number of inferior BPDUs received (all VLANs) : 0 Number of RLQ request PDUs received (all VLANs) : 0 Number of RLQ response PDUs received (all VLANs) : 0 Number of RLQ request PDUs sent (all VLANs) : 0 Number of RLQ response PDUs sent (all VLANs) : 0 CAT-IOS#