LAN スイッチング : スパニング ツリー プロトコル

Catalyst スイッチ上の Backbone Fast の説明と設定

2015 年 11 月 25 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2008 年 9 月 16 日) | 英語版 (2015 年 10 月 7 日) | フィードバック


目次


概要

Backbone Fast は Cisco 独自の機能で、ブリッジ ネットワークのすべてのスイッチで一度有効にしておくと、間接的なリンク障害からの回復時にスイッチの経過時間を最大 20 秒(max_age)まで短縮できます。 いくつかの Spanning Tree Protocol (STP) 基本の速い確認が、場合があった正確な障害シナリオ Backbone Fast が適用するおよび CatOS および Cisco IOS を両方実行する Catalyst スイッチのためにそれを設定する方法を見る後か。 ソフトウェア。

はじめに

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

前提条件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • 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 の概要と比較方法

Bridge Protocol Data Unit(BPDU; ブリッジ プロトコル データ ユニット)は、送信するフィールドによって厳密に分類できます。 これらのフィールドの間でルートブリッジID、パス コスト、および送信側ブリッジID はルートにあります。 BPDU は別の BDPU よりよいこれらの理由により考慮されます:

  • ある BPDU のルート ブリッジ ID 値が他の BPDU のルート ブリッジ ID 値よりも優良である場合。 値が低いほど優れています。

  • ルート ブリッジ ID の値が等しい場合には、ルートへのパス コストが最低値の BPDU が優良です。

  • ルート ブリッジ ID 値が等しく、ルートへのパス コストも同じ場合は、発信元ブリッジ ID がよい BPDU が優良です。 値が低いほど優れています。

他にも基準となる変数がありますが、 BPDU が優良であるほど、最適なルート ブリッジへのアクセスも速くなります。

ブリッジでは、自身が送信する BPDU よりも優良な BPDU がポートで受信されると、そのポートがルート ポートでない限り、ブロッキング モードに設定されます。 つまり、このポートに接続しているセグメント上には、別のブリッジが代表ブリッジとして存在します。 ブリッジは、現在の代表ブリッジから送られた BPDU 値をポート上に保存します。

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

次の図では、間接的なリンク障害の発生後に再計算する必要が生じた場合に、STP がどう動作するのかを示しています。つまり、直接接続していないリンク上の障害が原因で、ブリッジがいくつかのポートのステータスを変更する必要がある場合です。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18a.gif

3 つのスイッチ、R、B、および S がフルメッシュ構造のトポロジで配置されている上記のダイアグラム考えてみます。 R がルート ブリッジで、B がバックアップ用のルート ブリッジだとします。 S がポート P をブロッキングし、B はリンク L3 の代表ブリッジです。

  1. リンク L1 に障害が発生すると、スイッチ B はすぐにその障害を検出して、自らをルートと見なします。 B は BPDU を S に送信し始め、新規ルートであることを通知します。

  2. S は B から新しい BPDU を受信しても、その BPDU が、ポート P に保存されている BPDU よりも不良であることに気がつくと無視します。

  3. max_age タイマーがデフォルトの 20 秒を過ぎると、ポート P に関して S に保存されている BPDU はエージング アウトします。 ポート P はすぐにリスニングに移行し、S はより優良な BPDU を B に送り始めます。

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

  5. ポート P は、リスニングおよびラーニングのステートを経て、フォーワディング ステートに移行します。 これには、fw_delay 値の 2 倍の時間、つまり 30 秒かかります。 その後、完全な接続性が復元します。

この間接的なリンク障害から回復するのに、max_age 値(20 秒)と fw_delay 値の 2 倍(2 x 15 秒)がかかりました。 デフォルトのパラメータでは、50 秒になっています。 Backbone Fast 機能では、max_age(20 秒)を保つようになっています。 このために、不良 BPDU をポートに受信するとすぐにエージング アウトします。

標準的な STP 用の Backbone Fast 拡張機能

前の例で、STP により間接的なリンク障害によって発生する誤った情報が無効にされています。 このためには、受動的に max_age が待機されています。 この max_age の遅延をなくすために、Backbone Fast には次の 2 つの拡張機能が導入されています。

  • できるだけ迅速に間接的なリンク障害を検出する機能。 リング障害を検出するには、代表ブリッジが直接的なリンク障害を検出した後に送信する不良 BPDU をトラッキングします。

  • ポート上に保存された BPDU 情報がまだ有効であるかどうかをすぐにチェックできるメカニズム。 新しい Protocol Data Unit(PDU; プロトコル データ ユニット)および Root Link Query(このドキュメントでは、RLQ PDU と示されています)を使用して、このメカニズムが実装されています。

