内容

概要

前提条件

要件

使用するコンポーネント

BPDU の概要および比較方法

間接リンク障害からの STP 回復方法

Backbone Fast による標準 STP の機能拡張

間接リンク障害の検出

間接リンク障害への対応

Root Link Query PDU

Backbone Fast 機能を有効にしたシナリオ例

CatOS および Cisco IOS での Backbone Fast の設定

CatOS での設定

Cisco IOS での設定

関連情報

概要

このドキュメントでは、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）は、伝送するフィールドによって厳密に分類できます。BPDU が伝送するフィールドは、ルート ブリッジ ID、ルートへのパス コスト、送信元ブリッジ ID です。BPDU 同士の相対的な上位/下位を決定する基準は以下のとおりです。

- ある BPDU が別の BPDU より優れたルート ID を伝送している場合は、上位 BPDU となる。ルート ID は、値が小さければ小さいほど優れていることになります。

- ルート ID の値が等しい場合は、BDPDU のルートへのパス コストが他よりも小さい BPDU が上位 BPDU となる。

- ルート ID の値が等しく、ルートが同じ場合は、送信元ブリッジ ID が他よりも優れている BPDU が上位 BPDU となる。ルート ID は、値が小さければ小さいほど優れていることになります。

同点決着要因としての役割を果たす他の変数もありますが、BPDU が優れていれば、それだけルート ブリッジへのアクセスも優良ということになります。

送信する BPDU よりも高位の BPDU をポートで受信するブリッジは、そのポートがルート ポートでない限り、そのポートをブロック モードの状態にします。これは、そのポートに接続するセグメント上に、代表ブリッジとして別のブリッジがあることを意味します。ブリッジは、現在の代表ブリッジから送信された BPDU の値をポートで保管します。

間接リンク障害からの STP 回復方法

以下の図に、間接リンク障害の発生後に再計算が必要となる場合の STP の動作を示します。間接リンク障害とは、ブリッジが、直接接続されていないリンクで障害が発生したためにポートのステータスを変更しなければならない場合を意味します。

この図には、フル メッシュ構造のスイッチ R、B、および S が示されています。R はルート ブリッジで、B はバックアップ ルート ブリッジという設定です。S が自身のポート P をブロックし、B がリンク L3 の代表ブリッジとなっています。

1. リンク L1 がダウンすると、スイッチ B は直ちに障害を検出し、自身が新しいルートになるものと想定します。そのため、スイッチ B は新しいルートであると主張するために S に BPDU を送信し始めます。

2. Ｓ は B から新しい BPDU を受信すると、その BPDU がポート P で保管されている BPDU よりも下位であると判断して無視します。

3. max_age タイマーが満了すると（デフォルトでは 20 秒）、S のポート P で保管されている BPDU がエージ アウトします。ポート P は直ちにリスニング中の状態になり、S が自身の上位 BPDU を B に送信し始めます。

4. B は S から BPDU を受信すると同時に、BPDU の送信を停止します。

5. これにより、ポート P がリスニング中および学習中の状態からフォワーディング ステートに遷移します。この遷移には、fw_delay 値を 2 倍にした値に 30 秒を足した時間がかかります。遷移が完了すると、完全な接続性が回復します。

このように、間接リンク障害から回復するまでに、max_age 値（20 秒）に fw_delay 値の 2 倍（2x15 秒）の値を足した時間がかかっています。つまり、デフォルトのパラメータでは 50 秒かかるということです。Backbone Fast は、max_age（20 秒）時間の排除を提案する機能です。 Backbone Fast はそのために、ポートで下位 BPDU を受信すると、該当するポートを即時にエージ アウトします。

Backbone Fast による標準 STP の機能拡張

前の例では、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 を受信した場合にも発生します。

Root Link Query PDU

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 機能を有効にしたシナリオ例

このシナリオは最初の例に基づいていますが、Backbone Fast が 3 つのスイッチで有効にされています。

1. 最初の段階は、前に説明したとおりです。

2. S が B から下位 BPDU を受信すると、max_age を待つことなく、すぐにその非代表ポートの再確認を開始します。S はルート ポートでルート ブリッジ R の RLQ クエリを送信します。

3. ルート ブリッジ R はこのクエリを受信するとすぐに RLQ 応答を送信し、その方向にまだルート R があることを示します。

4. すると、S はそのすべての非代表ポートをチェックし、ルートにまだ接続できることを確認します。その上で、ポート P で保管されている情報を即時にエージ アウトします。これにより、P がリスニング状態に遷移して BPDU の送信を開始します。この段階で、すでに max_age 秒の時間は節約されており、標準スパニング ツリー アルゴリズム（STA）が適用されます。

5. B は S から上位 BPDU（R の方が B よりもルートが優れています）を受信し、L3 に至るポートをそのルート ポートと見なすようになります。

CatOS および Cisco IOS での Backbone Fast の設定

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 での設定

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 での設定

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#

関連情報

- PortFast と他のコマンドを使用したワークステーションの接続始動遅延の修復

- Cisco UplinkFast 機能の理解と設定

- ループ ガードと BPDU スキュー検出機能を使用したスパニング ツリー プロトコルの拡張

- スパニング ツリー PortFast の拡張 BPDU ガード

- PVST+ から rapid-PVST へのスパニング ツリー移行の設定例

- スパニング ツリー プロトコル テクニカルに関するサポート

- スイッチ製品に関するサポート

- LAN スイッチング テクノロジーに関するサポート

- テクニカル サポートとドキュメント – Cisco Systems