間接的なリンク障害の検出

代表ブリッジから送られてきた不良 BPDU をポートで受信すると、このブリッジには次のことが発生します。

  1. ルートが失われると、ブリッジ ID 値がより高いルート(元のルートよりも不良)のアドバタイズを開始します。

  2. または、ルートへのパス コストが、元の値を超えます。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18c.gif

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18d.gif

Institute of Electrical and Electronics Engineers(IEEE; 電気電子学会)の仕様に基づく一般的な動作では、すべての不良 BPDU が単に無視されます。 しかし、Backbone Fast 機能は、不良 BPDU を利用します。つまり、不良 BPDU を 1 つ受信したということは、ルートへのパスで障害が発生したことは確実であり、少なくとも 1 つのポートは早急にエージング アウトする必要があることがわかるからです。

注: ネットワーク内に不良 BPDU がまったく生成されなくても、間接的なリンク障害が発生する可能性があります。 上の図にハブを追加してみます。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18e.gif

ルート ブリッジ R とハブの間にリンク障害が発生しています。 B は、リンクの障害を検出しておらず、新しいルートであると通知する前に max_age を待機します。 メカニズムが機能するのは、ブリッジが直接的なリンク障害を検出した場合に限られることに注意してください。

代表ブリッジが送信した不良 BPDU のみがトラッキングされます。 これはポート上に保存される BPDU だからです。 たとえば、新しく挿入されたブリッジが不良 BPDU を送信し始めても、Backbone Fast 機能は起動されません。

間接的なリンク障害への対応

非代表ポートで不良 BPDU が検出されると、Backbone Fast 機能の第 2 フェーズが起動します。 障害の影響を受けたポートをエージング アウトするために、max_age を受動的に待機するのではなく、RLQ PDU を使用して障害を瞬時にテストする予防的な方法が導入されています。 RLQ を使用すると、非代表ポート上のルートで ping のような機能が実現します。ポート上に保存されている BPDU がまだ有効であるか、または廃棄する必要があるかを迅速に確認できます。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18f.gif

代表ブリッジから不良 BPDU を受信した場合は、不良 BPDU を受信したポートとセルフループ ポートを除き、すべての非代表ポートから RLP PDU を送信します。 これは、BPDU の受信に使用したポート上のルートからまだ応答があることをチェックするためです。 不良 BPDU を受信したポートは、障害の影響を受けていることが分かっているため、除外します。セルフループ ポートや代表ポートは、ルートに接続しないので役に立ちません。

ポートで RLQ 応答を受信したときに、応答が否定的であれば、ポートとルートとの接続は失われているので BPDU をエージング アウトできます。 さらに、他のすべての非代表ポートが否定応答を受信していた場合は、ブリッジ全体でルートが失われるため、STP 計算を始めから開始できます。

応答によって、このポート経由でルート ブリッジにまだアクセスできることが確認できれば、不良 BPDU を最初に受信したポートをすぐにエージング アウトできます。

次の例では、ポート A、B、D、および E がスイッチ S の非代表ポートになっています。A はルート ポートで、その他のポートはブロッキングしています。 ポート E が不良 BPDU を受信すると(1)、Backbone Fast が起動して STP 再計算が加速されます。

RLQ 要求を送信して、E 以外のすべての非代表ポート上でルート R を探します(2)。 応答には、これらのポート経由でアクセスできるルートがどれであるかが示されています。 D が受信した RLQ 応答には、D がルート R へのパスを失っていることが示されています。速やかに BPDU をエージング アウトします(3)。 ポート A および B は、ルート R へのパスが保持されていることを確認する応答を受信しました(4)。 スイッチ S はまだルートに接続されているので、すぐにポート E をエージング アウトし、正規の STP 規則で運用します(5)。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18g.gif

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18h.gif

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18i.gif

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18j.gif

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18k.gif

スイッチが R 以外のルートの応答しか受信しなかった場合は、ルートとの接続は失われており、STP の再計算がすぐに最初から再開されたと見なします。 このようなケースは、ブリッジ上の非代表(および非セルフループ)ポートだけがルート ポートであり、このポートで不良 BPDU を受信した場合にも発生することに注意してください。

ルートリンク クエリ PDU

RLQ には、RLQ 要求と RLQ 応答の 2 つの形式があります。

通常 BPDU を受信するポートに RLQ 要求を送信すると、このポート経由でルートとまだ接続されていることをチェックできます。 どのブリッジが自分のルートであるかを RLQ 要求に示すと、このポート経由でアクセスできるルート ブリッジを示す RLQ 応答がやがて戻ってきます。 2 つのルートが同一であれば、ルートとの接続はまだ保持されていますが、異なっていれば失われています。

RLQ 要求を受信するブリッジは、照会のあったルートとの接続が失われている(RLQ クエリーに示されているルート ブリッジとは異なるルート ブリッジと接続している)場合、および自らがルートである場合は、瞬時に応答します。

これがあてはまらない場合は、そのブリッジはルート ポート経由でルートにクエリーを転送します。

RLQ 応答は、代表ポートであふれます。 RLQ 要求の発信元は、ブリッジ ID を PDU に設定します。 これは、発信元が自らのクエリーに対する応答を受信するときに、代表ポートが応答であふれないようにするためです。

RLQ PDU のパケット構造は、通常の STP BPDU と同じです。 唯一の相違は、シスコ固有の、2 つの異なる SNAP アドレスが使用されることです。 1 つは要求用、もう 1 つは応答用のアドレスです。

次に、標準的な BPDU のフォーマットを示します。

DA SA 長さ DSAP SSAP CNTL SNAP PDU

次に、PDU フィールドを示します。

プロトコル ID Version メッセージ タイプ フラグ ルート ID ルート パス コスト
発信元 ID ポート ID メッセージの経過時間 最大経過時間 ハロー タイム 転送遅延

PDU で使用するメッセージ タイプも、標準 BPDU のものとは異なります。

使用するフィールドは、ルート ID と発信元ブリッジ ID だけです。

PDU を処理するために、このシスコ固有の機能をネットワーク内の全スイッチに設定する必要があります。

Backbone Fast 機能が有効になっているシナリオ例

次のケースは最初の例に基づいていますが、今回は、3 台のスイッチ上で Backbone Fast 機能が有効になっています。

  1. 最初の段階は、前に説明したものとまったく同じです。

  2. S は不良 BPDU を B から受信するとすぐに、max_age を待たずに非代表ポートを再確認し始めます。 さらに、ルート ブリッジ R 用のルート ポートにある RLQ クエリーを送信します。

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

  4. S はこれで S のすべての非代表ポートのチェックを終えました。ルートとの接続はまだ保持されています。 次に、S は、ポート P 上に保存された情報をすぐにエージング アウトできます。P はリスニングに移行し、BPDU を送信し始めます。 この段階で、max_age 秒をまだ超えてはおらず、標準的な Spanning-Tree Algorithm(STA; スパニングツリー アルゴリズム)が適用されます。

  5. B は S から優良な BPDU を受信し(R は B よりも優良なルートです)、L3 に接続するポートをルート ポートと見なします。

http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18m.gif

CatOS および Cisco IOS 用の Backbone Fast 機能の設定

Backbone Fast 機能を使用する場合、ネットワーク内のすべてのスイッチ上で Backbone Fast 機能を有効にする必要があります。これは、Backbone Fast 機能は、ルート パスの安全性をスイッチに通知するために RLQ 要求および応答メカニズムを使用する必要があるためです。 RLQ プロトコルは、Backbone Fast 機能がスイッチ上で有効になっている場合にのみアクティブになります。 また、Backbone Fast 機能が一部のスイッチで有効ではない場合、ネットワークには RLQ フラッディングの問題が発生する可能性もあります。 デフォルトでは、Backbone Fast 機能は無効です。

Catalyst 2900XL および 3500XL スイッチでは、BackboneFast 機能はサポートされていません。 通常、BackboneFast 機能をサポートするその他の Catalyst スイッチに加えて、スイッチ ドメインにこれらのスイッチが含まれる場合、BackboneFast 機能を有効にする必要があります。 XL スイッチが含まれる環境で Backbone Fast 機能を実装する場合、厳密なトポロジの下で、XL スイッチがラインの最終スイッチであり、2 つの場所でコアにのみ接続されていれば、Backbone Fast 機能を有効にすることができます。 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#

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 12014